Clearotron MCP server

Read from the package source without running it. The installed server may list more.

• ack_event

  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.

• band_record

  The OFFICIAL registry record the driver fetched into this run's _records/ for a given record_id (/mark/... uri) — the fetched document itself, for detail the band row does not carry. Cite the uri in whatever form the band, the findings or the provider gave you: case, a wrapping provider URL and the registration-instance suffix are all resolved to the same document. Read-only: it never fetches; an

• band_shape

  The deterministic shape of this run's merged register band: totals, mechanical tiers, the floors (every live in-class identical/near-identical record), each marked on its line in the band in the lawyer's order, class/status/registry/recency census, owner concentrations, crowd descriptors (with crowd-context joins) and blind spots. Read this FIRST, then pull what it names via band_lookup/band_recor

• brief

  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_ru

• decision_timeline

  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', c

• describe_options

  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 enfo

• diff_artifact

  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.

• feed_context

  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.

• fetch_url

  Fetch a public URL over HTTP(S) GET and return the response body as text (read-only). Use for public sources such as EUR-Lex.

• get_coverage

  What was searched vs what's a gap: per-register-axis presence/validity, the coverage-ledger marker, negative-results count, and per-artifact validity.

• get_delivery_packet

  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.

• get_finding

  One finding/negative/audit-trail record by id (F#, NR#, AT#).

• get_provider_usage

  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.

• get_runwrite action

  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.

• get_search_coverage

  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.

• get_telemetry

  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.

• list_evidence

  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 i

• list_findings

  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.

• list_outbox_events

  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).

• list_profiles

  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

• list_runs

  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

• list_searches

  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 defen

• mark_sent

  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

• plan_runwrite action

  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 market

• read_artifact

  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. p

• record_blind_frame

  Hand back your cold threat model as VALUES. The driver serializes it and writes

• record_clearance_variants

  Hand back the variant manifest as VALUES. The driver serialises variant-manifest.json, renders

• record_coverage

  Record your coverage-ledger rulings as VALUES. The driver writes the form — you never open or edit any

• record_coverage_status

  Record the status of each row of your coverage ledger. Send VALUES, not a file: one entry per ledger row, and the driver writes the record. Entries that validate are kept even when others in the same call are refused, and a later entry for the same unit replaces the earlier one.

• record_declination

  Record, per record or page, your decision NOT to deliver something that reached your findings surface.

• record_dispositions

  Record your meaning rulings. Send VALUES, not a file: one entry per row, and the driver writes the document. You type NO identifier of any kind: give `row_index`, the NUMBER printed beside that obligation in the obligations block, and `receipt_index`, the POSITION of the candidate in that row's own list — the driver resolves both. Rows are validated against THAT row as they arrive, so you learn wh

• record_doubt_closure

  Record your closure verdicts as VALUES. The driver applies them to the ledgers and renders the

• record_frame_diff

  Hand back the blind-model-vs-actual-scope diff as VALUES. The driver serializes frame-diff.json

• record_knockout_frame

  Hand back the batch FRAME as VALUES: the plan, and the scope note. The driver serializes

• record_knockout_review

  Hand back your REWRITES of the lines a reader meets first, as VALUES. The driver writes them into

• record_matter_frame

  Hand back the matter frame as VALUES. The driver renders matter-context.md from them — including

• record_narrative_refutation

  Hand back your verdict and your flags as VALUES. The driver renders senior-eye-review.md — the

• record_register_digest

  Hand back the register findings as VALUES. The driver renders register-findings.md — the title,

• record_released_families

  Release the WAITING families on this axis that you decided to ask, each with your reason: why looking wider

• record_report_card

  Hand back THIS finding's card as VALUES. The driver renders the `### Full detail` section, every

• record_report_overview

  Hand back the report SHELL as VALUES. The driver renders report-overview.md — the front-matter it

• record_skeptic

  Hand back your fresh-eyes flags and escalation decisions as VALUES. The driver renders

• record_synthesis

  Hand back your cross-finding narrative as SECTIONS and your findings as the record they already

• record_unit_note

  File this axis's SHORT AUDIT NOTE as values. The driver writes register-units/<axis>.md — you never open

• record_withheld_families

  Record the WAITING families on this axis that you decided NOT to ask, each with your reason. A family you

• register_batch_screen

  Batch-hydrate SCREENING data for many record_ids in one call, chunked at 100/call. Per row: classes/status/owner/dates/jurisdictions/markFeatures + computed live_status, all_class, and a closed-set screen_verdict (the SAME verdict vocabulary every register provider uses). Pass in_scope_classes. NEVER drop a surface:* / deepfetch:* row on a guess without a record_fetch.

• register_enumerate

  ENUMERATE a named band to COMPLETION — the completeness primitive. You choose the query (same fields as register_search); this tool owns the count probe, the OR-stack chunking and the screening, and CANNOT return a partial list. It returns ONE of two states: {state:'enumerated', total_hits, count, records[…batch-screened]} when the whole band was retrieved (every named record, already screened wit

• register_execute_planwrite action

  Execute the run's FROZEN register plan (_driver/register-plan.json) for ONE axis in a single call: the tool runs every dictated entry itself (enumerates to completion; count entries stay count-only crowd descriptors; a when-guarded fringe runs only if its parent slice enumerated) and WRITES the named band to output_path itself, each block stamped with its qid. MERGES with any existing band: your j

• register_expand_phoneme

  Generate phonetic-variant spellings via Corsearch's AI phoneme expansion. Returns { base, aiVariants }. Call before register_search match_mode='phonetic'. Language matters: en_US/de_DE/fr_FR/it_IT/es_ES.

• register_image_fetch

  Fetch figurative-mark image metadata (content type + size, presence) for one or more record_ids (synthetic refs or bare guids). Returns a per-guid summary; defaults to test_mode (set test_mode:false for the live image). Only invoke for records whose detail says an image is available.

• register_propose_supplemental

  PROPOSE judgment-addition register queries; CODE executes them and writes the band (the supplemental lane — you never run register coverage by hand and never author band blocks). Each proposal: {predicate: exact|default|wildcard|phonetic|owner, term OR terms[] (OR-stack, split anything wider than the plan bound), romanization (MANDATORY beside a single non-Latin term — this register indexes non-La

• register_record_fetch

  Fetch the full NORMALIZED detail record(s) for one or more trademarks by record_id (a synthetic /mark/<office>/<guid> ref OR a bare guid). Batched at EXACTLY 100 ids per call; each normalized record is persisted for the driver's citation-fidelity gate. Returns { count, records[…] } with neutral fields (applicationNumber/registrationNumber/dates/statusClass/niceClasses/owner/seniorities/priorities/

• register_search

  Search the register index; returns the COMPLETE set of matching records (this provider has no pagination — one call, the whole guid set) whose record_id is a synthetic /mark/<office>/<guid> ref. Provide at least one element (query/name/names, owner/owners, representative) and regions[] (required). match_mode: default (a TRUE contains)|exact|phonetic (native sound-alike; no variant preview exists o

• run_changeswrite action

  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']).

• search

  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.

• search_run_artifactswrite action

  Search ONE of this run's own artifacts (e.g. register-findings.md, common-law-findings.md) for

• search_runs

  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.

• server_info

  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.

• start_runwrite action

  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.

• stop_runwrite action

  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, anyt

• trace

  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 es

• what_if_plan

  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 boun

• what_if_result

  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.

• what_if_runwrite action

  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_resul

• Code scan1500 source files scanned15/25
• –Live reliabilityno gateway calls yet and no remote to proben/a
• –Tool poisoningtools not inspected (local package is not executed); not countedn/a
• Auth qualitylocal package, no credentials required12/15
• Maintenancelast push 0 days ago15/15
• Maintainer identityregistry namespace matches repository owner7/10

Safety score

75/100

higher than 45% of 48,255 servers

Tools

64

the typical server has 7

Tools that change things

13%

typical: 0%. Fewer write tools means less an agent can break

GitHub stars

2

more than 75% of 28,688 servers

Downloads a week

484

more than 87% of 12,191 servers with a package

Clearotron: common questions

Is Clearotron MCP server safe?

Mostly: it is graded B (75/100). Read the Clearotron safety report

How do I install Clearotron?

It runs on your machine. Copy the Claude Code, Cursor, VS Code or Claude Desktop config from the install section.

Does Clearotron need an API key?

Not as far as the registry entry and our scan can tell: no credentials are declared or required.

Is Clearotron maintained?

The last commit was 7 days ago (2026-10-28). The latest release is v0.4.1.

How does Clearotron compare with other MCP servers?

safety score 75/100 (higher than 45% of 48,255 servers); tools 64 (the typical server has 7); tools that change things 13% (typical: 0%. Fewer write tools means less an agent can break). Full comparison.