Verifiable document intelligence for AI agents. Extract, summarize, claim-check, and notarize PDFs & URLs with cryptographic proofs, cross-document search, and on-chain attestation via Base L2.
Scored across 22 tools
Most tools are clearly separated by resource (bundle, collection, document, url, receipt, job, account) and action. The only mild overlap is between document.extract_text and url.extract (both extract text, but one handles base64 uploads and the other URLs), and between collection.search and collection.ask (raw chunks vs. synthesized answer), but the descriptions explicitly cross-reference each other to reduce confusion.
Tool names follow a consistent resource.action pattern (account.quota, bundle.get, collection.create, document.summarize, url.qa, receipt.verify, job.status). Minor inconsistency: document.parse_invoice is a specialized extraction rather than a generic verb like extract_invoice, and job.status uses a noun rather than a verb, but the overall pattern is predictable.
22 tools is on the higher end but appropriate for a document evidence platform covering bundles, collections, document processing, URL processing, receipts, and jobs. Each tool serves a distinct function, though a few could be consolidated (e.g., url.extract/url.summarize/url.qa/url.translate are four separate URL tools).
The surface covers the core lifecycle well: bundle creation/verification/notarization, collection create/add/search/ask, document extraction/summarization/structured parsing, URL operations, receipts, and job polling. Minor gaps: there is no explicit bundle.delete or collection.delete, and no way to list bundles directly (only via receipts or collections), which could be a dead end for bundle management.
Get current credit balance and plan details for your API key. Free — no credits consumed. Check this before running credit-consuming operations (extract, summarize, etc.) to avoid QUOTA_EXCEEDED errors. Returns plan tier, billing period, and usage breakdown. Returns: { plan_id, billing_period (YYYY-MM), credits_used, credits_limit, credits_remaining, status: "active"|"suspended" } Example prompts:
"How many credits do I have left this month?"
"Check my current quota and plan status."
"Am I going to hit my credit limit soon?"
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| plan_id | Yes | |
| credits_used | Yes | |
| credits_limit | Yes | |
| billing_period | Yes | |
| credits_remaining | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds valuable behavioral context: 'Free — no credits consumed' clarifies that the operation itself has no cost, which is critical for a quota tool. It also discloses the response structure precisely, including the status field with possible values.
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 well-structured and front-loaded: it opens with the core purpose, then adds the no-credits detail and usage timing, followed by a clear return block and example prompts. Every section earns its place, and the length is appropriate.
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 tool's simplicity (no parameters) and the presence of formal annotations plus a detailed return schema in the description, the description covers all essential context: purpose, usage scenario, return payload, and example queries. It is complete for an agent to select and invoke the tool 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?
The tool has zero parameters, so there are no parameter semantics to explain. The description correctly omits parameter details; the empty schema makes this self-evident. Baseline of 4 applies due to 0 parameters.
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 clearly states the tool's function with a specific verb and resource: 'Get current credit balance and plan details for your API key.' It distinguishes from sibling tools by focusing on account/quota status, and specifies the return contents (plan tier, billing period, usage breakdown).
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 explicitly instructs when to use the tool: 'Check this before running credit-consuming operations (extract, summarize, etc.) to avoid QUOTA_EXCEEDED errors.' This provides clear contextual guidance, and the example prompts reinforce typical usage. It does not need alternatives since no competing tool exists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve metadata for an evidence bundle (ev_...) owned by your API key. Free — no credits consumed. Use for quick status/metadata lookups such as checking if a bundle is complete, finding its notarization status, or viewing retention/legal hold info. For deep cryptographic integrity verification (hash + signature + artifact checks), use bundle.verify instead. Also returns a signed action receipt (rcpt_...) binding this lookup to the bundle manifest — list with receipt.list, verify with receipt.verify. Returns: { bundle_id, source_url, mode, status: "pending"|"complete"|"failed", manifest_sha256, manifest_signature, signer_address, attestation_tx, attestation_at, eas_uid, parent_bundle_id, superseded_by, legal_hold: boolean, retention_until, created_at, receipt: ActionReceipt|null } Example prompts:
"Show me the metadata for bundle ev_550e8400."
"Check the status and notarization info of my evidence bundle."
"Get me the details of bundle [ev_id] — is it complete?"
| Name | Required | Description | Default |
|---|---|---|---|
| bundle_id | Yes | Evidence bundle ID (ev_...) returned by extract or bundle.notarize. Example: "ev_550e8400-e29b-41d4-a716-446655440000" |
| Name | Required | Description |
|---|---|---|
| mode | Yes | |
| status | Yes | |
| eas_uid | Yes | |
| receipt | Yes | |
| bundle_id | Yes | |
| created_at | Yes | |
| legal_hold | Yes | |
| source_url | Yes | |
| superseded_by | Yes | |
| attestation_at | Yes | |
| attestation_tx | Yes | |
| signer_address | Yes | |
| manifest_sha256 | Yes | |
| retention_until | Yes | |
| parent_bundle_id | Yes | |
| manifest_signature | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint and idempotentHint, but the description adds meaningful behavior beyond that: it is free ('no credits consumed'), scoped to bundles owned by the API key, and returns a signed action receipt binding the lookup to the manifest. This gives the agent crucial context about side effects and constraints that annotations alone do not cover.
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 usage guidance, alternatives, return fields, and examples. While the return-field list duplicates the output schema, it is presented compactly and every sentence contributes actionable information. It is a bit long but not bloated.
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?
With one parameter, an output schema, and strong annotations, the description still adds substantial value: cost, ownership, alternatives, receipt behavior, and example prompts. It fully equips the agent to decide when to invoke and what to expect.
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?
The input schema fully documents the only parameter (bundle_id) with a clear description and example, so the schema carries the weight. The description repeats this via example prompts but does not add new semantic details beyond what the schema already provides. Baseline 3 is appropriate.
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+resource: 'Retrieve metadata for an evidence bundle (ev_...)' and clearly distinguishes this from bundle.verify by stating it is for quick status/metadata lookups while verification is for deep cryptographic integrity checks. This unambiguously defines the tool's scope.
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 explicitly enumerates use cases ('checking if a bundle is complete, finding its notarization status, or viewing retention/legal hold info') and names an alternative for a different job ('use bundle.verify instead'). It also references companion tools (receipt.list, receipt.verify) for further actions, giving clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Notarize an evidence bundle on-chain by writing its manifest SHA-256 to the blockchain (Base/EVM). Creates a permanent, tamper-evident on-chain record of the document fingerprint. If the bundle is already notarized, returns the existing attestation immediately (idempotent). Use when you need an immutable on-chain timestamp proving a document existed at a point in time. For quick integrity checks without on-chain cost, use bundle.verify instead. Also returns a signed action receipt (rcpt_...) binding this notarize call to the bundle manifest — list with receipt.list, verify with receipt.verify. PREREQUISITE: Bundle status must be "complete". Check status with bundle.get first. NOTE: Costs gas (ETH). The on-chain record is permanent and cannot be deleted even if the bundle is later purged. Returns: { bundle_id, attestation: { tx_hash, network, attested_at, key_id, eas_uid?, schema_uid? }, receipt: ActionReceipt|null } Example prompts:
"Notarize bundle ev_550e8400 on-chain so I have a permanent record."
"Put the fingerprint of my evidence bundle on the blockchain."
"Create an on-chain timestamp for this document bundle."
| Name | Required | Description | Default |
|---|---|---|---|
| bundle_id | Yes | Evidence bundle ID (ev_...) to notarize. Bundle must have status "complete". Example: "ev_550e8400-e29b-41d4-a716-446655440000" |
| Name | Required | Description |
|---|---|---|
| receipt | Yes | |
| bundle_id | Yes | |
| attestation | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavioral context beyond the annotations: idempotency (returns existing attestation if already notarized), gas costs, permanence of the on-chain record even if the bundle is purged, and the signed action receipt returned. No contradictions with annotations; idempotentHint is consistent with the stated idempotent behavior.
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?
Though detailed, the description is well-structured with clear sections (PREREQUISITE, NOTE, Returns, Example prompts). Every sentence conveys necessary information for a high-stakes, gas-costly blockchain operation, and it is front-loaded with the core purpose. The length is justified by the tool's complexity.
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 tool involves an on-chain write with financial cost and permanent records, the description covers all essential context: when to use, prerequisites, cost implications, permanence, output structure, and example prompts. The output schema is also present, so the explicit return field listing is a bonus. This description is fully complete for an agent to select and invoke the tool 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?
The input schema already fully describes the bundle_id parameter with 100% coverage, including format, example, and status requirement. The description reinforces this by embedding the prerequisite ('Bundle status must be complete') and using the example in prompt suggestions, adding marginal value beyond the schema.
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 clearly states the tool's function: notarizing an evidence bundle on-chain by writing its SHA-256 manifest to the blockchain. It also differentiates from sibling tools like bundle.verify by emphasizing the on-chain, permanent timestamping use case.
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?
Explicitly states when to use the tool ('when you need an immutable on-chain timestamp') and when not to ('For quick integrity checks without on-chain cost, use bundle.verify instead'). It also specifies a prerequisite (bundle must be 'complete', check with bundle.get), giving clear operational guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify the cryptographic integrity of an evidence bundle (ev_...) owned by your API key. Checks manifest hash, EIP-191 signature, and R2 artifact hashes. Free — no credits consumed. Use when you need to confirm a bundle has not been tampered with. For quick metadata lookups (without full crypto verification), use bundle.get instead. Also returns a signed action receipt (rcpt_...) binding this verify call to the bundle manifest — list with receipt.list, verify with receipt.verify. Returns: { valid: boolean, bundle_id, manifest_sha256, checks: { status, manifest_hash, signature, artifacts: [{ name, ok }] }, tampered: string[], signer_address: string|null, attestation_tx: string|null, url: string, captured_at: string, receipt: ActionReceipt|null } Example prompts:
"Verify the cryptographic integrity of bundle ev_550e8400."
"Is this evidence bundle still valid and untampered?"
"Deep-check the manifest hash and signature of my bundle."
| Name | Required | Description | Default |
|---|---|---|---|
| bundle_id | Yes | Evidence bundle ID (ev_...) returned by extract or notarize. Example: "ev_550e8400-e29b-41d4-a716-446655440000" |
| Name | Required | Description |
|---|---|---|
| url | No | |
| valid | Yes | |
| checks | Yes | |
| receipt | Yes | |
| tampered | Yes | |
| bundle_id | Yes | |
| captured_at | No | |
| attestation_tx | No | |
| signer_address | No | |
| manifest_sha256 | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, and the description adds significant behavioral context: it is free (no credits consumed), checks the bundle is owned by the API key, enumerates specific integrity checks, and discloses that it returns a signed action receipt. This goes well beyond the annotation hints and adds useful operational details.
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 well-structured with purpose, usage, return value, and examples. It is longer than minimal but each section earns its place. The Returns block may be redundant with the existing output schema, but it still aids quick comprehension without being overly verbose.
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 description covers when to use, alternatives, cost, ownership, what is verified, and receipt handling. Combined with rich annotations and an output schema, it leaves no major operational gaps for an agent to correctly select and invoke this tool. The context signals indicate high schema and annotation richness, and the description completes the picture.
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 for the single parameter bundle_id is 100%, including type, description, and an example. The description does not add parameter-specific semantics beyond the schema, so the baseline score of 3 is appropriate. The schema already carries the full burden for parameters.
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 specifies a clear verb and resource: 'Verify the cryptographic integrity of an evidence bundle', and enumerates exact checks (manifest hash, EIP-191 signature, R2 artifact hashes). It also distinguishes itself from sibling bundle.get, which is for quick metadata lookups without full verification, making differentiation explicit.
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 provides explicit usage guidance: 'Use when you need to confirm a bundle has not been tampered with' and contrasts it with 'For quick metadata lookups (without full crypto verification), use bundle.get instead.' It also gives concrete example prompts that demonstrate when and how to invoke the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add an evidence bundle to a collection and trigger async vector indexing. Use after collection.create to populate a collection with documents. Once indexed, documents become searchable via collection.search and collection.ask. Indexing is async — poll job.status with the returned job_id until status is "complete". Also returns a signed action receipt (rcpt_...) binding this add call to the bundle manifest — list with receipt.list, verify with receipt.verify. PREREQUISITE: Bundle must have status "complete" (check with bundle.get). Collection must be owned by your API key. Returns: { collection_id, bundle_id, job_id (poll for indexing completion), receipt: ActionReceipt|null } Example prompts:
"Add my contract bundle ev_550e8400 to the Q4 Contracts collection."
"Put this evidence bundle into my Due Diligence Docs collection for search."
"Add document [bundle_id] to collection [col_id] with a title."
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | Optional display title for the document in this collection. Example: "Q4 2025 Financial Report" | |
| bundle_id | Yes | Evidence bundle ID (ev_...) to add. Bundle must have status "complete". Example: "ev_550e8400-e29b-41d4-a716-446655440000" | |
| collection_id | Yes | Collection ID (col_...) returned by collection.create. Example: "col_550e8400-e29b-41d4-a716-446655440000" |
| Name | Required | Description |
|---|---|---|
| job_id | Yes | |
| receipt | Yes | |
| bundle_id | Yes | |
| collection_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses that indexing is async, returns a job_id to poll, and provides a signed action receipt. It also mentions the requirement for bundle status and ownership. No contradiction with annotations.
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 well-structured with a clear opening, usage note, return contract, and examples. It is longer than minimal but every section adds value—prerequisites, async behavior, receipt handling, and invocation examples. Not all sentences are essential, hence a 4.
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 tool's async nature and return of job_id/receipt, the description covers the full workflow: how to invoke, what to do after (poll), prerequisites, and return structure. It also aligns with sibling tools (job.status, receipt.verify, collection.search) and provides example prompts.
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 100%, so the baseline applies. The description reinforces parameter usage through examples and prerequisites but does not add substantial meaning beyond the schema descriptions, which already include examples and constraints.
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 starts with a specific verb and resource: 'Add an evidence bundle to a collection and trigger async vector indexing.' It clearly distinguishes from siblings like collection.create (create collection), collection.search/ask (query), and bundle.get/receipt.verify.
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 explicitly states when to use it ('Use after collection.create'), what happens after indexing (searchable via collection.search and collection.ask), and gives prerequisites (bundle complete, collection owned). It also tells the agent to poll job.status, providing a clear workflow with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Answer a question using RAG over a document collection. Retrieves relevant chunks then synthesizes a cited answer with source attribution. Use when you need a direct answer grounded in your collection documents. For raw matching chunks (without synthesis), use collection.search instead. For single-document Q&A, use url.qa instead. PREREQUISITE: Collection must be populated via collection.add_document and indexed before results appear. Returns: { answer: string, sources: [{ bundle_id, chunk_id }], retrieval: [{ bundle_id, chunk_id, text, score }] } Example prompts:
"What are the key terms of the service agreement in my collection?"
"Based on my due diligence docs, what are the main risks?"
"Answer this question using all documents in the Q4 Contracts collection."
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | Natural language question to answer from collection documents. Example: "What are the key terms of the service agreement?" | |
| max_chunks | No | Max chunks to retrieve for context (default 8). Increase for broad questions, decrease for precision. Example: 12 | |
| collection_id | Yes | Collection ID (col_...) returned by collection.create. Example: "col_550e8400-e29b-41d4-a716-446655440000" |
| Name | Required | Description |
|---|---|---|
| answer | Yes | |
| sources | Yes | |
| retrieval | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the description's added context (synthesis process, citation behavior, return structure) is valuable. It also warns that collection must be populated first. It doesn't cover failure modes or rate limits, but for a read-only retrieval tool this is adequate.
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 moderately long but well-structured: main purpose, usage guidance, prerequisite, return type, and examples. It is front-loaded with the core verb and resource. Some redundancy between the first sentence and the 'Use when' clause, but overall efficient.
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 description is highly complete for a RAG tool. It covers what it does, when to use it, how it differs from alternatives, prerequisites, and the exact return structure. The output schema already exists, so return values are documented, and the description reinforces them with an example structure.
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 100%, with each parameter (question, max_chunks, collection_id) having a clear description and example. The description text does not add new parameter-level semantics beyond the schema, but the example prompts illustrate question phrasing. Baseline 3 is appropriate.
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 clearly states the tool performs RAG over a document collection to answer questions with source-attributed synthesis. It explicitly distinguishes itself from collection.search (raw chunks) and url.qa (single-document Q&A), making its purpose unambiguous.
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 provides explicit when-to-use guidance ('Use when you need a direct answer grounded in your collection documents') and names specific alternatives with different use cases. It also includes a prerequisite about populating and indexing the collection, which is essential for correct usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a named document collection for cross-document semantic search and RAG-based Q&A. Free — no credits consumed. Use when you want to group related evidence bundles for unified search (collection.search) or question answering (collection.ask). NOTE: Collections start empty. Add evidence bundles with collection.add_document. Indexing is async — once complete, use collection.search or collection.ask. Returns: { collection_id: string (col_...), name: string } Example prompts:
"Create a collection called Q4 Contracts for my quarterly reports."
"Set up a new document group named Due Diligence Docs."
"Make a collection to organize my vendor agreements."
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Human-readable collection name. Example: "Q4 Contracts" or "Due Diligence Docs" |
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| collection_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover readOnly/idempotent/destructive, but the description adds valuable behavioral details not in annotations: it's free (no credits), collections start empty, indexing is async, and it returns a specific object shape with collection_id. This goes beyond the structured fields.
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 well-structured with a clear opening, a note about async indexing, return format, and example prompts. While longer than the minimal example, each section adds practical value and the structure is easy to scan.
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 simple creation tool, the description covers purpose, usage, workflow, return schema, and examples. It mentions related sibling tools appropriately and leaves no major operational gaps.
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?
The schema fully describes the 'name' parameter with an example. The description reinforces it with prompt examples and mentions 'named' but doesn't add new technical constraints. Given 100% schema coverage, the baseline of 3 applies.
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+resource: 'Create a named document collection' and defines its purpose for cross-document semantic search and RAG-based Q&A. This clearly distinguishes it from sibling operations like collection.search, collection.ask, and collection.add_document.
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 explicitly states when to use: 'Use when you want to group related evidence bundles for unified search or question answering.' It also clarifies the workflow by noting collections start empty and that documents must be added via collection.add_document, with indexing async. This gives clear context, though it doesn't enumerate exclusions like when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all document collections owned by your API key. Free — no credits consumed. Use before collection.search or collection.ask when you need the collection ID. Supports pagination with limit and offset. Returns: { collections: [{ id, name, created_at }] } Example prompts:
"List all my document collections."
"Show me the collections I have created."
"What collections do I own? List them."
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max collections to return (default 50, max 100). Example: 20 | |
| offset | No | Pagination offset (default 0). Example: 0 |
| Name | Required | Description |
|---|---|---|
| collections | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, and the description adds valuable context: it is free and consumes no credits, returns a specific structure, and supports pagination. This goes beyond the annotations without contradicting them.
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 well-structured and front-loaded with the core purpose, but the three example prompts are somewhat redundant and could be trimmed for tighter conciseness.
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 description covers all important aspects: what is listed, ownership scope, cost, usage context, pagination, and return format. It is self-contained and sufficient for an agent to decide when and how to invoke the tool.
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?
The input schema describes both parameters (limit and offset) with examples, so schema description coverage is 100%. The description only mentions 'Supports pagination with limit and offset,' which adds minimal value beyond the schema.
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 clearly states 'List all document collections owned by your API key' using a specific verb and resource, and it distinguishes itself from sibling tools like collection.search and collection.ask by emphasizing listing all collections rather than searching or asking.
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 explicitly says 'Use before collection.search or collection.ask when you need the collection ID,' which provides clear context for when to use this tool and names alternatives. It also mentions free usage and pagination support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Semantic (vector) search across documents in a collection. Returns ranked text chunks with relevance scores. Free — no credits consumed. Use when you need raw matching chunks from a collection. For a synthesized cited answer from the same context, use collection.ask instead. PREREQUISITE: Collection must be populated via collection.add_document and async indexing must complete (poll job.status) before results appear. Returns: { results: [{ bundle_id, chunk_id, text, score: number (0–1), title? }] } Example prompts:
"Search my Q4 Contracts collection for mentions of liability cap."
"Find the clause about data retention in my due diligence docs."
"Search for revenue numbers across my quarterly reports."
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max chunks to return (default 10, max 50). Example: 5 | |
| query | Yes | Natural language search query. Example: "What were the revenue numbers for Q4?" | |
| collection_id | Yes | Collection ID (col_...) returned by collection.create. Example: "col_550e8400-e29b-41d4-a716-446655440000" |
| Name | Required | Description |
|---|---|---|
| results | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the description adds value by disclosing that the operation is 'Free — no credits consumed' and that async indexing must complete before results appear. This clarifies real-world behavior beyond the safety hints.
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 well-structured with clear sections: purpose, usage guidance, prerequisite, return format, and example prompts. It is front-loaded with the main purpose and includes no filler. Every sentence contributes to understanding the tool.
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 description covers all necessary context: purpose, usage, prerequisites, return format, cost, and examples. Given the tool's moderate complexity and the presence of an output schema, this is fully self-contained and leaves no major gaps for an agent to misuse.
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 100%, so all parameters (collection_id, query, limit) are already documented with descriptions and examples. The description adds example prompts that illustrate query phrasing but does not change the fundamental meaning of any parameter. Baseline 3 is appropriate.
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 clearly states 'Semantic (vector) search across documents in a collection' with a specific verb (search) and resource (documents in a collection). It also distinguishes itself from sibling tool collection.ask, which provides synthesized answers rather than raw chunks.
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?
Explicitly states when to use: 'Use when you need raw matching chunks from a collection.' Directly names the alternative: 'For a synthesized cited answer from the same context, use collection.ask instead.' Also provides a prerequisite about indexing completion and polling job.status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify a list of factual claims against document text. Uses a quality AI model with citation-level evidence. Use after document.extract_text or url.extract when you need to validate specific factual assertions. For open-ended questions about a document, use url.qa instead. For multi-document investigation, use collection.ask. Typical workflow: document.extract_text/url.extract → document.check_claims. Returns: { claims: [{ claim, status: "supported"|"contradicted"|"not_found", evidence: { quote, paragraphs[] }, confidence: "high"|"medium"|"low" }], truncated: boolean } Example prompts:
"Check whether this contract mentions a liability cap of $1M."
"Verify these claims against the document: [claims list]."
"Does the report actually say revenue grew 23%?"
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Document text to check claims against. Obtain via document.extract_text or url.extract. Example: "ACME Corp was founded in 2010. Revenue exceeded $1M in 2024." | |
| claims | Yes | Factual statements to verify. Each claim is checked independently against the text. Example: ["Founded in 2010", "Revenue exceeded $1M"] | |
| max_tokens | No | Input length cap (1 token ≈ 4 chars). Default ~3000 tokens. Truncates input text, not the output. Example: 4000 |
| Name | Required | Description |
|---|---|---|
| claims | Yes | |
| truncated | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, and the description adds substantial behavioral context: AI model quality, citation-level evidence, return structure with statuses and confidence, and the `truncated` flag. It also clarifies that max_tokens truncates input (in schema) but adds the return-level `truncated` indicator. No contradictions with annotations.
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 well-structured and front-loaded: a clear purpose sentence, usage alternatives, workflow, return shape, and example prompts. Every section adds value without redundancy. It is longer than a minimal description but all content is used.
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 tool with 3 parameters and a structured output, the description covers all necessary context: when to use, how to use, what it returns, and examples. The return schema is shown in the description, so the agent fully understands behavior before invoking the tool. Given the existing output schema, this is complete.
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 100%, with each parameter (text, claims, max_tokens) already described in detail. The description does not add new parameter semantics beyond the schema, only example prompts that illustrate usage rather than parameter meaning. Baseline of 3 is appropriate because the schema carries the full load.
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 first sentence states a specific verb and resource: 'Verify a list of factual claims against document text.' It also distinguishes from siblings by mentioning 'citation-level evidence' and explicitly comparing to url.qa and collection.ask for different use cases.
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?
Explicitly states when to use (validate specific assertions after extraction), when not to use (open-ended questions → url.qa; multi-document → collection.ask), and gives a typical workflow from extraction to checking claims. This is clear guidance with named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract typed fields from document text using a caller-defined schema. Uses a quality AI model with retry logic. Use when you need specific data points from a document rather than full text. For invoices with known fields, document.parse_invoice (prebuilt schema) may be simpler. For general summarization, use document.summarize instead. Schema format: { "field_name": "type hint or description" } — e.g. { "contract_date": "ISO date", "party_a": "string", "penalty_usd": "number" }. Returns: { data: { : value }, data_cited: { : { value, confidence: "high"|"medium"|"low", citations: [{ quote, paragraphs[] }] } } } Example prompts:
"Extract the contract date, parties, and penalty amount from this agreement."
"Pull the vendor name, PO number, and total from this document."
"Get me all named fields from this form using my custom schema."
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Document text to extract from. Obtain via document.extract_text or url.extract. Example: "This Service Agreement is entered into on 2025-03-15 between ACME Corp and Beta Inc..." | |
| schema | Yes | Field map: describe each field you want extracted with a type hint. Example: { "total_usd": "number", "vendor": "string", "invoice_date": "ISO date YYYY-MM-DD" } | |
| max_tokens | No | Input length cap (1 token ≈ 4 chars). Default ~2500 tokens. Truncates input, not output. Example: 3000 |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| data_cited | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the description doesn't need to restate them. It adds useful context about using a 'quality AI model with retry logic' and details the return structure with confidence levels and citations, which goes beyond annotation coverage.
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 moderately long but well-structured, with clear sections for purpose, usage, schema format, output, and examples. Every section earns its place given the tool's complexity, though it could be tightened slightly without losing value.
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 description covers usage context, alternatives, parameter examples, and explicitly describes the return object. For a complex tool with an output schema, this is comprehensive enough for an agent to select and invoke it correctly, though it doesn't address potential errors or edge cases.
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 100%, so the baseline is 3. The description provides a concrete schema format example and example prompts, but the schema descriptions already explain the parameters well. The added value is marginal—mainly illustrative rather than clarifying new 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 clearly states the tool extracts typed fields from document text using a caller-defined schema. It distinguishes itself from sibling tools by mentioning schema-driven extraction and explicitly contrasts with document.parse_invoice and document.summarize.
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?
Explicit guidance is provided: 'Use when you need specific data points from a document rather than full text,' and alternatives are named: 'For invoices with known fields, document.parse_invoice may be simpler. For general summarization, use document.summarize instead.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract tables and forms as Markdown from a PDF or image (base64-encoded). Use when the document contains structured tabular data such as financial statements, data sheets, or forms. For plain prose documents, use document.extract_text instead. Returns: { pages: number, text: string } — text contains Markdown-formatted tables. Example prompts:
"Extract the tables from this financial statement."
"Pull the data table from this PDF into Markdown format."
"Get the tabular data from this form document."
| Name | Required | Description | Default |
|---|---|---|---|
| mime_type | Yes | MIME type of the document. Example: "application/pdf" for PDF bank statements, "image/jpeg" for photo of a form. | |
| document_base64 | Yes | Base64-encoded PDF or image bytes (max ~15 MB). Example: "JVBERi0xLjcNJeLjz9MNCj..." (truncated PDF base64) |
| Name | Required | Description |
|---|---|---|
| text | Yes | |
| pages | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is known. The description adds value by disclosing the return format ({ pages, text } with Markdown tables) and input base64 encoding requirement, which is useful behavioral context beyond the annotations.
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 core description is concise and front-loaded, but the inclusion of three example prompts adds length. While these examples are useful, they could be trimmed without losing essential information. Overall, it remains efficient and well-structured.
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 simple tool with clear input schema and output schema (signal indicates has output schema: true), the description is complete. It explains when to use, what to expect in the output, and provides examples, covering all necessary context.
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 100%, so the schema already documents both parameters fully. The description does not add significant parameter semantics beyond what the schema provides, such as reiterating base64 encoding but without new detail.
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 clearly states the tool extracts tables and forms as Markdown from PDFs or images, using a specific verb and resource. It also distinguishes from sibling tool document.extract_text by noting it's for plain prose documents, providing clear differentiation.
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?
Explicitly specifies when to use the tool: 'Use when the document contains structured tabular data such as financial statements, data sheets, or forms.' It also names the alternative tool (document.extract_text) for prose documents, giving clear usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract plain text from a PDF or image (base64-encoded). Use when you need raw text for downstream AI analysis (summarization, claim checking, structured extraction). For documents at a public URL, use url.extract instead (no base64 encoding needed). Returns: { pages: number, text: string } Example prompts:
"Extract the text from this scanned contract so I can search it."
"Give me the raw text from this PDF document."
"OCR this image and return the text content."
| Name | Required | Description | Default |
|---|---|---|---|
| mime_type | Yes | MIME type of the document. Example: "application/pdf" for PDFs, "image/png" for PNG screenshots. | |
| document_base64 | Yes | Base64-encoded PDF or image bytes (max ~15 MB). Example: "JVBERi0xLjcNJeLjz9MNCj..." (truncated PDF base64) |
| Name | Required | Description |
|---|---|---|
| text | Yes | |
| pages | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, covering the safety profile. The description adds value by specifying the return shape ('Returns: { pages: number, text: string }') and indicating OCR capability for images. It does not contradict annotations.
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 well-structured, starting with the core action, followed by usage context, an alternative, the return format, and example prompts. The example prompts are slightly redundant but aid understanding. It is not overly verbose.
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 simple tool with 2 parameters and full schema coverage, the description covers purpose, usage, output shape, and an alternative tool. It does not mention error handling or size limits, but the schema includes the size limit, making the overall guidance adequate.
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?
The input schema provides 100% coverage with descriptions and examples for both parameters. The description does not add significant parameter details beyond what the schema already states, so the baseline score of 3 is appropriate.
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 clearly states a specific verb+resource: 'Extract plain text from a PDF or image (base64-encoded).' It also distinguishes itself from the sibling tool url.extract by explicitly noting that URL-based documents should use that alternative, which avoids ambiguity.
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 provides explicit when-to-use guidance: 'Use when you need raw text for downstream AI analysis (summarization, claim checking, structured extraction).' It also names a concrete alternative for public URLs, fulfilling the when-not-to-use condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parse a receipt or invoice document into structured fields. Uses a quality AI model for accuracy. Use when you need to extract line items, totals, and merchant info from financial documents. For general document text, use document.extract_text instead. Returns: { invoice: { merchant, date (YYYY-MM-DD), line_items[], subtotal, tax, total }, cited: { : { value, confidence: "high"|"medium"|"low", citations: [{ quote, paragraphs[] }] } } } Example prompts:
"Parse this invoice and give me the line items and total."
"Extract the merchant, date, and amounts from this receipt."
"Read this scanned invoice and return structured data."
| Name | Required | Description | Default |
|---|---|---|---|
| mime_type | Yes | MIME type of the document. Example: "application/pdf" for scanned invoice PDF, "image/jpeg" for a receipt photo. | |
| document_base64 | Yes | Base64-encoded PDF or image of the receipt/invoice (max ~15 MB). Example: "JVBERi0xLjcNJeLjz9MNCj..." (base64-encoded invoice PDF) |
| Name | Required | Description |
|---|---|---|
| cited | Yes | |
| invoice | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even with readOnlyHint and idempotentHint annotations, the description adds meaningful behavioral detail: it uses a quality AI model, returns confidence levels and citations, and shows the exact return structure. This goes well beyond the annotation-only baseline.
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 well-organized: purpose, usage guidance, return format, and example prompts. Every section adds value, and it remains concise despite the rich content, earning a top score.
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 tool's complexity, the description fully covers purpose, usage, output schema (via the return structure), and examples. Combined with complete parameter schema and annotations, nothing is left ambiguous for the AI agent.
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?
The input schema already provides 100% coverage with detailed descriptions and examples for both parameters. The description does not add param-specific semantics, so the baseline of 3 is appropriate.
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 clearly states it parses receipts/invoices into structured fields, specifies the extracted data (line items, totals, merchant info), and distinguishes itself from document.extract_text. The verb and resource are specific and unambiguous.
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?
Explicitly says 'Use when you need to extract line items, totals, and merchant info from financial documents' and directs users to document.extract_text for general text. Example prompts further clarify appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Summarize document text into a prose summary and key points with citations. Use after document.extract_text or url.extract when you need a condensed understanding of a long document. For single-sentence Q&A, use url.qa instead. For extracting specific fields, use document.extract_structured. Typical workflow: document.extract_text/url.extract → document.summarize. Returns: { summary: string, key_points: string[], summary_cited: { value, confidence, citations[] }, key_points_cited: [{ text, citations[] }], truncated: boolean, strategy: "full"|"truncated"|"chunked" } Example prompts:
"Summarize this financial report and give me the key points."
"What are the main takeaways from this document?"
"Give me a concise summary of this 50-page report."
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Document text to summarize. Obtain via document.extract_text or url.extract. Example: "The Q4 2025 financial report shows revenue growth of 23% year-over-year..." | |
| max_tokens | No | Input length cap (1 token ≈ 4 chars). Default ~3000 tokens. Truncates input, not output. Example: 4000 |
| Name | Required | Description |
|---|---|---|
| summary | Yes | |
| strategy | Yes | |
| truncated | Yes | |
| key_points | Yes | |
| summary_cited | Yes | |
| key_points_cited | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, lowering the bar. The description adds useful behavioral context beyond annotations: 'max_tokens' truncates input not output, and the return format includes 'truncated' and 'strategy' fields, describing how the tool handles long documents.
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 and usage guidance. It is somewhat long due to the return structure and example prompts, but every section adds value. It remains well-organized and avoids unnecessary words.
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 description is complete for this tool: it provides workflow, alternatives, return structure, and example prompts. The presence of an output schema and annotations fills remaining gaps, so the description needs no additional context.
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 100%, so the baseline is 3. The tool description repeats the schema's parameter descriptions but does not add significant new meaning; example prompts and return format are helpful for overall usage but not parameter-level semantics beyond what the schema already provides.
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: 'Summarize document text into a prose summary and key points with citations.' It clearly distinguishes from siblings by noting 'For single-sentence Q&A, use url.qa instead' and 'For extracting specific fields, use document.extract_structured.'
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?
Explicit when-to-use guidance is provided: 'Use after document.extract_text or url.extract when you need a condensed understanding of a long document.' It also states alternatives and a typical workflow, making the usage context unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Poll the status of an async job (extract, indexing, batch). Free — no credits consumed. Use after collection.add_document or async extract to check when processing completes. Poll this endpoint in a loop until status is "complete" or "failed". Completed jobs include the bundle_id or result_json in the response. Jobs are created when you POST /v1/extract with a webhook, or when collection.add_document triggers async indexing. Returns: { id, type: "extract"|"extract_batch"|"index_collection", status: "queued"|"processing"|"complete"|"failed"|"cancelled", progress_pct: number (0–100), progress_message, bundle_id (when complete), result_json (when complete), error (when failed), created_at, completed_at } Example prompts:
"Check the status of my indexing job job_550e8400."
"Is my async extract job done yet?"
"Poll job [job_id] — what is the current progress?"
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | Job ID (job_...) returned by async extract or collection.add_document. Example: "job_550e8400-e29b-41d4-a716-446655440000" |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| type | Yes | |
| error | Yes | |
| status | Yes | |
| bundle_id | Yes | |
| created_at | Yes | |
| result_json | Yes | |
| completed_at | Yes | |
| progress_pct | Yes | |
| collection_id | Yes | |
| progress_message | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and idempotentHint annotations, the description adds meaningful behavioral context: it is a polling endpoint, free with no credits consumed, completed jobs include bundle_id or result_json, and it details status values and progress fields. This provides a full picture of how the tool behaves at runtime.
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 moderately sized but well-structured, with a clear explanation, a return format block, and example prompts. Minor redundancy exists (bundle_id mentioned twice), but overall it is organized and each section serves a purpose.
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 tool's simplicity, the description is thorough: it covers usage context, polling behavior, cost, return structure, and state transitions. The output schema is present, but the description independently explains the fields and statuses, making the tool fully understandable without external references.
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?
The input schema already covers the single parameter (job_id) with a description and example. The description does not add additional parameter-specific semantics beyond the schema, so baseline 3 is appropriate.
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 clearly states the tool polls the status of an async job, listing specific job types (extract, indexing, batch). It distinguishes itself from sibling tools by focusing on job status rather than data extraction or collection management, making its purpose unambiguous.
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 explicitly tells when to use the tool: after collection.add_document or async extract, and to poll in a loop until complete or failed. It also mentions when jobs are created (POST /v1/extract with webhook, or add_document), and provides example prompts, giving clear usage context and no misleading alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List signed action receipts (rcpt_...) for an evidence bundle owned by your API key. Free — no credits consumed. Use after bundle.get, bundle.verify, bundle.notarize, or collection.add_document to audit which agent actions were bound to which manifest hash. Pass a receipt_id from the results to receipt.verify for independent signature + manifest-binding verification. Returns: { bundle_id, receipts: [{ receipt_id, bundle_id, agent_id, action, manifest_sha256, signed_at, signature, signer_address, key_id, algorithm }], limit, offset } Example prompts:
"List all signed action receipts for bundle ev_550e8400."
"What agent actions have been recorded against this evidence bundle?"
"Show me the receipts for [bundle_id] so I can verify one."
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max receipts to return (default 50, max 200). Example: 50 | |
| offset | No | Pagination offset (default 0). Example: 0 | |
| bundle_id | Yes | Evidence bundle ID (ev_...) to list receipts for. Example: "ev_550e8400-e29b-41d4-a716-446655440000" |
| Name | Required | Description |
|---|---|---|
| limit | Yes | |
| offset | Yes | |
| receipts | Yes | |
| bundle_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only and idempotent, and the description adds 'Free — no credits consumed' which is a cost behavior not captured by annotations. It also clarifies that receipts are scoped to the caller's API key ('owned by'), an access control detail. This goes beyond the structured fields, though it stops short of discussing error conditions or rate limits.
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 tightly written: a one-sentence purpose, a one-sentence usage context, a compact return structure, and three example prompts. Every sentence earns its place, and the structure front-loads the core purpose before adding workflow details.
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 has a read-only, idempotent annotation profile, a full parameter schema, and an output structure explicitly described in the text. The description covers purpose, when to use it, behavioral quirks (free, owned by API key), and the return format. For this simple list operation, the context is complete enough for an agent to select and 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?
All three parameters (bundle_id, limit, offset) are already described in the input schema with examples, so the schema covers 100% of the parameter semantics. The description doesn't add any parameter-specific syntax or format details, but it does provide example prompts that reference bundle_id. Given the high schema coverage, a baseline score of 3 is appropriate.
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 'List signed action receipts...' which clearly states the verb and resource, scoped to 'an evidence bundle owned by your API key.' It distinguishes from sibling receipt.verify by noting that this tool lists receipts while verification is a separate step. This is a specific, well-differentiated purpose.
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 explicitly says 'Use after bundle.get, bundle.verify, bundle.notarize, or collection.add_document' to audit which agent actions were bound to which manifest hash, providing clear when-to-use guidance. It also directs the user to pass a receipt_id to receipt.verify for independent verification, effectively naming the alternative for the next step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Independently verify a signed action receipt (rcpt_...) returned by bundle.get, bundle.verify, bundle.notarize, collection.add_document, or listed via receipt.list. Free — no credits consumed. Proves both that the receipt signature is authentic AND that the manifest_sha256 it was bound to still matches the bundle's current manifest — i.e. that the action was not performed against a stale or since-superseded document. Use for third-party audit of an agent's prior actions. Returns: { receipt_id, valid: boolean, signature_valid: boolean, manifest_matches_current: boolean, bundle_id, agent_id, action, manifest_sha256, signer_address, signed_at, tampered: string[] } Example prompts:
"Verify action receipt rcpt_550e8400 is authentic and still current."
"Was this receipt signed against the real document, or a stale copy?"
| Name | Required | Description | Default |
|---|---|---|---|
| receipt_id | Yes | Action receipt ID (rcpt_...) returned in the receipt field of another tool's response. Example: "rcpt_550e8400-e29b-41d4-a716-446655440000" |
| Name | Required | Description |
|---|---|---|
| valid | Yes | |
| action | Yes | |
| agent_id | Yes | |
| tampered | Yes | |
| bundle_id | Yes | |
| signed_at | Yes | |
| receipt_id | Yes | |
| signer_address | Yes | |
| manifest_sha256 | Yes | |
| signature_valid | Yes | |
| manifest_matches_current | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is known. The description adds valuable context: it is free, it checks two distinct conditions (signature validity and manifest currency), and the output includes a 'tampered' string array that flags any altered fields. This goes beyond the annotations without contradicting them.
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 well-structured: it opens with the core purpose, then explains the verification logic, lists the return fields in a compact JSON shape, and ends with two example prompts. While a bit lengthy, every sentence carries useful information and the structure aids quick comprehension.
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 description effectively includes an output schema through the Returns block, covers the input parameter and its origin, explains the verification semantics, and provides example user prompts. Given the tool's moderate complexity and the presence of an output schema, the description is complete and leaves no major gaps for an agent to successfully invoke it.
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?
The schema has 100% coverage with a description and example for receipt_id. The description further enriches meaning by explaining that the receipt ID is returned by specific sibling tools and appears in the format rcpt_..., which helps the agent map the parameter to real-world usage beyond the bare schema.
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 uses the specific verb 'verify' and identifies the exact resource ('signed action receipt') with the rcpt_ prefix. It distinguishes this tool from siblings by explaining that it proves both signature authenticity and current manifest match, which clearly differentiates receipt.verify from bundle.verify and other verification-like tools.
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 explicitly states when to use this tool ('Use for third-party audit of an agent's prior actions'), names all tools that produce the receipts (bundle.get, bundle.verify, etc.), and adds a cost-related guideline ('Free — no credits consumed'). This gives clear, actionable context for when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a public HTTPS URL and return extracted text and page metadata. Lean mode — no evidence bundle stored, no bundle_id returned. Use for raw text extraction from web pages and online documents. Use url.summarize for summaries, url.qa for Q&A, url.translate for translation, document.extract_text for base64 file uploads. Returns: { url, title, word_count, text, final_url (after redirects) } Example prompts:
"Extract the text from https://example.com/report.pdf for me."
"Get me the raw content of this web page: [URL]."
"Pull the text from this online article so I can analyze it."
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Public HTTPS URL to fetch and extract. Example: "https://example.com/report.pdf" or "https://blog.example.com/article" |
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| text | Yes | |
| title | No | |
| final_url | No | |
| word_count | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds behavioral nuance: lean mode, no evidence bundle stored, no bundle_id returned, and final_url after redirects. It also restricts to public HTTPS URLs, which is useful context beyond the schema.
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 function, then provides alternatives, return structure, and example prompts. It is well-structured, with each section earning its place and no redundant 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 simple single-parameter read-only tool, the description covers purpose, usage boundaries, return format, and example prompts. With output schema and annotations present, nothing critical 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 covers the single url parameter with a description and example (100% coverage). The description reinforces the HTTPS requirement and provides example prompts, but adds little else beyond what the schema already provides.
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 clearly states the verb+resource: 'Fetch a public HTTPS URL and return extracted text and page metadata.' It distinguishes from sibling tools by naming alternatives for summaries, Q&A, translation, and file uploads, making the tool's unique role explicit.
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?
Explicitly directs when to use this tool vs alternatives: 'Use url.summarize for summaries, url.qa for Q&A, url.translate for translation, document.extract_text for base64 file uploads.' It also notes the lean mode with no bundle storage, implying a lightweight use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a public HTTPS URL and answer a specific question about its content. Lean mode — no bundle stored. Use when you have a precise question about a web page. For a broad summary, use url.summarize. For multi-document Q&A, use collection.ask instead. Returns: { url, answer, answer_cited: { value, confidence, citations[] }, confidence: "high"|"medium"|"low", truncated } Example prompts:
"What is the refund policy at https://docs.example.com/policy?"
"Look at [URL] and tell me what the delivery terms are."
"Answer this question based on the content of [URL]: [question]."
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Public HTTPS URL to fetch and question. Example: "https://docs.example.com/policy" | |
| question | Yes | Specific question to answer from the page content. Example: "What is the refund policy?" | |
| max_tokens | No | Input length cap (1 token ≈ 4 chars). Truncates fetched page content, not the answer. Example: 4000 |
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| answer | No | |
| truncated | Yes | |
| confidence | No | |
| answer_cited | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=true, while the description adds behavioral details such as 'Lean mode — no bundle stored' and the 'truncated' field in the return value, indicating potential truncation. This goes beyond annotations, though it omits failure modes or rate limits, so not a 5.
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 well-structured with a clear action statement, usage guidance, return format, and example prompts. It is front-loaded with the core purpose and every sentence adds value. No wasted words.
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 straightforward fetch-and-answer tool, the description covers: what it does, when to use it, alternatives, return value structure, and example invocations. Output schema exists, but the description still explains the return fields. No significant gaps.
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 100%, so the baseline is 3. The description does not add parameter-level details beyond the schema, but it includes example prompts that illustrate parameter usage. The schema already explains max_tokens truncation behavior.
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 clearly states a specific verb and resource: 'Fetch a public HTTPS URL and answer a specific question about its content.' It differentiates from siblings by explicitly naming url.summarize and collection.ask as alternatives, and adds 'Lean mode — no bundle stored' to set it apart.
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?
Provides explicit usage guidance: 'Use when you have a precise question about a web page.' It also gives clear exclusions and alternatives: 'For a broad summary, use url.summarize. For multi-document Q&A, use collection.ask instead.' This is high-quality differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a public HTTPS URL and return a prose summary with key points. Lean mode — no bundle stored. Use when you need a condensed understanding of a web page. For raw text, use url.extract. For asking a specific question about a page, use url.qa. Returns: { url, summary, key_points: string[], truncated: boolean, word_count } Example prompts:
"Summarize https://en.wikipedia.org/wiki/Artificial_intelligence for me."
"Give me the key points from this blog post: [URL]."
"What is this article about? Summarize [URL]."
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Public HTTPS URL to fetch and summarize. Example: "https://en.wikipedia.org/wiki/Artificial_intelligence" | |
| max_tokens | No | Input length cap (1 token ≈ 4 chars). Truncates fetched page content, not the output summary. Example: 4000 |
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| summary | No | |
| truncated | Yes | |
| key_points | No | |
| word_count | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds useful context: 'Lean mode — no bundle stored' clarifies lack of persistent side effects, and the return shape is described. It doesn't mention rate limits or error handling, but these are less critical for a read-only fetch.
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 appropriately sized: first sentence states the core function, then usage guidance, return format, and example prompts. Every sentence earns its place with no filler or redundancy.
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 two parameters fully explained in the schema, annotations covering read-only and open-world, and an output schema, the description provides sufficient context: it explains when to use it, what it returns, and how to formulate prompts. It is complete for the tool's complexity.
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 100%, with both 'url' and 'max_tokens' well-documented. The description provides example prompts that illustrate usage but adds no new parameter semantics beyond the schema. Baseline 3 applies.
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 uses a specific action ('Fetch a public HTTPS URL') and output ('prose summary with key points'), clearly distinguishing it from sibling tools url.extract and url.qa. It also mentions the return structure.
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?
Explicitly states when to use the tool ('Use when you need a condensed understanding of a web page') and provides direct alternatives: 'For raw text, use url.extract. For asking a specific question about a page, use url.qa.' This is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a public HTTPS URL and return its content translated into a target language. Lean mode — no bundle stored. Use when you need to understand web content in a different language. For extracting raw untranslated text, use url.extract instead. Returns: { url, translated_text, target_lang, truncated } Example prompts:
"Translate https://example.de/artikel into English for me."
"Translate this German article into Spanish: [URL]."
"Fetch [URL] and give me the French translation."
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Public HTTPS URL to fetch and translate. Example: "https://example.de/artikel" | |
| max_tokens | No | Input length cap (1 token ≈ 4 chars). Truncates fetched page content before translation. Example: 4000 | |
| target_lang | Yes | ISO 639-1 language code for the target language. Example: "es" for Spanish, "fr" for French, "de" for German, "ja" for Japanese, "zh" for Chinese |
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| truncated | Yes | |
| target_lang | Yes | |
| translated_text | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and openWorldHint=true. The description adds meaningful behavioral context beyond that: 'Lean mode — no bundle stored' (clarifies side effects), 'public HTTPS URL' (constrains input), and the return shape including 'truncated' (indicates possible content truncation). This goes beyond simply restating the annotations, though it does not cover every possible behavior like rate limits or auth, which is acceptable given the read-only nature.
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 well-structured and reasonably sized: core function in the first sentence, followed by behavior, usage guidance, return shape, and examples. Every sentence contributes value, and the examples are useful for an agent. It is slightly longer than the minimal two-sentence example, but the extra content (alternatives, return structure, examples) is justified.
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 tool's moderate complexity (3 parameters, output schema present, annotations present), the description is quite complete. It covers what the tool does, when to use it, an alternative, key behavioral traits, and return structure. The only minor omission is explicit mention of max_tokens, but the schema fully documents that, so the overall completeness is high.
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 100%, with all three parameters (url, max_tokens, target_lang) documented with types, descriptions, and examples. The description itself does not add additional parameter semantics beyond what the schema already provides, so the baseline of 3 applies. The example prompts indirectly illustrate how to use url and target_lang, but this is marginal additional value.
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 clearly states the tool's function: 'Fetch a public HTTPS URL and return its content translated into a target language.' It uses a specific verb ('fetch', 'return') and resource ('content translated'), and distinguishes itself from the sibling url.extract by explicitly noting it provides raw untranslated text. This makes the purpose unambiguous.
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 gives explicit usage guidance: 'Use when you need to understand web content in a different language' and provides a concrete alternative for a different need: 'For extracting raw untranslated text, use url.extract instead.' This satisfies the when/when-not/alternatives criterion fully.
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.
account.quotaadd_document_to_collectionask_collectionbundle.getbundle.notarizebundle.verifycheck_claimscollection.add_documentcollection.askcollection.createcollection.listcollection.searchcreate_collectiondocument.check_claimsdocument.extract_structureddocument.extract_tablesdocument.extract_textdocument.parse_invoicedocument.summarizeextract_structuredextract_tablesextract_textextract_urlget_bundleget_job_statusget_quotajob.statuslist_collectionsnotarize_bundleparse_invoiceqa_urlreceipt.listreceipt.verifysearch_collectionsummarize_documentsummarize_urltranslate_urlurl.extracturl.qaurl.summarizeurl.translateverify_action_receiptverify_bundleadd_document_to_collection2 fields changedOutput schema / properties / receiptAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "action": {
+ "type": "string"
+ },
+ "agent_id": {
+ "type": "string"
+ },
+ "algorithm": {
+ "const": "secp256k1-eip191",
+ "type": "string"
+ },
+ "bundle_id": {
+ "type": "string"
+ },
+ "key_id": {
+ "type": "string"
+ },
+ "manifest_sha256": {
+ "type": "string"
+ },
+ "receipt_id": {
+ "type": "string"
+ },
+ "signature": {
+ "type": "string"
+ },
+ "signed_at": {
+ "type": "string"
+ },
+ "signer_address": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "receipt_id",
+ "bundle_id",
+ "agent_id",
+ "action",
+ "manifest_sha256",
+ "signed_at",
+ "signature",
+ "signer_address",
+ "key_id",
+ "algorithm"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}Output schema / requiredPrevious value: -[
- "collection_id",
- "bundle_id",
- "job_id"
-]New value: +[
+ "collection_id",
+ "bundle_id",
+ "job_id",
+ "receipt"
+]get_bundle2 fields changedOutput schema / properties / receiptAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "action": {
+ "type": "string"
+ },
+ "agent_id": {
+ "type": "string"
+ },
+ "algorithm": {
+ "const": "secp256k1-eip191",
+ "type": "string"
+ },
+ "bundle_id": {
+ "type": "string"
+ },
+ "key_id": {
+ "type": "string"
+ },
+ "manifest_sha256": {
+ "type": "string"
+ },
+ "receipt_id": {
+ "type": "string"
+ },
+ "signature": {
+ "type": "string"
+ },
+ "signed_at": {
+ "type": "string"
+ },
+ "signer_address": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "receipt_id",
+ "bundle_id",
+ "agent_id",
+ "action",
+ "manifest_sha256",
+ "signed_at",
+ "signature",
+ "signer_address",
+ "key_id",
+ "algorithm"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}Output schema / requiredPrevious value: -[
- "bundle_id",
- "source_url",
- "mode",
- "status",
- "manifest_sha256",
- "manifest_signature",
- "signer_address",
- "attestation_tx",
- "attestation_at",
- "eas_uid",
- "parent_bundle_id",
- "superseded_by",
- "legal_hold",
- "retention_until",
- "created_at"
-]New value: +[
+ "bundle_id",
+ "source_url",
+ "mode",
+ "status",
+ "manifest_sha256",
+ "manifest_signature",
+ "signer_address",
+ "attestation_tx",
+ "attestation_at",
+ "eas_uid",
+ "parent_bundle_id",
+ "superseded_by",
+ "legal_hold",
+ "retention_until",
+ "created_at",
+ "receipt"
+]notarize_bundle2 fields changedOutput schema / properties / receiptAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "action": {
+ "type": "string"
+ },
+ "agent_id": {
+ "type": "string"
+ },
+ "algorithm": {
+ "const": "secp256k1-eip191",
+ "type": "string"
+ },
+ "bundle_id": {
+ "type": "string"
+ },
+ "key_id": {
+ "type": "string"
+ },
+ "manifest_sha256": {
+ "type": "string"
+ },
+ "receipt_id": {
+ "type": "string"
+ },
+ "signature": {
+ "type": "string"
+ },
+ "signed_at": {
+ "type": "string"
+ },
+ "signer_address": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "receipt_id",
+ "bundle_id",
+ "agent_id",
+ "action",
+ "manifest_sha256",
+ "signed_at",
+ "signature",
+ "signer_address",
+ "key_id",
+ "algorithm"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}Output schema / requiredPrevious value: -[
- "bundle_id",
- "attestation"
-]New value: +[
+ "bundle_id",
+ "attestation",
+ "receipt"
+]verify_action_receiptverify_bundle2 fields changedOutput schema / properties / receiptAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "action": {
+ "type": "string"
+ },
+ "agent_id": {
+ "type": "string"
+ },
+ "algorithm": {
+ "const": "secp256k1-eip191",
+ "type": "string"
+ },
+ "bundle_id": {
+ "type": "string"
+ },
+ "key_id": {
+ "type": "string"
+ },
+ "manifest_sha256": {
+ "type": "string"
+ },
+ "receipt_id": {
+ "type": "string"
+ },
+ "signature": {
+ "type": "string"
+ },
+ "signed_at": {
+ "type": "string"
+ },
+ "signer_address": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "receipt_id",
+ "bundle_id",
+ "agent_id",
+ "action",
+ "manifest_sha256",
+ "signed_at",
+ "signature",
+ "signer_address",
+ "key_id",
+ "algorithm"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}Output schema / requiredPrevious value: -[
- "bundle_id",
- "valid",
- "manifest_sha256",
- "checks",
- "tampered"
-]New value: +[
+ "bundle_id",
+ "valid",
+ "manifest_sha256",
+ "checks",
+ "tampered",
+ "receipt"
+]add_document_to_collection1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "bundle_id": {
+ "type": "string"
+ },
+ "collection_id": {
+ "type": "string"
+ },
+ "job_id": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "collection_id",
+ "bundle_id",
+ "job_id"
+ ],
+ "type": "object"
+}ask_collection1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "answer": {
+ "additionalProperties": false,
+ "properties": {
+ "citations": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "artifact": {
+ "type": "string"
+ },
+ "char_end": {
+ "type": "number"
+ },
+ "char_start": {
+ "type": "number"
+ },
+ "chunk_id": {
+ "type": "string"
+ },
+ "confidence": {
+ "enum": [
+ "high",
+ "medium",
+ "low"
+ ],
+ "type": "string"
+ },
+ "page": {
+ "type": "number"
+ },
+ "paragraphs": {
+ "items": {
+ "type": "number"
+ },
+ "type": "array"
+ },
+ "quote": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "quote",
+ "paragraphs",
+ "confidence"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "confidence": {
+ "enum": [
+ "high",
+ "medium",
+ "low"
+ ],
+ "type": "string"
+ },
+ "value": {}
+ },
+ "required": [
+ "value",
+ "confidence",
+ "citations"
+ ],
+ "type": "object"
+ },
+ "retrieval": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "bundle_id": {
+ "type": "string"
+ },
+ "chunk_id": {
+ "type": "string"
+ },
+ "score": {
+ "type": "number"
+ },
+ "text": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "bundle_id",
+ "chunk_id",
+ "text",
+ "score"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "sources": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "bundle_id": {
+ "type": "string"
+ },
+ "chunk_id": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "bundle_id",
+ "chunk_id"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "answer",
+ "sources",
+ "retrieval"
+ ],
+ "type": "object"
+}check_claims1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "claims": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "claim": {
+ "type": "string"
+ },
+ "confidence": {
+ "enum": [
+ "high",
+ "medium",
+ "low"
+ ],
+ "type": "string"
+ },
+ "evidence": {
+ "additionalProperties": false,
+ "properties": {
+ "paragraphs": {
+ "items": {
+ "type": "number"
+ },
+ "type": "array"
+ },
+ "quote": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "quote",
+ "paragraphs"
+ ],
+ "type": "object"
+ },
+ "status": {
+ "enum": [
+ "supported",
+ "contradicted",
+ "not_found"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "claim",
+ "status",
+ "evidence",
+ "confidence"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "truncated": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "claims",
+ "truncated"
+ ],
+ "type": "object"
+}create_collection1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "collection_id": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "collection_id",
+ "name"
+ ],
+ "type": "object"
+}extract_structured1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "data": {
+ "additionalProperties": {},
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "data_cited": {
+ "additionalProperties": {
+ "additionalProperties": false,
+ "properties": {
+ "citations": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "artifact": {
+ "type": "string"
+ },
+ "char_end": {
+ "type": "number"
+ },
+ "char_start": {
+ "type": "number"
+ },
+ "chunk_id": {
+ "type": "string"
+ },
+ "confidence": {
+ "enum": [
+ "high",
+ "medium",
+ "low"
+ ],
+ "type": "string"
+ },
+ "page": {
+ "type": "number"
+ },
+ "paragraphs": {
+ "items": {
+ "type": "number"
+ },
+ "type": "array"
+ },
+ "quote": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "quote",
+ "paragraphs",
+ "confidence"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "confidence": {
+ "enum": [
+ "high",
+ "medium",
+ "low"
+ ],
+ "type": "string"
+ },
+ "value": {}
+ },
+ "required": [
+ "value",
+ "confidence",
+ "citations"
+ ],
+ "type": "object"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ }
+ },
+ "required": [
+ "data",
+ "data_cited"
+ ],
+ "type": "object"
+}extract_tables1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "pages": {
+ "type": "number"
+ },
+ "text": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "pages",
+ "text"
+ ],
+ "type": "object"
+}extract_text1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "pages": {
+ "type": "number"
+ },
+ "text": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "pages",
+ "text"
+ ],
+ "type": "object"
+}extract_url1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "final_url": {
+ "type": "string"
+ },
+ "text": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ },
+ "word_count": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "url",
+ "text"
+ ],
+ "type": "object"
+}get_bundle1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "attestation_at": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "attestation_tx": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "bundle_id": {
+ "type": "string"
+ },
+ "created_at": {
+ "type": "string"
+ },
+ "eas_uid": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "legal_hold": {
+ "type": "boolean"
+ },
+ "manifest_sha256": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "manifest_signature": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "mode": {
+ "type": "string"
+ },
+ "parent_bundle_id": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "retention_until": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "signer_address": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "source_url": {
+ "type": "string"
+ },
+ "status": {
+ "enum": [
+ "pending",
+ "complete",
+ "failed"
+ ],
+ "type": "string"
+ },
+ "superseded_by": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "required": [
+ "bundle_id",
+ "source_url",
+ "mode",
+ "status",
+ "manifest_sha256",
+ "manifest_signature",
+ "signer_address",
+ "attestation_tx",
+ "attestation_at",
+ "eas_uid",
+ "parent_bundle_id",
+ "superseded_by",
+ "legal_hold",
+ "retention_until",
+ "created_at"
+ ],
+ "type": "object"
+}get_job_status1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "bundle_id": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "collection_id": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "completed_at": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "created_at": {
+ "type": "string"
+ },
+ "error": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "id": {
+ "type": "string"
+ },
+ "progress_message": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "progress_pct": {
+ "type": "number"
+ },
+ "result_json": {
+ "anyOf": [
+ {},
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "status": {
+ "enum": [
+ "queued",
+ "processing",
+ "complete",
+ "failed",
+ "cancelled"
+ ],
+ "type": "string"
+ },
+ "type": {
+ "enum": [
+ "extract",
+ "extract_batch",
+ "index_collection"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "type",
+ "status",
+ "progress_pct",
+ "progress_message",
+ "bundle_id",
+ "collection_id",
+ "result_json",
+ "error",
+ "created_at",
+ "completed_at"
+ ],
+ "type": "object"
+}get_quota1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "billing_period": {
+ "type": "string"
+ },
+ "credits_limit": {
+ "type": "number"
+ },
+ "credits_remaining": {
+ "type": "number"
+ },
+ "credits_used": {
+ "type": "number"
+ },
+ "plan_id": {
+ "type": "string"
+ },
+ "status": {
+ "enum": [
+ "active",
+ "suspended",
+ "revoked"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "plan_id",
+ "billing_period",
+ "credits_used",
+ "credits_limit",
+ "credits_remaining",
+ "status"
+ ],
+ "type": "object"
+}list_collections1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "collections": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "created_at": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "created_at"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "collections"
+ ],
+ "type": "object"
+}notarize_bundle1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "attestation": {
+ "additionalProperties": false,
+ "properties": {
+ "attested_at": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "eas_uid": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "key_id": {
+ "type": "string"
+ },
+ "network": {
+ "type": "string"
+ },
+ "schema_uid": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "tx_hash": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "tx_hash",
+ "network",
+ "attested_at"
+ ],
+ "type": "object"
+ },
+ "bundle_id": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "bundle_id",
+ "attestation"
+ ],
+ "type": "object"
+}parse_invoice1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "cited": {
+ "additionalProperties": {
+ "additionalProperties": false,
+ "properties": {
+ "citations": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "artifact": {
+ "type": "string"
+ },
+ "char_end": {
+ "type": "number"
+ },
+ "char_start": {
+ "type": "number"
+ },
+ "chunk_id": {
+ "type": "string"
+ },
+ "confidence": {
+ "enum": [
+ "high",
+ "medium",
+ "low"
+ ],
+ "type": "string"
+ },
+ "page": {
+ "type": "number"
+ },
+ "paragraphs": {
+ "items": {
+ "type": "number"
+ },
+ "type": "array"
+ },
+ "quote": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "quote",
+ "paragraphs",
+ "confidence"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "confidence": {
+ "enum": [
+ "high",
+ "medium",
+ "low"
+ ],
+ "type": "string"
+ },
+ "value": {}
+ },
+ "required": [
+ "value",
+ "confidence",
+ "citations"
+ ],
+ "type": "object"
+ },
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "invoice": {
+ "additionalProperties": false,
+ "properties": {
+ "date": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "line_items": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "description": {
+ "type": "string"
+ },
+ "quantity": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "total": {
+ "type": "number"
+ },
+ "unit_price": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "required": [
+ "description",
+ "quantity",
+ "unit_price",
+ "total"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "merchant": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "subtotal": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "tax": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "total": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "required": [
+ "merchant",
+ "date",
+ "line_items",
+ "subtotal",
+ "tax",
+ "total"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "invoice",
+ "cited"
+ ],
+ "type": "object"
+}qa_url1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "answer": {
+ "type": "string"
+ },
+ "answer_cited": {
+ "additionalProperties": false,
+ "properties": {
+ "citations": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "artifact": {
+ "type": "string"
+ },
+ "char_end": {
+ "type": "number"
+ },
+ "char_start": {
+ "type": "number"
+ },
+ "chunk_id": {
+ "type": "string"
+ },
+ "confidence": {
+ "enum": [
+ "high",
+ "medium",
+ "low"
+ ],
+ "type": "string"
+ },
+ "page": {
+ "type": "number"
+ },
+ "paragraphs": {
+ "items": {
+ "type": "number"
+ },
+ "type": "array"
+ },
+ "quote": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "quote",
+ "paragraphs",
+ "confidence"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "confidence": {
+ "enum": [
+ "high",
+ "medium",
+ "low"
+ ],
+ "type": "string"
+ },
+ "value": {}
+ },
+ "required": [
+ "value",
+ "confidence",
+ "citations"
+ ],
+ "type": "object"
+ },
+ "confidence": {
+ "enum": [
+ "high",
+ "medium",
+ "low"
+ ],
+ "type": "string"
+ },
+ "truncated": {
+ "type": "boolean"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "url",
+ "truncated"
+ ],
+ "type": "object"
+}search_collection1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "results": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "bundle_id": {
+ "type": "string"
+ },
+ "chunk_id": {
+ "type": "string"
+ },
+ "score": {
+ "type": "number"
+ },
+ "text": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "bundle_id",
+ "chunk_id",
+ "text",
+ "score"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "results"
+ ],
+ "type": "object"
+}summarize_document1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "key_points": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "key_points_cited": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "citations": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "artifact": {
+ "type": "string"
+ },
+ "char_end": {
+ "type": "number"
+ },
+ "char_start": {
+ "type": "number"
+ },
+ "chunk_id": {
+ "type": "string"
+ },
+ "confidence": {
+ "enum": [
+ "high",
+ "medium",
+ "low"
+ ],
+ "type": "string"
+ },
+ "page": {
+ "type": "number"
+ },
+ "paragraphs": {
+ "items": {
+ "type": "number"
+ },
+ "type": "array"
+ },
+ "quote": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "quote",
+ "paragraphs",
+ "confidence"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "text": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "text",
+ "citations"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "strategy": {
+ "enum": [
+ "full",
+ "truncated",
+ "chunked"
+ ],
+ "type": "string"
+ },
+ "summary": {
+ "type": "string"
+ },
+ "summary_cited": {
+ "additionalProperties": false,
+ "properties": {
+ "citations": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "artifact": {
+ "type": "string"
+ },
+ "char_end": {
+ "type": "number"
+ },
+ "char_start": {
+ "type": "number"
+ },
+ "chunk_id": {
+ "type": "string"
+ },
+ "confidence": {
+ "enum": [
+ "high",
+ "medium",
+ "low"
+ ],
+ "type": "string"
+ },
+ "page": {
+ "type": "number"
+ },
+ "paragraphs": {
+ "items": {
+ "type": "number"
+ },
+ "type": "array"
+ },
+ "quote": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "quote",
+ "paragraphs",
+ "confidence"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "confidence": {
+ "enum": [
+ "high",
+ "medium",
+ "low"
+ ],
+ "type": "string"
+ },
+ "value": {}
+ },
+ "required": [
+ "value",
+ "confidence",
+ "citations"
+ ],
+ "type": "object"
+ },
+ "truncated": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "summary",
+ "key_points",
+ "summary_cited",
+ "key_points_cited",
+ "truncated",
+ "strategy"
+ ],
+ "type": "object"
+}summarize_url1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "key_points": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "summary": {
+ "type": "string"
+ },
+ "truncated": {
+ "type": "boolean"
+ },
+ "url": {
+ "type": "string"
+ },
+ "word_count": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "url",
+ "truncated"
+ ],
+ "type": "object"
+}translate_url1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "target_lang": {
+ "type": "string"
+ },
+ "translated_text": {
+ "type": "string"
+ },
+ "truncated": {
+ "type": "boolean"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "url",
+ "target_lang",
+ "truncated"
+ ],
+ "type": "object"
+}verify_bundle1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "attestation_tx": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "bundle_id": {
+ "type": "string"
+ },
+ "captured_at": {
+ "type": "string"
+ },
+ "checks": {
+ "additionalProperties": false,
+ "properties": {
+ "artifacts": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "actual": {
+ "type": "string"
+ },
+ "expected": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "ok": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "name",
+ "ok"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "attestation": {
+ "anyOf": [
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "manifest_hash": {
+ "type": "boolean"
+ },
+ "signature": {
+ "anyOf": [
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "status": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "status",
+ "manifest_hash",
+ "signature",
+ "artifacts",
+ "attestation"
+ ],
+ "type": "object"
+ },
+ "manifest_sha256": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "signer_address": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "tampered": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "url": {
+ "type": "string"
+ },
+ "valid": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "bundle_id",
+ "valid",
+ "manifest_sha256",
+ "checks",
+ "tampered"
+ ],
+ "type": "object"
+}add_document_to_collection3 fields changedInput schema / properties / bundle_id / descriptionPrevious value: -"Evidence bundle ID (ev_...) to add. Bundle must have status \"complete\"."New value: +"Evidence bundle ID (ev_...) to add. Bundle must have status \"complete\". Example: \"ev_550e8400-e29b-41d4-a716-446655440000\""Input schema / properties / collection_id / descriptionPrevious value: -"Collection ID (col_...) returned by create_collection"New value: +"Collection ID (col_...) returned by create_collection. Example: \"col_550e8400-e29b-41d4-a716-446655440000\""Input schema / properties / title / descriptionPrevious value: -"Optional display title for the document in this collection"New value: +"Optional display title for the document in this collection. Example: \"Q4 2025 Financial Report\""ask_collection3 fields changedInput schema / properties / collection_id / descriptionPrevious value: -"Collection ID (col_...) returned by create_collection"New value: +"Collection ID (col_...) returned by create_collection. Example: \"col_550e8400-e29b-41d4-a716-446655440000\""Input schema / properties / max_chunks / descriptionPrevious value: -"Max chunks to retrieve for context (default 8). Increase for broad questions, decrease for precision."New value: +"Max chunks to retrieve for context (default 8). Increase for broad questions, decrease for precision. Example: 12"Input schema / properties / question / descriptionPrevious value: -"Natural language question to answer from collection documents"New value: +"Natural language question to answer from collection documents. Example: \"What are the key terms of the service agreement?\""check_claims3 fields changedInput schema / properties / claims / descriptionPrevious value: -"Factual statements to verify, e.g. [\"Founded in 2010\", \"Revenue exceeded $1M\"]"New value: +"Factual statements to verify. Each claim is checked independently against the text. Example: [\"Founded in 2010\", \"Revenue exceeded $1M\"]"Input schema / properties / max_tokens / descriptionPrevious value: -"Input length cap (1 token ≈ 4 chars). Default ~3000 tokens. Truncates input, not output."New value: +"Input length cap (1 token ≈ 4 chars). Default ~3000 tokens. Truncates input text, not the output. Example: 4000"Input schema / properties / text / descriptionPrevious value: -"Document text to check claims against. Obtain via extract_text or extract_url."New value: +"Document text to check claims against. Obtain via extract_text or extract_url. Example: \"ACME Corp was founded in 2010. Revenue exceeded $1M in 2024.\""create_collection1 field changedInput schema / properties / name / descriptionPrevious value: -"Human-readable collection name, e.g. \"Q4 Contracts\" or \"Due Diligence Docs\""New value: +"Human-readable collection name. Example: \"Q4 Contracts\" or \"Due Diligence Docs\""extract_structured3 fields changedInput schema / properties / max_tokens / descriptionPrevious value: -"Input length cap (1 token ≈ 4 chars). Default ~2500 tokens. Truncates input, not output."New value: +"Input length cap (1 token ≈ 4 chars). Default ~2500 tokens. Truncates input, not output. Example: 3000"Input schema / properties / schema / descriptionPrevious value: -"Field map: { \"field_name\": \"type hint\" }, e.g. { \"total_usd\": \"number\", \"vendor\": \"string\", \"invoice_date\": \"ISO date YYYY-MM-DD\" }"New value: +"Field map: describe each field you want extracted with a type hint. Example: { \"total_usd\": \"number\", \"vendor\": \"string\", \"invoice_date\": \"ISO date YYYY-MM-DD\" }"Input schema / properties / text / descriptionPrevious value: -"Document text to extract from. Obtain via extract_text or extract_url."New value: +"Document text to extract from. Obtain via extract_text or extract_url. Example: \"This Service Agreement is entered into on 2025-03-15 between ACME Corp and Beta Inc...\""extract_tables2 fields changedInput schema / properties / document_base64 / descriptionPrevious value: -"Base64-encoded PDF or image bytes (max ~15 MB)"New value: +"Base64-encoded PDF or image bytes (max ~15 MB). Example: \"JVBERi0xLjcNJeLjz9MNCj...\" (truncated PDF base64)"Input schema / properties / mime_type / descriptionPrevious value: -"MIME type: application/pdf | image/jpeg | image/png | image/webp"New value: +"MIME type of the document. Example: \"application/pdf\" for PDF bank statements, \"image/jpeg\" for photo of a form."extract_text2 fields changedInput schema / properties / document_base64 / descriptionPrevious value: -"Base64-encoded PDF or image bytes (max ~15 MB)"New value: +"Base64-encoded PDF or image bytes (max ~15 MB). Example: \"JVBERi0xLjcNJeLjz9MNCj...\" (truncated PDF base64)"Input schema / properties / mime_type / descriptionPrevious value: -"MIME type: application/pdf | image/jpeg | image/png | image/webp"New value: +"MIME type of the document. Example: \"application/pdf\" for PDFs, \"image/png\" for PNG screenshots."extract_url1 field changedInput schema / properties / url / descriptionPrevious value: -"Public HTTPS URL to fetch and extract"New value: +"Public HTTPS URL to fetch and extract. Example: \"https://example.com/report.pdf\" or \"https://blog.example.com/article\""get_bundle1 field changedInput schema / properties / bundle_id / descriptionPrevious value: -"Evidence bundle ID (ev_...) returned by extract or notarize_bundle"New value: +"Evidence bundle ID (ev_...) returned by extract or notarize_bundle. Example: \"ev_550e8400-e29b-41d4-a716-446655440000\""get_job_status1 field changedInput schema / properties / job_id / descriptionPrevious value: -"Job ID (job_...) returned by async extract or add_document_to_collection"New value: +"Job ID (job_...) returned by async extract or add_document_to_collection. Example: \"job_550e8400-e29b-41d4-a716-446655440000\""list_collections2 fields changedInput schema / properties / limit / descriptionPrevious value: -"Max collections to return (default 50, max 100)"New value: +"Max collections to return (default 50, max 100). Example: 20"Input schema / properties / offset / descriptionPrevious value: -"Pagination offset (default 0)"New value: +"Pagination offset (default 0). Example: 0"notarize_bundle1 field changedInput schema / properties / bundle_id / descriptionPrevious value: -"Evidence bundle ID (ev_...) to notarize. Bundle must have status \"complete\"."New value: +"Evidence bundle ID (ev_...) to notarize. Bundle must have status \"complete\". Example: \"ev_550e8400-e29b-41d4-a716-446655440000\""parse_invoice2 fields changedInput schema / properties / document_base64 / descriptionPrevious value: -"Base64-encoded PDF or image of the receipt/invoice (max ~15 MB)"New value: +"Base64-encoded PDF or image of the receipt/invoice (max ~15 MB). Example: \"JVBERi0xLjcNJeLjz9MNCj...\" (base64-encoded invoice PDF)"Input schema / properties / mime_type / descriptionPrevious value: -"MIME type: application/pdf | image/jpeg | image/png | image/webp"New value: +"MIME type of the document. Example: \"application/pdf\" for scanned invoice PDF, \"image/jpeg\" for a receipt photo."qa_url3 fields changedInput schema / properties / max_tokens / descriptionPrevious value: -"Input length cap (1 token ≈ 4 chars). Truncates fetched page content, not the answer."New value: +"Input length cap (1 token ≈ 4 chars). Truncates fetched page content, not the answer. Example: 4000"Input schema / properties / question / descriptionPrevious value: -"Specific question to answer from the page content"New value: +"Specific question to answer from the page content. Example: \"What is the refund policy?\""Input schema / properties / url / descriptionPrevious value: -"Public HTTPS URL to fetch and question"New value: +"Public HTTPS URL to fetch and question. Example: \"https://docs.example.com/policy\""search_collection3 fields changedInput schema / properties / collection_id / descriptionPrevious value: -"Collection ID (col_...) returned by create_collection"New value: +"Collection ID (col_...) returned by create_collection. Example: \"col_550e8400-e29b-41d4-a716-446655440000\""Input schema / properties / limit / descriptionPrevious value: -"Max chunks to return (default 10)"New value: +"Max chunks to return (default 10, max 50). Example: 5"Input schema / properties / query / descriptionPrevious value: -"Natural language search query"New value: +"Natural language search query. Example: \"What were the revenue numbers for Q4?\""summarize_document2 fields changedInput schema / properties / max_tokens / descriptionPrevious value: -"Input length cap (1 token ≈ 4 chars). Default ~3000 tokens. Truncates input, not output."New value: +"Input length cap (1 token ≈ 4 chars). Default ~3000 tokens. Truncates input, not output. Example: 4000"Input schema / properties / text / descriptionPrevious value: -"Document text to summarize. Obtain via extract_text or extract_url."New value: +"Document text to summarize. Obtain via extract_text or extract_url. Example: \"The Q4 2025 financial report shows revenue growth of 23% year-over-year...\""summarize_url2 fields changedInput schema / properties / max_tokens / descriptionPrevious value: -"Input length cap (1 token ≈ 4 chars). Truncates fetched page content, not the output summary."New value: +"Input length cap (1 token ≈ 4 chars). Truncates fetched page content, not the output summary. Example: 4000"Input schema / properties / url / descriptionPrevious value: -"Public HTTPS URL to fetch and summarize"New value: +"Public HTTPS URL to fetch and summarize. Example: \"https://en.wikipedia.org/wiki/Artificial_intelligence\""translate_url3 fields changedInput schema / properties / max_tokens / descriptionPrevious value: -"Input length cap (1 token ≈ 4 chars). Truncates fetched page content before translation."New value: +"Input length cap (1 token ≈ 4 chars). Truncates fetched page content before translation. Example: 4000"Input schema / properties / target_lang / descriptionPrevious value: -"ISO 639-1 language code, e.g. \"es\" (Spanish), \"fr\" (French), \"de\" (German), \"ja\" (Japanese)"New value: +"ISO 639-1 language code for the target language. Example: \"es\" for Spanish, \"fr\" for French, \"de\" for German, \"ja\" for Japanese, \"zh\" for Chinese"Input schema / properties / url / descriptionPrevious value: -"Public HTTPS URL to fetch and translate"New value: +"Public HTTPS URL to fetch and translate. Example: \"https://example.de/artikel\""verify_bundle1 field changedInput schema / properties / bundle_id / descriptionPrevious value: -"Evidence bundle ID (ev_...) returned by extract or notarize"New value: +"Evidence bundle ID (ev_...) returned by extract or notarize. Example: \"ev_550e8400-e29b-41d4-a716-446655440000\""add_document_to_collectionask_collectioncheck_claimscreate_collectionextract_structuredextract_tablesextract_textextract_urlget_bundleget_job_statusget_quotalist_collectionsnotarize_bundleparse_invoiceqa_urlsearch_collectionsummarize_documentsummarize_urltranslate_urlverify_bundle
Add one secure layer between your agents and this server.