# io.github.CordilleraSarl/clearotron (npm · clearotron) Clearotron — trademark clearance that shows its work - Trust score: 73/100 (medium) - Change this week: +3 - Registry status: active - Liveness: live - Owner verified: no - Last scored: 2026-11-05 ## Components - npm · `clearotron`: 73/100 (this document), [markdown](https://verifymcp.io/servers/cordillerasarl-clearotron/clearotron.md), [page](https://verifymcp.io/servers/cordillerasarl-clearotron/clearotron) ## Channel facts - Registry: `npm` - Package: `clearotron` - Version: `0.5.0` - Transport: `stdio` ## Trust breakdown How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog) Scored 2026-11-05. - **Supply Chain Security**: 76/100 - No malware found by supply-chain analysis. - CVE check failed: a known high-severity CVE affects uuid 8.3.2, reached via exceljs > uuid. A fixed version is available. - Install-script check failed: the install command fetches or executes arbitrary code (inline_eval). An install hook runs on every machine, in CI, and on transitive installs, whether or not you ever run the server. - Dependency health was assessed across the 244 of 265 dependencies we could resolve, so this covers what we could see, not the whole tree. - **Provenance & Transparency**: 100/100 - Source repository is publicly reachable at the declared URL. - Cryptographically verified build provenance (signed, bound to CordilleraSarl/clearotron). - Clear OSI-approved license (AGPL-3.0-only). - Actively maintained (last published 0 days ago). - Publishes a security disclosure policy (SECURITY.md). - **Schema Quality & AI Usability**: 38/100 - 7% of prompts and resources have a non-trivial description (not blank, and not just the item's name). - AI-judged instruction clarity (good). - Context-footprint check failed: tool/resource definitions use about 11551 tokens (~251/item across 46 items; 32 tools + 14 resources), over budget; trim descriptions and params. - Usage-examples check failed: none of the tools include examples. - **Stability & Change Management**: 60/100 - Stability observed for 18 of 30 days with no destabilising changes; credit accrues until the full window elapses. - **Tool Coverage**: 84/100 - 100% of tools have a non-trivial description (not blank, and not just the tool's name). - 51% of tool parameters carry a description. - **Tool Safety**: 75/100 - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured. - 0 of 1 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation; "what_if_run" implies "execute" and declares no destructiveHint at all, which the MCP spec reads as destructive by default. - An AI judge read all 34 captured unit(s) of tool text and found none that tries to manipulate the model reading it. - **Capabilities**: 100/100 - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28. ## Install ### How do I install the io.github.CordilleraSarl/clearotron MCP server? io.github.CordilleraSarl/clearotron runs locally as an npm package, launched with npx -y clearotron. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation. ### Claude ```bash claude mcp add cordillerasarl-clearotron -- npx -y clearotron ``` ### Cursor ```json { "mcpServers": { "cordillerasarl-clearotron": { "command": "npx", "args": [ "-y", "clearotron" ] } } } ``` ### VS Code ```json { "servers": { "cordillerasarl-clearotron": { "command": "npx", "args": [ "-y", "clearotron" ] } } } ``` ### Codex ```bash codex mcp add cordillerasarl-clearotron -- npx -y clearotron ``` ### opencode ```json { "$schema": "https://opencode.ai/config.json", "mcp": { "cordillerasarl-clearotron": { "type": "local", "command": [ "npx", "-y", "clearotron" ], "enabled": true } } } ``` ### OpenClaw ```bash openclaw mcp add cordillerasarl-clearotron --command npx --arg -y --arg clearotron ``` ### Hermes ```yaml mcp_servers: cordillerasarl-clearotron: command: "npx" args: ["-y", "clearotron"] ``` ### Netclaw ```json { "McpServers": { "cordillerasarl-clearotron": { "Transport": "stdio", "Command": "npx", "Arguments": [ "-y", "clearotron" ] } } } ``` ### Vellum ```bash assistant mcp add cordillerasarl-clearotron -t stdio -c npx -a -y clearotron ``` ### Other ```json { "mcpServers": { "cordillerasarl-clearotron": { "command": "npx", "args": [ "-y", "clearotron" ] } } } ``` ## Changelog Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims. ### 2026-11-04 (score 73, +1) - [security regression] Stability: 0.53 → unverified - [security regression] Tool safety: pass → unverified - [security improvement] CVE-2026-118764 no longer affects this package - [functional regression] Capabilities: pass → unverified - [functional regression] Tool coverage: 100 → unverified - [functional regression] Schema quality: 7 → unverified - [functional] Package version: 0.4.1 → 0.5.0 ### 2026-11-02 (score 72, +1) No change was recorded against any check on this day. Stability & Change Management went from 47 to 50. That category is still filling its 30-day observation window: 14 days of observed history at the previous scan, 15 at this one. The score rises as the window fills, whether or not the server changes. ### 2026-10-31 (score 71, +1) - [security regression] CVE-2026-118764 affects this package: high ### 2026-10-29 (score 70, +1) No change was recorded against any check on this day. Stability & Change Management went from 33 to 37. That category is still filling its 30-day observation window: 10 days of observed history at the previous scan, 11 at this one. The score rises as the window fills, whether or not the server changes. ### 2026-10-26 (score 69, +1) No change was recorded against any check on this day. Stability & Change Management went from 23 to 27. That category is still filling its 30-day observation window: 7 days of observed history at the previous scan, 8 at this one. The score rises as the window fills, whether or not the server changes. ### 2026-10-24 (score 68, +1) No change was recorded against any check on this day. Stability & Change Management went from 17 to 20. That category is still filling its 30-day observation window: 5 days of observed history at the previous scan, 6 at this one. The score rises as the window fills, whether or not the server changes. ### 2026-10-22 (score 67, +1) No change was recorded against any check on this day. Stability & Change Management went from 10 to 13. That category is still filling its 30-day observation window: 3 days of observed history at the previous scan, 4 at this one. The score rises as the window fills, whether or not the server changes. ### 2026-10-20 (score 66, +1) No change was recorded against any check on this day. Stability & Change Management went from 3 to 7. That category is still filling its 30-day observation window: 1 days of observed history at the previous scan, 2 at this one. The score rises as the window fills, whether or not the server changes. ## MCP tools (32) ### `brief` (~150 tokens) START HERE for any 'what do you have on X / what did the search find' question — ONE plain-language briefing of a run, in the client-voiced wording (which search product this run was, overall risk in plain words, each conflict in 1–2 plain sentences, any conditions on the result). Facts, never advice. No internal stage names, no risk-formula codes, no model names. Reach for the audit tools (get_run, trace, decision_timeline, get_telemetry) only when the user asks HOW the system reached a conclusion. Input parameters: - `runId` (string, required): The run's full runId (slug-date-codename) OR just its codename. ### `list_runs` (~388 tokens) List the searches this session can see (in progress and finished), newest first. A session may hold more than one client, so the list is NOT one client's: every row names the client it was run for, and the project where there is one. TO FIND ONE CLIENT'S SEARCHES, pass `mark` with the client's name — the same name-shaped filter reads the client and the project as well as the mark. TO FIND A SEARCH BY THE NAME IT CLEARED, pass `mark` — the stored identifier is a longer prefixed slug a client has never seen, so a bare mark name will not match `slug`. If a filtered call comes back empty, list unfiltered and read down the mark names before telling anyone there is nothing there. States: 'postponed' = paused on a provider cap and resuming by itself (resetsAt); 'recovering' = backing off and retrying (recoveryResumesAt); 'parked-for-human' = interrupted mid-search, resumes on the next activation. sendPending:true is the authoritative list of finished searches still owed their delivery notification. Follow up with brief for a plain-language summary of one search. Input parameters: - `agent` (string) - `limit` (number) - `mark` (string): Find a search by NAME: the mark it cleared, the client it was run for, the project it was run under, or the identifier — case-insensitively, on part of the word. This is the parameter a name-shaped q… - `sendPending` (boolean): true = only searches still owed a delivery notification; false = only already-settled ones. - `slug` (string): EXACT identifier match, for a caller that already holds one. A mark name is not a slug — use `mark`. - `state` (string) ### `list_profiles` (~219 tokens) List the customer ACCOUNTS the firm runs clearotron clearances for (key + name + industry + their PROJECTS) — the roster the intake step resolves a job's profileKey (and optional projectKey) against. profileKey selects that customer's marketplaces, default classes/jurisdictions, report format and risk posture; a project (spec 62) is an engagement UNDER a customer that overlays its own marketplaces/classes/sector/posture. Resolve by JUDGMENT (explicit name, misspelling, or implicit reference); OMIT profileKey for a new/unknown customer (uses the neutral generic profile — a customer who does not exist here yet never blocks a search; tell the requester it is running under the neutral profile, and that their own company can be set up in the portal if they want its framework, territories and marketplaces applied instead); set projectKey only when the request names a specific project in that customer's projects[], else OMIT it (runs on the customer profile); never pick a profile from the sender's email domain. Read-only. ### `get_run` (~88 tokens) ENGINEERING/AUDIT view — full run mechanics: status, every pipeline stage (trigger/outcome), failover facts, artifact validity, and a coverage summary. Use when the user asks how the run executed; for 'what did it find', call brief instead. Input parameters: - `runId` (string, required): The run's full runId (slug-date-codename) OR just its codename. ### `read_artifact` (~164 tokens) Read a run artifact's raw text (or one '# Section', or its front-matter). For briefing a person, the report is the plain-language layer; the rest are internal working documents. Names: report, audit, narrative, registerFindings, commonLaw, placement, matterContext, variantManifest, skepticFlags, seniorEyeReview, caseLaw, clientSummary (internal cover-note source; ops only), a register axis (e.g. primary-sweep), status.json, run.jsonl. Input parameters: - `frontMatterOnly` (boolean) - `name` (string, required) - `runId` (string, required): The run's full runId (slug-date-codename) OR just its codename. - `section` (string): Return only this '# Section'. ### `list_evidence` (~137 tokens) The records this search considered — every register and common-law entry, including ones the report does not name individually. Each carries the mark, owner and country, the classes, the register status, the source link, whether the provider record was actually retrieved (`retrieved`), and `superseded: true` if a later pass withdrew it. Use this to answer 'what exactly did you find, and who owns it?'. Filter with layer: register | common-law. Input parameters: - `layer` (string) - `runId` (string, required): The run's full runId (slug-date-codename) OR just its codename. ### `list_searches` (~144 tokens) What the search looked for and where — the searches that came back empty as well as the ones that surfaced something. Each row carries the term, the match shapes tried (exact, fuzzy, phonetic, transliteration…), the classes and jurisdictions, the register office where one was named, and the outcome (no-hit | found | out-of-scope | screened-out | excluded-own-rights | negligible). This is the defensibility record: proof of where the search looked and found nothing. Filter by outcome. Input parameters: - `outcome` (string) - `runId` (string, required): The run's full runId (slug-date-codename) OR just its codename. ### `get_search_coverage` (~109 tokens) What the search covered and what is still open, in the report's own words — each area with its state (Searched — clean / Partially covered / Open item / Not run this run). An area that is not clean is NOT cleared: read it as open. Reach for this whenever a result looks clean and the user is about to rely on it. Input parameters: - `runId` (string, required): The run's full runId (slug-date-codename) OR just its codename. ### `list_findings` (~119 tokens) Structured findings from the deterministic audit. kind: findings (default) | negatives | audit (audit-trail). Filter by sourceLayer (Register/Common-law). Pass group (on-field/off-field/out-of-scope) to get the curated report cards instead — the cards' one-liners are already plain-language. Input parameters: - `group` (string) - `kind` (string) - `runId` (string, required): The run's full runId (slug-date-codename) OR just its codename. - `sourceLayer` (string) ### `get_finding` (~61 tokens) One finding/negative/audit-trail record by id (F#, NR#, AT#). Input parameters: - `id` (string, required) - `runId` (string, required): The run's full runId (slug-date-codename) OR just its codename. ### `trace` (~243 tokens) ENGINEERING/AUDIT view — HOW a conclusion was reached; use only when the user asks how/why, not for briefing findings. Walks the full logic flow from any target (a stage, an artifact name, a finding id, or 'verdict') back through the stage that emitted it (and whether a failover occurred), its inputs (with sha-at-consumption vs now), the audit-trail rationale, search terms + record URL, skeptic escalations, and the refutation verdict. Pass shallow:true for a fast skeleton (stage→input lineage + verdict only; skips the findings rebuild and the live provider-usage tally). Input parameters: - `depth` (number): upstream recursion depth (default 2) - `runId` (string, required): The run's full runId (slug-date-codename) OR just its codename. - `shallow` (boolean): Fast skeleton: lineage + verdict only, skipping the slow enrichments. Use when a full trace is slow or you only need the chain. - `target` (string, required): stage | artifact | finding id (F#/NR#/AT#) | 'verdict' | a mark/owner substring ### `get_telemetry` (~114 tokens) ENGINEERING/AUDIT view — per-run + per-stage execution telemetry (models, tokens, wall, failovers, fail reasons) from run.jsonl + the per-attempt logs. The ONLY tool that reports model identity — keep model names out of answers unless explicitly asked. Pass stage (+axis) to focus. Input parameters: - `axis` (string) - `runId` (string, required): The run's full runId (slug-date-codename) OR just its codename. - `stage` (string) ### `get_provider_usage` (~76 tokens) ENGINEERING/AUDIT view — billed register-search provider call counts for the run, RECOMPUTED live from the ledger (more correct than the cached value) with a drift/low-confidence flag. Input parameters: - `runId` (string, required): The run's full runId (slug-date-codename) OR just its codename. ### `get_coverage` (~67 tokens) What was searched vs what's a gap: per-register-axis presence/validity, the coverage-ledger marker, negative-results count, and per-artifact validity. Input parameters: - `runId` (string, required): The run's full runId (slug-date-codename) OR just its codename. ### `search` (~153 tokens) Keyword search across one run's artifacts (single-run scope), ranked. mode 'all' (default) = every query word must appear on the line, any order (so 'MYRKUR similar mark conflict' matches a line about all four); 'any' = ≥1 word, ranked by how many; 'phrase' = the exact substring (old behaviour). Returns {artifact, line, score, snippet}. Optional kind to scope to one artifact. Input parameters: - `kind` (string) - `limit` (number) - `mode` (string) - `query` (string, required) - `runId` (string, required): The run's full runId (slug-date-codename) OR just its codename. ### `decision_timeline` (~130 tokens) ENGINEERING/AUDIT view — the run's DECISION timeline: an ordered milestone list projected from the event log — stages (with trigger and a 'changedFromPrevious' marker when a stage was recomputed), skeptic escalations (with the reason), the verdict(s) (with the reviewer's head note), screen-gates, and the terminal outcome. Answers 'how did the verdict evolve?' in one call; for 'what did it find', call brief instead. Input parameters: - `runId` (string, required): The run's full runId (slug-date-codename) OR just its codename. ### `run_changes` (~148 tokens) Change-feed for monitoring a live run: the timeline events since a timestamp, plus a cursor to poll with. MCP has no push, so poll again with since=cursor. Optional kinds[] to filter event kinds (e.g. ['verdict','skeptic-escalation','failed']). Input parameters: - `kinds` (array): Optional event-kind filter. - `runId` (string, required): The run's full runId (slug-date-codename) OR just its codename. - `since` (string): Poll cursor — a stable sequence number from a prior call's `cursor` (preferred), OR an ISO timestamp for the first call. Returns only newer events; omit for the full timeline. ### `diff_artifact` (~240 tokens) Diff two versions of an artifact (what actually changed between them). Versions exist only when something snapshotted them — an in-place re-dispatch (_history) or a what-if experiment (_experiments); the automated escalation/correction overwrites in place, so a normal run has only 'canonical' and there's nothing to diff (reported honestly). Defaults: a=canonical, b=newest snapshot. Input parameters: - `a` (string): ref for THIS run: canonical | _history/ | _experiments/ (must be a real snapshot of this artifact; absolute/`..` paths are rejected). Default canonical. - `axis` (string): Required (and validated against the known axes) only if name is a bare 'register-unit'. - `b` (string): ref (same grammar as a). Default = newest _history snapshot for this artifact. - `name` (string, required): Artifact: registerFindings, narrative, report, placement, a register axis (e.g. primary-sweep), … - `runId` (string, required): The run's full runId (slug-date-codename) OR just its codename. ### `search_runs` (~158 tokens) Cross-run search across ALL runs (in-flight + archived) — e.g. 'has the MYRK- root shown up in prior clearances?'. scope: findings (default; the mark/owner/search-term columns — cheapest), audit, key-artifacts (report+registerFindings+commonLaw+narrative), or all-artifacts (full text, most expensive). Same ranked all|any|phrase modes as search. Capped by maxRuns. Input parameters: - `agent` (string) - `limit` (number) - `maxRuns` (number) - `mode` (string) - `query` (string, required) - `scope` (string) - `slug` (string) - `state` (string) ### `what_if_plan` (~294 tokens) DRY-RUN a what-if (no spend), in one of two kinds. kind 'stage' (the default) re-runs a single stage of a LIVE run: what re-runs, the cost prior, what downstream is NOT recomputed, a completeness verdict, and a confirmationToken — pass `stage`, and express the change via instructions (e.g. 'treat ACME as expired') and/or model. kind 'memo' answers a what-if about a DELIVERED report instead: a bounded re-read of that run's archived findings and records under a stated assumption, spending model tokens only — no searching, no register calls, and the report and its archive are never modified. A memo takes no stage; put the reader's own words in `instructions`. Input parameters: - `axis` (string) - `instructions` (string): For kind 'memo' this is REQUIRED and is the assumption to apply, in the reader's own words. - `kind` (string): 'stage' (default) re-runs one stage of a live run; 'memo' reasons over a delivered run's archived evidence. - `model` (string) - `runId` (string, required): The run's full runId (slug-date-codename) OR just its codename. - `stage` (string): Required for kind 'stage'. A memo re-runs no stage and must not pass one. ### `what_if_run` (~131 tokens) EXECUTE a planned what-if (SPENDS tokens / maybe billed calls): re-runs ONE stage in a sandbox (original untouched) and diffs it. Requires the confirmationToken from what_if_plan. Approval-gated — confirm cost before calling. Over the client connector this QUEUES the experiment on the server and returns an experimentId instead of a diff — pass `runId` too, and collect the result with what_if_result. Input parameters: - `confirmationToken` (string, required) - `runId` (string): The run's full runId (slug-date-codename) OR just its codename. ### `what_if_result` (~114 tokens) Collect a QUEUED what-if: its state (queued | running | done | failed) and, once done, the diff against the canonical run. Pass runId and the experimentId what_if_run returned; omit experimentId to list every what-if asked of this run. The original run is never modified — the experiment lives in its own sandbox. Input parameters: - `experimentId` (string) - `runId` (string, required): The run's full runId (slug-date-codename) OR just its codename. ### `describe_options` (~250 tokens) START HERE before composing a search — the option space, for free. Returns the four searches this deployment can actually run — each with the geography it accepts, how many names it reads, its turnaround, whether it carries the case-law reading, whether the native-language investigation is optional or automatic, and a plain note when one is unavailable — plus the combination rules the servers enforce (territories, native-language routing, marketplaces, classes, names per search), and — for a client connector — YOUR OWN account: its key (the profileKey plan_run and start_run require), its projects, its saved searches (the recipeKey slugs) and what is left of today's allowance. Omit profileKey to be answered about your own account(s); pass it to ask about a specific one. Reserves nothing, spends nothing, starts nothing. Then: plan_run (free) with the arguments you intend, and start_run with the SAME arguments once the requester has confirmed. Input parameters: - `profileKey` (string): OPTIONAL: the customer ACCOUNT key to describe. Omit it to be answered about the account(s) this session holds — that is how a client connector discovers the key it must pass to plan_run/start_run. ### `plan_run` (~1100 tokens) FREE PREVIEW — resolve what a search WOULD do and return it, spending nothing and queueing nothing. Takes the SAME arguments as start_run. Use this BEFORE start_run whenever the requester has not already confirmed the specifics: it reports the PRODUCT that resolves and WHERE it came from (their request, the account default, a saved search, or the territories themselves), the territories and marketplaces that would ACTUALLY be searched, the turnaround, and any blockers as questions to put back. Show the result to the requester; then call start_run with the SAME arguments to actually run it. Nothing here reserves or holds anything. Input parameters: - `campaignShape` (string): Campaign-shape FACTS from the request/client — how the mark will be deployed: standalone brand vs flavour/sub-brand under a NAMED house mark; seasonal/limited vs permanent; launch scale. Verbatim fac… - `classes` (array) - `commercialFlexibility` (string) - `customer` (string) - `customerUnknown` (boolean) - `deadline` (string) - `deliveryRoute` (string): OPTIONAL: how the delivered packet leaves — email (default). "portal" is reserved for the portal delivery lane and CLARIFIES at admission until it ships (never a silent no-op) — so the preview BLOCKS… - `forwarder` (string, required): Requester/reply-routing key — same as start_run, so the preview describes the job that would actually be built. Account sessions may omit it — it is stamped from your verified identity. - `forwarderEmail` (string) - `goods` (string) - `jurisdictions` (array): WHERE the search points — and, for a clearance, WHICH search it is: one country is a full-country-search, a region or two-or-more countries a multi-country-focus-search. AUTHORITATIVE (the matter fra… - `markName` (string): The mark (single-mark form). REQUIRED unless marks[] is given. - `marks` (array) - `nativeLanguage` (boolean): OPTIONAL, and only on a multi-country-focus-search: the native-language investigation. Send TRUE or omit the field — FALSE IS REFUSED, not honoured: the toggle only ever added, so there is nothing fo… - `platforms` (array) - `priorUse` (string) - `product` (string): WHICH of the four searches. "knockout-search" — worldwide, or any set of territories; up to 8 names. "global-preliminary-search" — worldwide, and nothing else; up to 1 name. "multi-country-focus-sear… - `profileKey` (string): The customer ACCOUNT key (see list_profiles). OMIT it for a new or unknown client and the search runs under the neutral generic profile, which is never a reason to refuse a search — offer that and th… - `projectKey` (string) - `recipeKey` (string) - `ref` (string) - `upfrontInstructions` (string) - `worldwide` (boolean): Search EVERYWHERE, and refuse to be narrowed by the account's own default territories. This is not the same as omitting jurisdictions, which means "whatever the account says" — the two used to be ind… ### `start_run` (~1522 tokens) OPS-ONLY. Enqueue a NEW clearance/search run the driver will pick up. Provide markName (or marks[] for a batch) + forwarder (and ideally classes/goods/customer/profileKey/ref). Returns the queue id + slug; the runId/codename is assigned when the runner claims it — poll list_runs (by markName) or run_changes for progress. Spends real money once it runs. Input parameters: - `agent` (string): Which agent workspace's queue. An assistant passes its own agent id: the run's events name the queue's agent, and a courier takes only its own. Omitted, the job goes to the deployment default (CLEARO… - `brief` (string) - `campaignShape` (string): Campaign-shape FACTS from the request/client — how the mark will be deployed: standalone brand vs flavour/sub-brand under a NAMED house mark; seasonal/limited vs permanent; launch scale. Verbatim fac… - `classes` (array): Nice classes — whole numbers 1–45 (1–34 goods, 35–45 services). classes OR goods; either suffices. - `clientPrincipal` (boolean): Set by the client portal only: this run was started by a CLIENT and consumes that account's runCaps.dailyRuns allowance. Omit for staff, agent and email-door runs — absence means uncapped, and settin… - `commercialFlexibility` (string) - `conversationId` (string) - `customer` (string) - `customerUnknown` (boolean) - `deadline` (string): ISO-8601 — drives the deadline envelope. - `deliverableSpec` (string) - `deliveryRoute` (string): OPTIONAL: how the delivered packet leaves — email (default). "portal" is reserved for the portal delivery lane and CLARIFIES at admission until it ships (never a silent no-op). - `dupOverride` (boolean): Requester-confirmed force-run past matter dedup. - `forwarder` (string, required): Requester/reply-routing key — rides the delivery packet so the integrator knows who gets the report (docs/DELIVERY.md). Account sessions may omit it — it is stamped from your verified identity. - `forwarderDomain` (string) - `forwarderEmail` (string) - `goods` (string) - `id` (string) - `jurisdictions` (array): WHERE the search points — and, for a clearance, WHICH search it is: one country is a full-country-search, a region or two-or-more countries a multi-country-focus-search. AUTHORITATIVE (the matter fra… - `markName` (string): The mark (single-mark form). Required unless marks[] is provided. - `marks` (array): Batch form: EVERY name of the batch in ONE job. Only a knockout-search reads more than one name at a time; a clearance reads one, and more is refused rather than truncated. - `msgId` (string) - `nativeLanguage` (boolean): OPTIONAL, and only on a multi-country-focus-search: the native-language investigation. Send TRUE or omit the field — FALSE IS REFUSED, not honoured: the toggle only ever added, so there is nothing fo… - `parentRunId` (string): OPTIONAL escalation lineage: the runId this run escalates from (e.g. a knockout HIGH mark → this clearotron). - `platforms` (array): OPTIONAL per-run SCOPE: extra marketplaces to sweep, as bare store domains e.g. ["gnc.com"]. ADDED to the account's own marketplaces — additive only, never a replacement (a client's platform list is… - `priorUse` (string) - `product` (string): WHICH of the four searches. "knockout-search" — worldwide, or any set of territories; up to 8 names. "global-preliminary-search" — worldwide, and nothing else; up to 1 name. "multi-country-focus-sear… - `profileKey` (string): The customer ACCOUNT key (see list_profiles) whose profile rates this run; omit for the neutral generic profile — that is how a clearance for a NEW client runs, and a client with no account yet is ne… - `projectKey` (string): OPTIONAL (spec 62): the PROJECT/engagement key UNDER profileKey (see that customer's projects[] in list_profiles) whose overlay rates this run; omit to run on the customer profile. An unknown key cla… - `provider` (string) - `rawRequest` (string) - `recipeKey` (string): OPTIONAL alternative selector: a saved search (recipe) slug for this customer. Mutually exclusive with product — a saved search already carries one. - `ref` (string) - `upfrontInstructions` (string) - `worldwide` (boolean): Search EVERYWHERE, and refuse to be narrowed by the account's own default territories. This is not the same as omitting jurisdictions, which means "whatever the account says" — the two used to be ind… ### `stop_run` (~518 tokens) OPS-ONLY. Cancel a run. Pass id to remove a not-yet-claimed queued job (a real cancel, no spend). Pass runId to file a cancel request on a started run. By default the cancel is COOPERATIVE — the sentinel is written and a turn already in flight is allowed to finish, which has no deadline: a reasoning turn can run for tens of minutes. Add immediate:true to also end that turn: it is sent a stop, anything of it still running a few seconds later is killed, and the answer says the turn ended only once it has seen it end. If it could not be ended, the run ends at its next step boundary, and the answer says that instead. Input parameters: - `agent` (string) - `id` (string): A queued job id (from start_run) — dequeues before the runner claims it. - `immediate` (boolean): Stop NOW instead of at the next step boundary. The cancel sentinel is written FIRST and then the run's own recorded engine turn is stopped, in that order — the sentinel is what makes the record clean… - `onBehalfOf` (string): The identifier of a human this caller has itself verified. RECORDED BESIDE the token's own principal, never instead of it — a stop by the portal for alice@x is written `portal:alice@x`, so an asserte… - `runId` (string): A started run's runId — files a cancel sentinel. ### `server_info` (~61 tokens) The AGPL §13 source offer: this server's name, version, licence, source repository and the COMMIT IT IS RUNNING. Callable by every session kind — the offer is owed to whoever interacts with the service. Reads no run and no account data. ### `list_outbox_events` (~68 tokens) Integrator discovery read (docs/DELIVERY.md): every pending outbox event — delivered markers plus the self-contained run-failed / intake-rejected / duplicate-skipped / late-bind-ack packets. Route each, then mark_sent (delivered) or ack_event (the rest). ### `get_delivery_packet` (~61 tokens) The run's send payload: _driver/delivery.json (subject, recipient routing, verbatim emailBodyHtml, whatsapp line) and/or failure.json, plus sendPending/.sent state. NOT exposed to client tokens. Input parameters: - `runId` (string, required) ### `ack_event` (~55 tokens) OPS-ONLY. Consume ONE routed outbox event by its file name (from list_outbox_events). Idempotent (ok+alreadyGone). The delivered marker is instead cleared by mark_sent. Input parameters: - `file` (string, required) ### `mark_sent` (~179 tokens) OPS-ONLY. Integrator write-back after sending a delivered run's packet (docs/DELIVERY.md step 3): writes the .sent idempotency guard, clears status.sendPending, removes the outbox marker. Idempotent — an already-sent run returns ok+alreadySent. SETTLING REQUIRES EVIDENCE: pass messageId or attestation, or the call refuses. Never call this for a send that was blocked or failed — leave the marker so the send stays owed. Input parameters: - `attestation` (string): Out-of-band evidence when there is no messageId: an explicit statement of how the packet actually reached the reader (channel + when), recorded VERBATIM in .sent. - `messageId` (string): The sent email's messageId — the send receipt. - `runId` (string, required) ### `feed_context` (~69 tokens) OPS-ONLY. Late-bind context onto a run: the applicant + exclusions (written as customer-bind.json, the pipeline's pre-start applicant bind). Use to resolve a customer-unknown run. Input parameters: - `customer` (string) - `exclusions` (array) - `runId` (string, required) ## Diagnostics Captured diagnostic sections: Provenance, Install scripts, Vulnerabilities, Dependencies. The full working is on the page: https://verifymcp.io/servers/cordillerasarl-clearotron/clearotron#diagnostics ## Score history - 2026-11-05: 73 - 2026-11-04: 73 - 2026-11-03: 72 - 2026-11-02: 72 - 2026-11-01: 71 - 2026-10-31: 71 - 2026-10-30: 70 - 2026-10-29: 70 - 2026-10-28: 69 - 2026-10-27: 69 - 2026-10-26: 69 - 2026-10-25: 68 - 2026-10-24: 68 - 2026-10-23: 67 - 2026-10-22: 67 - 2026-10-21: 66 - 2026-10-20: 66 - 2026-10-19: 65 - 2026-10-18: 65 ## Common questions ### What is the io.github.CordilleraSarl/clearotron MCP server? io.github.CordilleraSarl/clearotron is an MCP server listed in the public MCP registry as io.github.CordilleraSarl/clearotron. Clearotron, trademark clearance that shows its work. This page covers its npm package (clearotron). ### Is the io.github.CordilleraSarl/clearotron MCP server safe to use? io.github.CordilleraSarl/clearotron scores 73 out of 100 on VerifyMCP. We recorded 1 known advisory against it as of 5 November 2026. It declares an install script we flagged as high risk. Its build provenance is signed and verified. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm. ### What tools does the io.github.CordilleraSarl/clearotron MCP server expose? io.github.CordilleraSarl/clearotron exposes 32 tools: brief, list_runs, list_profiles, get_run, read_artifact, and 27 more. Their descriptions and schemas cost roughly 7,330 tokens of context every time the server is loaded. ### Is the io.github.CordilleraSarl/clearotron MCP server still maintained? io.github.CordilleraSarl/clearotron is still listed as active in the MCP registry. We last reached this channel on 5 November 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced. ### What licence is the io.github.CordilleraSarl/clearotron MCP server under? io.github.CordilleraSarl/clearotron declares the AGPL-3.0-only licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls. ## Links - npm package: https://www.npmjs.com/package/clearotron - Socket report: https://socket.dev/npm/package/clearotron - Repository: https://github.com/CordilleraSarl/clearotron - Changelog RSS feed: https://verifymcp.io/servers/cordillerasarl-clearotron/clearotron.xml - Changelog JSON feed: https://verifymcp.io/servers/cordillerasarl-clearotron/clearotron.json - HTML version of this page: https://verifymcp.io/servers/cordillerasarl-clearotron/clearotron