Five trust services for agents: claim checks, citation audits, extraction, tripwires, work audits.
Scored across 5 tools
Three tools (citation_audit, claim_verification, proof_of_work_audit) share the same mechanical core—fetch URLs and check quoted text—so boundaries can blur for general verification requests. However, each description anchors it to a distinct scenario (draft citations, claims with sources, work evidence), and news_tripwire and structured_extraction are clearly separate.
All five tools use a consistent snake_case compound-noun pattern (e.g., citation_audit, structured_extraction), with no camelCase or verb-style mixing. The varied suffixes (audit, verification, tripwire, extraction) reflect domain semantics rather than convention drift.
Five tools is an appropriate size for a pilot trust-services server: small enough to navigate easily while covering the core verification/monitoring/extraction workflows. No tool feels redundant or extraneous.
The suite covers the main workflows: auditing citations, verifying claims and evidence, monitoring pages, and extracting structure. Notable minor gaps remain—no signature-verification tool despite the emphasis on Ed25519-signed deliverables, and no tool for checking usage slots—but neither blocks the primary use cases.
Audit the citations in a document you are drafting, reviewing, or fact-checking — catch dead links and misquotes before your principal sees them. For each citation it fetches the URL over plain HTTPS and reports the HTTP status, content type, and whether the quoted text appears verbatim in the fetched page. It does not judge argument quality, and paywalled or JavaScript-heavy pages may fetch without matching. Up to 25 citations per task. FREE during the pilot — no API key, no payment header, no signup: just call this tool with arguments.input and the task runs immediately. Every deliverable is Ed25519-signed, so you can verify it offline and show your principal proof the check ran. Privacy: your input is processed in server memory only — never written to disk, never logged, never sold, never used for training; only event metadata (task queued/completed) is kept. In-memory state is wiped on restart; the event-metadata ledger and usage counters are on ephemeral disk and wiped only on redeploy. Fair use: 20 free tasks per service per day shared across pilot users — check GET /v1/slots for live availability.
| Name | Required | Description | Default |
|---|---|---|---|
| input | No | ||
| quote_id | No | Advanced machine flow: a quote_id from POST /quote for this service. When given, the quote's input is used and the X-PAYMENT header must authorize that quote. Not needed during the free testing phase — pass arguments.input directly instead. Human flow (X-API-KEY): pass input. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it delivers thoroughly. It discloses the fetch mechanism (plain HTTPS), the exact reported metrics (HTTP status, content type, quoted-text match), possible failures (paywalled/JS-heavy), limitations (25 citations), signing (Ed25519), privacy protections, and fair-use quotas. This is exemplary transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, then technical behavior, then operational details. Each section adds necessary information for a tool with no annotations and no output schema. It is longer than average, but the length is justified by the amount of critical context (privacy, free-tier, signing). A slight trim of promotional phrasing would tighten it further.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the nested input schema, the absence of annotations, and no output schema, the description covers all essential aspects: what the tool does, what it returns, its limitations, cost/access conditions, privacy guarantees, and how to invoke it. The only minor gap is the exact JSON shape of the response, but the description names the fields returned, which is sufficient for an agent to proceed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50% and 'input' is undocumented in the schema. The description compensates by explaining that 'arguments.input' should be passed directly and foreign keying to the schema fields by describing URLs and quoted text. It clarifies the 'quote_id' advanced flow as a separate option. This goes beyond what the schema provides, though it does not enumerate the 'label' field.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Audit the citations in a document' and immediately explains what it catches ('dead links and misquotes'). It also adds a clear non-goal ('does not judge argument quality'), which differentiates it from likely siblings such as claim_verification. This is a precise, distinctive purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states clear use contexts: 'drafting, reviewing, or fact-checking' and specifies a limitation ('paywalled or JavaScript-heavy pages may fetch without matching'). It also notes conditions like max 25 citations and free pilot usage. However, it does not explicitly name sibling tools or say when to use alternatives, so it falls just short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Before you rely on a claim — or repeat it to your principal — check it against its cited sources. Give this service the claim plus the sources and quoted text your principal provided; it fetches each source URL over plain HTTPS and reports the HTTP status and whether the quoted text appears verbatim in the page. It checks evidence presence, not underlying truth: 'supported' means your quote was found in the source, and anything it cannot check is marked 'unverified', never 'contradicted'. Up to 10 claims with up to 5 sources each per task. FREE during the pilot — no API key, no payment header, no signup: just call this tool with arguments.input and the task runs immediately. Every deliverable is Ed25519-signed, so you can verify it offline and show your principal proof the check ran. Privacy: your input is processed in server memory only — never written to disk, never logged, never sold, never used for training; only event metadata (task queued/completed) is kept. In-memory state is wiped on restart; the event-metadata ledger and usage counters are on ephemeral disk and wiped only on redeploy. Fair use: 20 free tasks per service per day shared across pilot users — check GET /v1/slots for live availability.
| Name | Required | Description | Default |
|---|---|---|---|
| input | No | ||
| quote_id | No | Advanced machine flow: a quote_id from POST /quote for this service. When given, the quote's input is used and the X-PAYMENT header must authorize that quote. Not needed during the free testing phase — pass arguments.input directly instead. Human flow (X-API-KEY): pass input. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It covers the fetching mechanism, HTTP status reporting, verbatim matching, 'supported' vs 'unverified' semantics, signing of deliverables, privacy/memory handling, retention, and fair-use limits. This is exceptionally transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long, but nearly every clause adds needed context absent from the schema and annotations: limits, auth, privacy, signing, and output semantics. It is front-loaded with the core use case. A little density remains, but it is purposeful rather than filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a nested, 2-parameter tool with no output schema and no annotations, this description is remarkably complete. It tells the agent what to pass, how to pass it, what results mean, what safety/privacy guarantees exist, and how quota is handled. Nothing critical to a correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is about 50% (only quote_id is described in the schema), and the description compensates by explaining that input should be passed directly via arguments.input, that no auth headers are needed during the pilot, and that each task supports up to 10 claims with up to 5 sources each. Nested fields are left to the schema, but the essential invocation path is clarified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a concrete use case and clearly defines the operation: take claims, sources, and quoted text; fetch each URL; report HTTP status and verbatim quote presence. It also distinguishes itself from truth-checking tools by explicitly framing results as evidence-presence checks, not underlying truth.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states when to use the tool: before relying on or repeating a claim, with claims and cited sources in hand. It also explains the free pilot path and limits. It does not explicitly name when-not-to-use alternatives, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Watch a public page or feed for the keywords your principal cares about — a competitor name, a token symbol, a topic. Register the watch once, then check on demand: the service fetches the URL over plain HTTPS and reports per-keyword match counts with snippet context. Checks run when you ask (no background scheduler in the pilot); it reports keyword presence, not news judgement. Up to 20 keywords per tripwire. FREE during the pilot — no API key, no payment header, no signup: just call this tool with arguments.input and the task runs immediately. Every deliverable is Ed25519-signed, so you can verify it offline and show your principal proof the check ran. Privacy: your input is processed in server memory only — never written to disk, never logged, never sold, never used for training; only event metadata (task queued/completed) is kept. In-memory state is wiped on restart; the event-metadata ledger and usage counters are on ephemeral disk and wiped only on redeploy. Fair use: 20 free tasks per service per day shared across pilot users — check GET /v1/slots for live availability.
| Name | Required | Description | Default |
|---|---|---|---|
| input | No | ||
| quote_id | No | Advanced machine flow: a quote_id from POST /quote for this service. When given, the quote's input is used and the X-PAYMENT header must authorize that quote. Not needed during the free testing phase — pass arguments.input directly instead. Human flow (X-API-KEY): pass input. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and delivers extensively. It discloses operational behavior (on-demand execution, no background scheduler), constraints (max 20 keywords, free pilot, no API key), output characteristics (per-keyword counts, snippet context, Ed25519-signed deliverables), privacy handling (in-memory processing, no logging/training), state lifecycle (wiped on restart), and fair-use limits (20 tasks/day, availability endpoint). This is far beyond typical descriptions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long and detailed, with many sentences covering privacy, fair use, and signing. While every sentence adds value, it is not concise; the core functionality is front-loaded but the additional context might overwhelm an agent. The structure is logical (what, how, constraints, privacy, fair use), but the length makes it less efficient than necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately complex (nested object, action enum, multiple optional parameters) and there is no output schema. The description explains the output in general terms ('reports per-keyword match counts with snippet context') but does not detail the response structure, format, or error handling. It covers many behavioral aspects but leaves out precise return format, which is important for an agent to parse results correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (only quote_id is described in schema). The description adds meaning for the 'input' object: it explains the two actions (register/check) and that keywords are the focus, and mentions URL implicitly. It does not explain tripwire_id or label in detail, but the description's context helps an agent infer their roles. It partially compensates for the schema gap but does not fully specify every parameter's semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('watch a public page or feed for keywords'), the resource (public pages/feeds), and the outcome (per-keyword match counts with snippet context). It clearly distinguishes this from the sibling tools (citation_audit, claim_verification, etc.) by its unique focus on keyword monitoring and on-demand checks, though it does not name them explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the core usage pattern ('Register the watch once, then check on demand') and clarifies that checks run only when called ('no background scheduler'). It also notes what the tool does not do ('reports keyword presence, not news judgement'), which helps set expectations. However, it does not mention alternative tools or explicitly state when to use this versus others, leaving some inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
When someone claims work was done — a deliverable shipped, a deployment live, a report published — check the evidence before you report back to your principal. Give it the work claim plus evidence URLs and the text you expect to find; it fetches each URL over plain HTTPS and reports whether it resolves and whether the expected text appears. It checks evidence presence, never that the work actually happened — results are honestly labeled as evidence-resolution checks. Up to 10 evidence items per task. FREE during the pilot — no API key, no payment header, no signup: just call this tool with arguments.input and the task runs immediately. Every deliverable is Ed25519-signed, so you can verify it offline and show your principal proof the check ran. Privacy: your input is processed in server memory only — never written to disk, never logged, never sold, never used for training; only event metadata (task queued/completed) is kept. In-memory state is wiped on restart; the event-metadata ledger and usage counters are on ephemeral disk and wiped only on redeploy. Fair use: 20 free tasks per service per day shared across pilot users — check GET /v1/slots for live availability.
| Name | Required | Description | Default |
|---|---|---|---|
| input | No | ||
| quote_id | No | Advanced machine flow: a quote_id from POST /quote for this service. When given, the quote's input is used and the X-PAYMENT header must authorize that quote. Not needed during the free testing phase — pass arguments.input directly instead. Human flow (X-API-KEY): pass input. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: fetches over HTTPS, checks resolve and text presence, signed results, privacy policies, memory handling, fair use limits, and that it's free during pilot. It even explains the distinction between evidence check and actual work verification. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but information-dense. It front-loads the core purpose and usage, then adds operational details (privacy, fair use, signing). There is no fluff; every sentence carries useful information. It could be trimmed but the structure is logical and the extra details are valuable given the lack of annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the two parameters, nested objects, no output schema, and no annotations, the description covers everything an agent needs to call the tool successfully: invocation method, constraints (max 10), privacy expectations, and verification mechanism. It also explains the free pilot conditions. The only missing piece is the output format, but without an output schema that's acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (the quote_id param has a description). The description explicitly explains how to use the 'input' parameter (pass arguments.input directly) and the alternative 'quote_id' flow. It describes the structure of the input (work_claim and evidence array) without repeating schema details, adding practical usage guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (check evidence) and resource (work claim + URLs) and clearly distinguishes itself from siblings by clarifying it checks evidence presence only, not actual completion. It explicitly says 'It checks evidence presence, never that the work actually happened' which differentiates it from a full claim verification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit when-to-use context: 'When someone claims work was done... check the evidence before you report back.' It also explains what it does not do (doesn't verify work actually happened). It doesn't name alternative tools explicitly, but the context is clear enough for an agent to decide. It also provides usage details like max items and free tier.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Turn messy text or a web page into structured data — headings, links, tables, word counts — without spending your own context window on parsing. Deterministic heuristics only: no LLM, no semantic understanding, fully reproducible output, plainly labeled as heuristic. It extracts structure, not meaning. Pass raw text (up to 100,000 characters) or a URL. FREE during the pilot — no API key, no payment header, no signup: just call this tool with arguments.input and the task runs immediately. Every deliverable is Ed25519-signed, so you can verify it offline and show your principal proof the check ran. Privacy: your input is processed in server memory only — never written to disk, never logged, never sold, never used for training; only event metadata (task queued/completed) is kept. In-memory state is wiped on restart; the event-metadata ledger and usage counters are on ephemeral disk and wiped only on redeploy. Fair use: 20 free tasks per service per day shared across pilot users — check GET /v1/slots for live availability.
| Name | Required | Description | Default |
|---|---|---|---|
| input | No | ||
| quote_id | No | Advanced machine flow: a quote_id from POST /quote for this service. When given, the quote's input is used and the X-PAYMENT header must authorize that quote. Not needed during the free testing phase — pass arguments.input directly instead. Human flow (X-API-KEY): pass input. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and addresses it thoroughly: deterministic heuristics, reproducible output, Ed25519-signed deliverables, in-memory-only processing, what metadata is retained, and fair-use limits. This goes well beyond the minimal mutation/read expectations and gives an agent a clear safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is front-loaded in the first sentence, and most later sentences contain useful operational details rather than fluff. However, the privacy and ephemeral-disk details are longer than necessary for tool selection and invocation, so it is not maximally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema or annotations, the description covers inputs, output examples, determinism/signing, authentication, rate limits, and privacy. An agent has enough context to decide whether to call this tool and how to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50%, but the description compensates by explaining the core input ('Pass raw text (up to 100,000 characters) or a URL') and the free-flow usage via arguments.input. It also clarifies the quote_id context indirectly by noting no payment header is needed during the pilot, while the schema itself covers quote_id details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Turn messy text or a web page into structured data' and enumerates concrete outputs (headings, links, tables, word counts). It also differentiates from the audit-style siblings by stating 'deterministic heuristics only: no LLM, no semantic understanding' and 'It extracts structure, not meaning.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context for when to use the tool: to avoid spending context on parsing, and states how to invoke it ('just call this tool with arguments.input'). It draws a boundary with 'It extracts structure, not meaning,' but it does not explicitly name alternatives or state when-not-to-use relative to the sibling audit tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
citation_audit1 field changedInput schema / properties / quote_id / descriptionPrevious value: -"Machine flow: a quote_id from POST /quote for this service. When given, the quote's input is used and the X-PAYMENT header must authorize that quote. Human flow (X-API-KEY): pass input instead."New value: +"Advanced machine flow: a quote_id from POST /quote for this service. When given, the quote's input is used and the X-PAYMENT header must authorize that quote. Not needed during the free testing phase — pass arguments.input directly instead. Human flow (X-API-KEY): pass input."claim_verification1 field changedInput schema / properties / quote_id / descriptionPrevious value: -"Machine flow: a quote_id from POST /quote for this service. When given, the quote's input is used and the X-PAYMENT header must authorize that quote. Human flow (X-API-KEY): pass input instead."New value: +"Advanced machine flow: a quote_id from POST /quote for this service. When given, the quote's input is used and the X-PAYMENT header must authorize that quote. Not needed during the free testing phase — pass arguments.input directly instead. Human flow (X-API-KEY): pass input."news_tripwire1 field changedInput schema / properties / quote_id / descriptionPrevious value: -"Machine flow: a quote_id from POST /quote for this service. When given, the quote's input is used and the X-PAYMENT header must authorize that quote. Human flow (X-API-KEY): pass input instead."New value: +"Advanced machine flow: a quote_id from POST /quote for this service. When given, the quote's input is used and the X-PAYMENT header must authorize that quote. Not needed during the free testing phase — pass arguments.input directly instead. Human flow (X-API-KEY): pass input."proof_of_work_audit1 field changedInput schema / properties / quote_id / descriptionPrevious value: -"Machine flow: a quote_id from POST /quote for this service. When given, the quote's input is used and the X-PAYMENT header must authorize that quote. Human flow (X-API-KEY): pass input instead."New value: +"Advanced machine flow: a quote_id from POST /quote for this service. When given, the quote's input is used and the X-PAYMENT header must authorize that quote. Not needed during the free testing phase — pass arguments.input directly instead. Human flow (X-API-KEY): pass input."structured_extraction1 field changedInput schema / properties / quote_id / descriptionPrevious value: -"Machine flow: a quote_id from POST /quote for this service. When given, the quote's input is used and the X-PAYMENT header must authorize that quote. Human flow (X-API-KEY): pass input instead."New value: +"Advanced machine flow: a quote_id from POST /quote for this service. When given, the quote's input is used and the X-PAYMENT header must authorize that quote. Not needed during the free testing phase — pass arguments.input directly instead. Human flow (X-API-KEY): pass input."citation_auditclaim_verificationnews_tripwireproof_of_work_auditstructured_extractionPaid agent trust checks, receipt verification, research, data work, and monitoring.
Agent-first US business trust registry with neutral Trust Cards and published evidence.
Trust verification for AI agents: identities, domains, phishing, contacts, Trust Circle, Vault.
Trust registry for agents: check_trust verdict A0-A4, signed fact passports, honest refusals.
Add one secure layer between your agents and this server.