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 21 tools
The descriptions are excellent at steering selection, explicitly saying 'for X use Y instead' (search_collection vs ask_collection, extract_text vs extract_url, get_bundle vs verify_bundle). Minor overlap remains within the extract family (extract_text/extract_tables/extract_url) and the field-extraction pair (extract_structured vs parse_invoice), but each still targets a distinct input/action.
Nearly all tools follow a consistent snake_case verb_noun pattern (extract_text, create_collection, verify_bundle, summarize_url). The only real outlier is 'qa_url', which is a noun-ish label rather than a verb, but it remains readable and predictable.
21 tools is on the higher end and straddles the 'heavy' guideline, but the server spans several genuinely distinct domains (extraction, collections/RAG, notarization, verification, jobs/quota), so most tools earn their place rather than being padding.
The surface covers a broad lifecycle: extraction, summarization, Q&A, translation, collection creation/population/search, plus notarization and integrity verification with quota/job introspection. Gaps exist around collections/bundles lifecycle (no delete_collection or remove-from-collection, no list_bundles), but these are workaroundable and evidence bundles are immutable by design.
Add an evidence bundle to a collection and trigger async vector indexing. Use after create_collection to populate a collection with documents. Once indexed, documents become searchable via search_collection and ask_collection. Indexing is async — poll get_job_status with the returned job_id until status is "complete". PREREQUISITE: Bundle must have status "complete" (check with get_bundle). Collection must be owned by your API key. Returns: { collection_id, bundle_id, job_id (poll for indexing completion) } 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 create_collection. 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?
Annotations cover safety (idempotentHint=true, destructiveHint=false, readOnlyHint=false), and the description adds substantial non-annotation context: indexing is asynchronous, the returned job_id must be polled via get_job_status until 'complete', and documents only become searchable after indexing. It also discloses the preconditions on bundle status and collection ownership.
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?
Front-loaded with the core action and side effect, followed by prerequisites, return shape, and example prompts in a scannable structure. The three example prompts are somewhat redundant given the clear prose but aid invocation grounding; minor bulk only.
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 an async mutation with an output schema, the description covers the prerequisite checks, the async polling contract, the returned job_id, and the downstream searchability. Nothing an agent needs to call and follow up correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters are already documented, including the bundle 'complete' status requirement and the collection_id provenance. The description's parameter-level content largely restates the schema, adding only the ownership constraint, so the 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?
States a specific verb and resource ('Add an evidence bundle to a collection') plus the side effect ('trigger async vector indexing'), which distinguishes it from siblings like create_collection and search_collection. An agent can identify the operation without opening the schema.
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 after create_collection', states prerequisites (bundle status must be 'complete', collection must be owned by your API key), and routes the agent to get_bundle, get_job_status, search_collection, and ask_collection for the follow-on steps. When-to-use and alternatives are both covered.
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 search_collection instead. For single-document Q&A, use qa_url instead. PREREQUISITE: Collection must be populated via add_document_to_collection 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 create_collection. 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 cover the safety profile (readOnly, idempotent), and the description adds genuinely non-obvious behavior: the prerequisite that the collection must be populated and indexed before results appear, and the two-stage retrieve-then-synthesize flow. It also sketches the return shape, though that overlaps with the output schema, keeping it short of 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?
Front-loaded with purpose then routing then prerequisite, and each block earns its place. The example prompts add realistic usage color but make the definition longer than strictly necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the description covers purpose, alternatives, the indexing prerequisite, and the retrieval/synthesis behavior; the structured output schema handles return-value detail. Nothing an agent needs to call this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so question, max_chunks (with default and tuning guidance), and collection_id are already documented in the schema. The description adds no syntax or format detail beyond that, so the 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?
States a specific verb+resource: RAG-based question answering over a document collection, and explicitly contrasts itself with search_collection (raw chunks) and qa_url (single-document Q&A). An agent can distinguish it from all three relevant siblings without opening a schema.
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?
Gives an explicit use condition ('need a direct answer grounded in your collection documents') plus two named alternatives with the selection criteria for each. This is the when/when-not/alternative pattern at full strength.
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 extract_text or extract_url when you need to validate specific factual assertions. For open-ended questions about a document, use qa_url instead. For multi-document investigation, use ask_collection. Typical workflow: extract_text/extract_url → 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 extract_text or extract_url. 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, so the safety profile is covered and the description only needs to add incrementally. It does add useful context (quality AI model, citation-level evidence, max_tokens truncates input not output), but it spends most of its length restating the return shape, which is redundant given the output schema exists. Net additive value is modest.
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 opening purpose sentence and the sibling-routing sentence are tightly front-loaded and earn their place. However, the verbatim 'Returns:' block duplicates the output schema already attached to the tool, and the three example prompts largely repeat the same pattern, adding bulk without new decision-relevant information.
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 3-parameter read-only tool with a full output schema and complete annotation coverage, the description supplies everything an agent needs: what it does, when to use it, which siblings to prefer instead, the upstream workflow, and worked examples. Nothing material is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters are already fully documented with examples. The description adds no new syntax, format, or constraint information about text/claims/max_tokens beyond what the schema provides, so the 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?
States a specific verb and resource ('Verify a list of factual claims against document text') and immediately distinguishes itself from siblings qa_url (open-ended questions) and ask_collection (multi-document investigation). The claim-status model is concrete enough that an agent can tell exactly what this tool does without opening the schema.
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?
Gives an explicit precondition ('Use after extract_text or extract_url'), an explicit alternative for the open-ended case (qa_url), and an explicit alternative for multi-document work (ask_collection). It even spells out the intended workflow chain, leaving nothing to inference.
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 (search_collection) or question answering (ask_collection). NOTE: Collections start empty. Add evidence bundles with add_document_to_collection. Indexing is async — once complete, use search_collection or ask_collection. 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?
With annotations covering the safety profile, the description still adds useful behavior: no credits consumed, collection starts empty, and indexing is asynchronous with search/ask available only after completion. It omits whether repeating the same name creates a duplicate despite idempotentHint=false being called out in 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?
Front-loaded with the core purpose, then NOTE/Returns/example sections in a scannable order. The three example prompts are somewhat repetitive and could be trimmed, but each section earns its place and nothing is buried.
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?
Covers the creation-to-search lifecycle and repeats the return shape, which is useful even though an output schema exists. The only meaningful gap is name uniqueness/duplicate-creation behavior, which is left ambiguous for a non-idempotent create.
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% and the single 'name' parameter is already documented with an example format, so the schema carries the semantics. The description's example prompts reinforce naming style but add no constraints or format rules beyond what the schema provides; 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?
States a specific verb (create) and resource (named document collection) and scopes it to cross-document semantic search and RAG Q&A. It names the sibling tools it feeds into (search_collection, ask_collection) and the sibling that populates it (add_document_to_collection), so it is distinguishable from them without opening either schema.
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 when to use it: 'Use when you want to group related evidence bundles for unified search ... or question answering.' It also names the alternative downstream tools and the prerequisite step (add_document_to_collection), leaving no inference needed.
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, parse_invoice (prebuilt schema) may be simpler. For general summarization, use summarize_document 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 extract_text or extract_url. 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 cover the read-only/idempotent profile, so the description earns credit by adding non-schema behavior: the quality AI model and retry logic. It also discloses the confidence/citation behavior of results, though the return shape is largely echoed from the output 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?
Front-loaded and well-sectioned, with purpose and routing before schema/return detail. The return-shape block and three example prompts are somewhat redundant given a formal output schema and a fully covered input schema, so it is slightly longer than necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a nested-object, caller-schema-driven tool this covers the essentials: routing, schema construction, and result shape. Minor gap is the absence of failure/partial-extraction behavior (what happens when a field cannot be found), which matters more than the return-format text that the output schema already supplies.
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% (baseline 3), and the description still adds real value by explaining the caller-defined schema map format with a concrete example and by clarifying schema is a field-to-type-hint map rather than a JSON Schema document. It does not extend to the max_tokens truncation semantics, which live only in 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?
States a specific verb+resource ('Extract typed fields from document text') and scopes it with 'using a caller-defined schema', which cleanly separates it from sibling extractors. It explicitly names the confusable siblings it is not (parse_invoice, summarize_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?
Gives an explicit condition ('when you need specific data points rather than full text') plus two named alternatives with the conditions that select them: parse_invoice for known invoice fields, summarize_document for summarization. No inference required.
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 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 and idempotentHint, so the safety profile is covered. The description adds that input may be a base64 image or PDF and that output is Markdown, but it adds no operational detail beyond the schema/annotations (size limits, OCR behavior, multi-page handling) even though the size cap lives only in the schema description.
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?
Front-loaded with purpose, usage condition, and alternative in the first two sentences, then the return shape. The three example prompts are somewhat redundant with the usage sentence already given, which keeps it just short of a 5.
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?
An output schema exists and the description gratuitously restates the return shape, which is unnecessary but harmless. Combined with the sibling routing and complete parameter docs, an agent has everything needed; the only minor gap is that no behavioral edge cases (large files, non-tabular pages) are mentioned.
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% and both parameters are fully documented in the schema, including the mime_type enum. The description only restates that the document is base64-encoded, adding no syntax or format meaning beyond what is already there, so the 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?
States a specific verb and resource ('Extract tables and forms as Markdown'), names the input types (PDF or base64 image), and explicitly distinguishes itself from the sibling extract_text. An agent can route between the two without opening either schema.
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?
Gives an explicit use condition ('when the document contains structured tabular data such as financial statements, data sheets, or forms') and a named alternative for the opposite case ('For plain prose documents, use extract_text instead'). This is textbook when/when-not/alternative 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 extract_url 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 cover the safety profile (readOnlyHint, idempotentHint), and the description adds the accepted input forms and the base64-vs-URL tradeoff. The 'Returns: { pages, text }' line duplicates the existing output schema rather than adding behavior, and it omits limits like the ~15 MB cap (present only in 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?
Front-loaded with the core action and routing rule, and the three example prompts are genuinely useful for matching user phrasings. Minor waste in the 'Returns' line, which restates the output schema.
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 an output schema present and 100% schema coverage, the description only needs to carry intent and routing — both are fully covered, plus it names extract_structured/check_claims-adjacent downstream uses. Nothing needed to invoke correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already documented (including the size cap and MIME examples). The description adds no syntax or format detail beyond restating that input is base64-encoded PDF or image, so the 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?
States a specific verb and resource ('Extract plain text from a PDF or image') and immediately scopes it with the input form (base64-encoded), clearly distinguishing it from the sibling extract_url. An agent can select this tool without opening the schema.
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?
Gives explicit when-to-use ('raw text for downstream AI analysis — summarization, claim checking, structured extraction') and an explicit alternative with the selecting condition ('For documents at a public URL, use extract_url instead'). This is a textbook routing statement.
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 summarize_url for summaries, qa_url for Q&A, translate_url for translation, 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?
The description goes beyond annotations by disclosing a key behavioral trait: 'Lean mode — no evidence bundle stored, no bundle_id returned.' It also notes the return shape including 'final_url (after redirects)', which is useful context. Annotations (readOnlyHint, openWorldHint) cover safety and external interaction, but the description adds operational specifics about storage behavior and output. It could mention rate limits or auth requirements, but the core behaviors are well-covered.
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 structured: first sentence states the core action and output format, second sentence clarifies the 'lean' behavioral distinction, third sentence lists alternatives, and then a separate 'Returns' block and example prompts. Every sentence adds value, and information is front-loaded.
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 (1 parameter, output schema exists), the description provides complete context: it explains the lean mode, lists the return fields, and positions the tool within the sibling ecosystem. The agent has everything needed to call it correctly and understand its output.
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%, and the single parameter is fully documented in the schema with format and examples. The description adds no new parameter-level details, which is appropriate given the schema's completeness. Baseline 3 is correct when the schema already provides full semantic coverage.
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 verb ('Extract') and resource ('text from URL'), and it clearly distinguishes itself from siblings by naming the exact alternatives for different operations (summarize_url, qa_url, translate_url, extract_text). An agent can immediately tell this is raw text extraction without any summarization or Q&A.
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 this tool ('raw text extraction from web pages and online documents') and provides a clear mapping to alternatives for other intents (summarize_url for summaries, qa_url for Q&A, translate_url for translation, extract_text for base64 uploads). This is comprehensive routing guidance with no inference required.
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 verify_bundle instead. 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 } 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 notarize_bundle. 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 already establish readOnlyHint and idempotentHint. The description adds genuine context beyond them: 'Free — no credits consumed,' the meaning of status values (pending/complete/failed), and fields like superseded_by and legal_hold that signal bundle lifecycle. It does not cover error behavior for a nonexistent or foreign-owner bundle, so it stops short of 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 purpose, cost, and sibling routing are front-loaded in the first two sentences. The verbatim Returns block is somewhat redundant since an output schema exists, and the three example prompts pad the definition, but nothing is misleading.
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 single-parameter read tool with an output schema and safety annotations, the description covers purpose, cost, routing, and use cases completely. Minor redundancy in restating the return shape rather than a gap, though ownership/auth failure behavior is left unaddressed.
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?
Only one parameter and schema coverage is 100%, so the schema already documents the ev_... format and its origin. The description adds only the ownership scoping note ('owned by your API key'), which is useful but not a syntactic or semantic expansion. 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?
States a specific verb (retrieve) and resource (metadata for an evidence bundle), scopes it to the caller's API key, and explicitly distinguishes itself from verify_bundle, which handles deep cryptographic verification. An agent can route between the two without opening either schema.
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?
Gives concrete when-to-use cases (checking completeness, notarization status, retention/legal hold) and names the alternative tool plus the condition that selects it ('for deep cryptographic integrity verification... use verify_bundle instead').
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 add_document_to_collection 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 add_document_to_collection 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 add_document_to_collection. 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?
Annotations already declare readOnlyHint and idempotentHint, but the description adds material context beyond them: it is free with no credits consumed, it is meant to be polled repeatedly, and it explains how jobs are created (webhook extract or async indexing). That is exactly the extra disclosure the annotations cannot carry.
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?
Front-loaded with the core action and cost, then usage, then returns. The full return-shape block duplicates the existing output schema and is somewhat verbose, but the example prompts and job-creation note are cheap and useful.
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 a single-param, read-only polling tool with an output schema, the description covers everything an agent needs: trigger points, polling loop, terminal statuses, and validation via 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% for the single job_id parameter, and the description largely mirrors the schema by noting the ID comes from extract or add_document_to_collection. Baseline 3 is appropriate since the schema already does the work.
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?
States a specific verb (poll) and resource (async job status), and immediately scopes the job types it covers (extract, indexing, batch). An agent can distinguish this from list_collections or get_bundle without opening a schema.
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 names when to use it (after add_document_to_collection or an async extract) and how (poll in a loop until status is complete or failed). This is prescriptive sequencing guidance, not just implied context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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, so the safety profile is covered. The description adds a genuinely useful behavioral trait beyond the annotations: 'Free — no credits consumed,' plus the QUOTA_EXCEEDED failure mode. It stops short of noting rate limits or auth scope.
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?
Front-loaded with the purpose and the cost/error guidance, and the example prompts are a reasonable affordance. The inline 'Returns: {...}' block is somewhat redundant given a separate output schema exists, adding length without new information.
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 zero-arg read tool with an output schema, the description supplies everything an agent needs: purpose, cost behavior, when to call it, and a preview of the return shape. No meaningful gaps remain.
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?
Zero parameters, so there is no parameter semantics to document; the baseline for a no-arg tool is 4. Nothing in the description contradicts or complicates the empty 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?
States a specific verb+resource: 'Get current credit balance and plan details for your API key.' It is clearly distinguishable from siblings like extract_structured or summarize_document, which consume credits rather than report on them.
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 tells the agent when to call it ('Check this before running credit-consuming operations (extract, summarize, etc.)') and why ('to avoid QUOTA_EXCEEDED errors'). It names the relevant sibling categories, leaving nothing to inference.
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 search_collection or ask_collection 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 carry readOnlyHint and idempotentHint, so the safety profile is covered. The description adds value beyond that with the billing behavior ('Free — no credits consumed') and the supported pagination mechanism, though it doesn't disclose default page size limits itself (those live in 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?
Front-loaded with the core action and cost, then usage, then return shape, then examples. Every line earns its place and nothing is buried.
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?
An output schema exists, yet the description still summarizes the return shape, and it covers scope, cost, when-to-use, and pagination. Nothing an agent needs to call this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and both parameters already document defaults and max values, so the baseline is 3. The description only restates that pagination is supported via limit/offset without adding format or ordering 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?
States a specific verb and resource ('List all document collections owned by your API key') with clear scope (owned by your key). It also distinguishes itself from siblings by positioning itself as the ID-discovery step before search_collection and ask_collection.
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 when to use it ('before search_collection or ask_collection when you need the collection ID') and names the alternative tools. The cost note ('Free — no credits consumed') further helps an agent decide which call to prefer.
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 verify_bundle instead. PREREQUISITE: Bundle status must be "complete". Check status with get_bundle 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? } } 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?
Annotations only declare readOnlyHint=false and idempotentHint=true; the description goes well beyond that by disclosing gas cost (ETH), that the on-chain record is permanent and undeletable even after bundle purge, and how idempotency manifests (returns the existing attestation immediately). These are exactly the consequences an agent needs before committing an irreversible write.
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?
Front-loaded with the core action, then cleanly sectioned into PREREQUISITE, NOTE, Returns, and examples. Slightly long, and the Returns block plus three example prompts are somewhat redundant given an output schema exists, but each section is legible and earns most of its space.
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 single-parameter, irreversible on-chain write, the description covers purpose, alternative, prerequisite, cost, permanence, and idempotent behavior. The output schema already carries return structure, so nothing an agent needs to invoke this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single parameter already documents the ev_... format and the "complete" status requirement, so the schema does the heavy lifting. The description adds no syntax or format detail beyond it, making the baseline 3 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?
States a specific verb and resource (notarize an evidence bundle) plus the exact mechanism (writing its manifest SHA-256 on-chain to Base/EVM). It explicitly distinguishes itself from verify_bundle, so an agent can route between the two without opening either schema.
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?
Gives a clear when-to-use condition (need an immutable on-chain timestamp proving a document existed at a point in time), names the alternative (verify_bundle) for the cheaper path, and states the prerequisite (status must be "complete", check with get_bundle). Nothing is left to inference.
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 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?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is known. The description adds useful context beyond that: it uses a quality AI model for accuracy, and it discloses confidence levels and citations in the output. It omits auth/cost/rate-limit details, 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?
Front-loaded with purpose and routing, followed by a structured Returns block. The example prompts are somewhat redundant given the clear purpose but serve as invocation illustrations; overall slightly verbose but 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?
An output schema exists so return values need no explanation, yet the description still sketches the return shape. Combined with the routing guidance and 100% parameter coverage, an agent has everything needed to call this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters (document_base64, mime_type) are already fully documented with examples and the enum. The description adds no additional parameter syntax or constraints, so the 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?
States a specific verb (parse) and resource (receipt or invoice document) with the output (structured fields). It also explicitly distinguishes itself from the sibling extract_text, so an agent can route without opening either schema.
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?
Gives an explicit when-to-use ('extract line items, totals, and merchant info from financial documents') and names the alternative for a different need ('For general document text, use extract_text instead'). When and when-not are both covered.
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 summarize_url. For multi-document Q&A, use ask_collection 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 cover the safety profile (readOnlyHint, openWorldHint), but the description adds meaningful context beyond them: 'Lean mode — no bundle stored' discloses persistence behavior, and max_tokens is noted to truncate fetched content rather than the answer. It stops short of describing rate limits or error behavior, so a 4.
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?
Purpose, guidance, and returns are front-loaded in the first sentences with zero filler. The three example prompts are somewhat redundant given the clear prose, marginally costing conciseness but still illustrating realistic phrasing.
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 an output schema present, the description needn't detail return values, and safety is covered by annotations. The description still covers scope, alternatives, and the no-bundle/truncation behavior, leaving only edge cases like error or non-public URL handling unaddressed.
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 all three parameters are already documented, including the max_tokens truncation caveat. The description adds only example prompts and the HTTPS requirement, which the schema's uri format already implies. Baseline 3 applies when the schema does the heavy lifting.
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?
States a specific verb and resource ('Fetch a public HTTPS URL and answer a specific question about its content') and immediately disambiguates itself from summarize_url and ask_collection. An agent can distinguish this from all sibling extraction/QA tools without opening a schema.
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 ('a precise question about a web page') plus named alternatives for adjacent cases: summarize_url for broad summaries and ask_collection for multi-document Q&A. Routing conditions are fully spelled out, not left to inference.
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 ask_collection instead. PREREQUISITE: Collection must be populated via add_document_to_collection and async indexing must complete (poll get_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 create_collection. 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 safety profile is covered. The description adds genuinely new behavioral context: cost ('Free — no credits consumed'), the async-indexing prerequisite that gates whether results appear, and the return shape. It stops short of error/rate-limit behavior, 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?
Front-loads purpose, then usage routing, prerequisites, return shape, and examples in a logical order. Slightly long, and the explicit 'Returns' block partially duplicates the existing output schema, but every section carries useful information.
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?
Covers purpose, routing, prerequisites, cost, and return shape; combined with annotations and the output schema, an agent has everything needed to invoke it correctly, including the two-step indexing dependency that would otherwise cause empty results.
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% and the schema already documents all three params including the limit default/max and query examples. The description adds no parameter syntax or format detail beyond that, so the 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?
States a specific verb+resource ('semantic (vector) search across documents in a collection') and immediately distinguishes its output ('ranked text chunks with relevance scores') from the sibling ask_collection. An agent can pick this tool over ask_collection without opening either schema.
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?
Gives explicit when-to-use ('when you need raw matching chunks from a collection') and names the alternative with its condition ('for a synthesized cited answer... use ask_collection instead'). It adds a concrete prerequisite workflow (populate via add_document_to_collection, poll get_job_status) and example prompts.
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 extract_text or extract_url when you need a condensed understanding of a long document. For single-sentence Q&A, use qa_url instead. For extracting specific fields, use extract_structured. Typical workflow: extract_text/extract_url → summarize_document. 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 extract_text or extract_url. 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 declare readOnlyHint and idempotentHint, covering safety and repeatability. The description adds valuable behavioral detail beyond annotations: the exact return structure, the 'truncated' flag, and the 'strategy' values (full/truncated/chunked). It does not cover error handling or rate limits, but for a read-only summarizer this is a minor gap.
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 purpose, then usage, workflow, return structure, and example prompts. It is well-organized and every section earns its place, though the example prompts are somewhat redundant for an agent that already understands the tool's purpose and alternatives.
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 (summarization with citations), the rich input schema, clear annotations, and presence of an output schema, the description is complete. It covers purpose, workflow, alternatives, and even return value details, leaving no obvious gaps for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with detailed descriptions for 'text' and 'max_tokens' including examples and the note that max_tokens truncates input, not output. The description itself adds no parameter-level semantics beyond what the schema already provides, 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?
States a specific verb (Summarize) and resource (document text) and explicitly distinguishes from siblings by naming alternatives: qa_url for single-sentence Q&A and extract_structured for extracting specific fields. An agent can select this tool without opening other definitions.
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 when-to-use context: 'Use after extract_text or extract_url when you need a condensed understanding of a long document.' It also names alternatives and the condition that selects them, plus a typical workflow 'extract_text/extract_url → summarize_document'.
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 extract_url. For asking a specific question about a page, use qa_url. 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, so the safety profile is covered. The description adds genuinely useful context beyond that: 'Lean mode — no bundle stored', which matters given siblings like get_bundle/verify_bundle in the same family, and it declares the return shape. It stops short of noting rate limits, auth needs, or behavior on fetch failure, so not a full 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?
Front-loads purpose, then alternatives, then return shape, then example prompts in a tight sequence. The example prompts are somewhat expendable, but they demonstrate correct phrasing and earn their place for a URL tool where input format matters.
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 two-parameter read-only tool with annotations covering safety and an output schema, the description is nearly complete: purpose, routing, mode, and return fields are all present. Only edge-case behavior (invalid/non-HTTPS URLs, fetch failures) is unaddressed.
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 both url and max_tokens are already documented in the schema, including the important note that max_tokens truncates input rather than output. The description adds no parameter-level detail beyond that, so the 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?
States a specific verb+resource ('fetch a public HTTPS URL and return a prose summary with key points') and explicitly distinguishes itself from two named siblings, extract_url and qa_url. An agent can pick this apart from the other URL tools without opening any schema.
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?
Gives an explicit when-to-use ('need a condensed understanding of a web page') plus two when-to-use-something-else clauses routing to extract_url for raw text and qa_url for targeted questions. Nothing is left to inference.
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 extract_url 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?
Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds real context beyond that: lean mode with no bundle stored (relevant given the get_bundle/verify_bundle siblings), an HTTPS-only public-URL constraint, and a truncated return field that warns output may be cut short.
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?
Front-loads the core capability, then the mode note, then the sibling routing, then the return shape. Example prompts are compact and each sentence carries usable information; no 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 three-parameter read tool with an output schema and full annotation coverage, the description supplies the missing pieces: fetch constraints, mode behavior, sibling routing, and the return shape. An agent has everything needed to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description still adds meaning beyond the schema by restricting url to public HTTPS endpoints and by framing truncation as a result-shaping concern rather than just a cap.
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?
States a specific verb+resource with scope: 'Fetch a public HTTPS URL and return its content translated into a target language.' It explicitly distinguishes itself from the sibling extract_url, so an agent can route correctly without opening either schema.
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?
Gives a clear use condition ('when you need to understand web content in a different language') and names the concrete alternative plus the condition that selects it ('For extracting raw untranslated text, use extract_url instead'). Nothing is left to inference.
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 get_bundle, verify_bundle, notarize_bundle, or add_document_to_collection. 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 only declare readOnlyHint and idempotentHint; the description adds non-obvious behavioral facts: it is free (no credits), it verifies two distinct conditions (signature authenticity AND manifest still current), and it detects stale/superseded documents. That is real context beyond 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?
Front-loaded with the core action, cost, and proof semantics in the first two sentences; example prompts aid disambiguation. The inline Returns block slightly overlaps the existing output schema, but the overall structure is tight and earns its space.
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?
A one-parameter read tool with annotations and an output schema; the description covers purpose, source of input, cost, semantic guarantees, and audit context. Nothing needed to call it correctly 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 coverage is 100% and the single receipt_id parameter is fully documented in the schema, so the description need not add syntax. It does reinforce where the ID comes from (the receipt field of another tool's response), but that largely mirrors 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?
Specific verb+resource: 'Independently verify a signed action receipt (rcpt_...)'. It names the exact source tools that produce receipts and contrasts implicitly with verify_bundle's bundle-level check, letting an agent route correctly without opening the schema.
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 scopes the use case ('Use for third-party audit of an agent's prior actions') and names the four sibling tools whose responses supply the receipt_id, plus concrete example prompts. An agent knows exactly when and why to reach for this.
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 get_bundle instead. 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 } 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 cover the safety profile (readOnlyHint, idempotentHint), but the description adds real value: what is actually checked (manifest hash, EIP-191 signature, R2 artifact hashes) and the cost model ('Free — no credits consumed'). It stops short of disclosing failure modes or latency, so a 4 rather than 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 core sentences are front-loaded and efficient, but the inline 'Returns:' block restates the output schema verbatim and the example prompts are boilerplate. Both duplicate structured data the agent already receives, diluting the concise core.
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?
A single-parameter, read-only verification tool with an output schema, full annotation coverage, and a schema-documented parameter. Everything needed to select and invoke it correctly is present, including the sibling hand-off.
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% and the schema already documents bundle_id with the ev_ prefix and example. The description's '(ev_...)' and the ownership-by-API-key note marginally reinforce it but add no syntax or format detail beyond the schema. Baseline 3 is correct.
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?
States a specific verb (verify), resource (evidence bundle), scope (cryptographic integrity), and ownership constraint (owned by your API key). It also explicitly routes away from get_bundle, so an agent can distinguish this from its closest sibling without opening the schema.
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?
Gives the trigger condition ('confirm a bundle has not been tampered with') and names the alternative with the condition that selects it ('quick metadata lookups ... use get_bundle instead'). No inference required.
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_bundleaccount.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.