DocImprint
Server Details
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.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.6/5 across 20 of 20 tools scored.
Each tool has a clearly distinct purpose with detailed usage descriptions. For example, extract_text vs extract_url vs extract_tables are well-separated, and ask_collection vs search_collection vs qa_url are differentiated by scope and output type.
All tool names follow a consistent verb_noun pattern in snake_case, such as create_collection, extract_text, verify_bundle. The naming is predictable and makes tool roles immediately clear.
With 20 tools, the server covers a broad document processing domain (extraction, summarization, search, claims, notarization). While slightly above the ideal 3-15 range, each tool serves a specific function and the count feels justified.
The tool surface covers the full ingestion-to-query pipeline for documents, including OCR, extraction, collections, Q&A, and verification. Minor gaps exist (e.g., no delete/update for collections or bundles), but the core workflows are fully supported.
Available Tools
21 toolsadd_document_to_collectionAdd Document to CollectionAIdempotentInspect
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" |
Output Schema
| Name | Required | Description |
|---|---|---|
| job_id | Yes | |
| receipt | Yes | |
| bundle_id | Yes | |
| collection_id | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-read-only, idempotent, and non-destructive behavior. The description adds critical context: async vector indexing, polling with job_id, and prerequisite checks on bundle status. No contradiction with annotations; the description enriches the behavioral model 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?
The description is concise and well-structured: main action first, then usage context, prerequisites, return format, and example prompts. Every sentence serves a purpose with no redundancy. It is front-loaded and 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?
Given the tool's complexity (async indexing, prerequisites, polling, ownership) and the presence of a complete input schema and output schema description, the description covers all necessary aspects: action, async behavior, polling mechanism, prerequisites, and examples. No gaps are apparent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameter descriptions in the schema already define each field. The description adds value by tying parameters to prerequisites (e.g., bundle_id must be from a complete bundle) and clarifying the meaning of title as optional display name. However, the primary semantics are already in the schema, so the description's addition is moderate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add an evidence bundle to a collection') and specifies the async indexing behavior. It distinguishes from siblings by noting that after indexing, documents become searchable via 'search_collection' and 'ask_collection', and directs usage to follow 'create_collection'. This meets the criteria for a specific verb+resource with sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use ('Use after create_collection'), includes prerequisites (bundle status must be 'complete', collection owned by API key), and provides example prompts. It also explains the indexing lifecycle and how to monitor completion via 'get_job_status'. This provides clear guidance on when to use and what to check.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ask_collectionAsk CollectionARead-onlyIdempotentInspect
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" |
Output Schema
| Name | Required | Description |
|---|---|---|
| answer | Yes | |
| sources | Yes | |
| retrieval | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true and idempotentHint=true, and the description adds behavior: retrieves chunks then synthesizes answer with citations. It also states the prerequisite that the collection must be populated and indexed. No contradictions. Could be slightly more detailed about edge cases (e.g., no relevant chunks), but overall well-transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear main sentence, usage guidance, prerequisites, return format, and examples. It is not overly verbose, though some details (like the example prompts) could be considered extraneous. Still, it earns its sentences.
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 (3 parameters, 100% schema coverage, output schema present, annotations present), the description is complete. It explains the RAG process, distinguishes siblings, provides prerequisites, and includes the return structure. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good descriptions for each parameter. The description adds value by providing examples for each parameter and guidance on max_chunks usage (default 8, increase for broad questions). This goes beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool uses RAG to answer a question from a document collection, producing a cited answer with source attribution. It effectively distinguishes from siblings like search_collection (raw chunks without synthesis) and qa_url (single-document Q&A), so the agent can select appropriately.
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 guidance on when to use this tool (direct answer grounded in collection) versus alternatives (search_collection for raw matching, qa_url for single-document Q&A). Also includes a prerequisite about collection population and indexing, which is crucial for correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_claimsCheck ClaimsARead-onlyIdempotentInspect
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 |
Output Schema
| Name | Required | Description |
|---|---|---|
| claims | Yes | |
| truncated | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and idempotentHint. Description adds value by detailing AI model quality, citation-level evidence, return format with status fields, and truncation behavior. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose and usage, followed by return format and examples. Every sentence adds value with no fluff. Ideal length for an AI agent.
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 output schema exists, description still covers workflow, truncation handling, and provides multiple example prompts. All necessary context for correct invocation is present.
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%, but description enriches each parameter with concrete examples and extra context (e.g., 'max_tokens' truncates input, not output). Redundant examples further clarify usage.
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?
Description clearly states 'Verify a list of factual claims against document text' with specific verb and resource. Differentiates from sibling tools like qa_url (open-ended questions) and ask_collection (multi-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?
Explicitly provides when to use ('after extract_text or extract_url'), when not to use alternatives ('for open-ended questions, use qa_url'), and typical workflow. Includes example prompts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_collectionCreate CollectionAInspect
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" |
Output Schema
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| collection_id | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses it's free with no credits consumed, indexing is async, and returns specific fields. Annotations already indicate non-read-only, non-destructive. Adds value by explaining credit impact and async behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured: purpose, usage notes, return type, example prompts. Could be slightly more concise, but no wasted sentences. Front-loaded with key action.
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 low complexity (1 param, output schema present), the description fully covers purpose, usage, behavior, and return. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with description for name. Tool description adds example prompts and clarifies 'Human-readable collection name', enhancing understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'create', resource 'named document collection', and purpose 'cross-document semantic search and RAG-based Q&A'. Distinguishes from sibling tools like 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 'Use when you want to group related evidence bundles for unified search or question answering'. Also notes collections start empty and directs to add_document_to_collection. No explicit when-not-to-use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
extract_structuredExtract Structured DataARead-onlyIdempotentInspect
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 |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| data_cited | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds context beyond annotations: mentions 'quality AI model with retry logic', how max_tokens truncates input only, and details the return format. No contradiction with readOnlyHint or idempotentHint.
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?
Well-structured and front-loaded with main purpose. Usage guidance, schema format, return format, and example prompts are all included without redundancy. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (3 parameters, output schema exists), the description is comprehensive. It explains how to use the tool, what to expect as output, and provides example prompts. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and description adds value: for text parameter, it suggests sources; for schema, gives format example; for max_tokens, explains default and behavior. Goes beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'extract', the resource 'typed fields from document text', and the method 'using a caller-defined schema'. It distinguishes itself from siblings like parse_invoice and 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?
Explicitly states when to use ('when you need specific data points from a document') and when not (for invoices use parse_invoice, for summarization use summarize_document). Provides clear alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
extract_tablesExtract TablesARead-onlyIdempotentInspect
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) |
Output Schema
| Name | Required | Description |
|---|---|---|
| text | Yes | |
| pages | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and idempotentHint. Description adds return format (pages, text Markdown) and input constraints (base64, max 15 MB). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four purposeful sentences plus three example prompts. Front-loaded with core action and output, no redundant information. Efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, when to use, alternatives, return format, and provides example prompts. Given low complexity (2 params, output schema, annotations), description is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with well-described parameters. Description reinforces parameter roles but does not add new semantic details beyond the schema. Baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb (Extract), resource (tables and forms from PDF/image), and output format (Markdown). Distinguishes from sibling extract_text by specifying structured tabular data vs plain prose.
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 when to use (structured tabular data like financial statements, data sheets, forms) and when not (plain prose, referring to extract_text as alternative). Provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
extract_textExtract TextARead-onlyIdempotentInspect
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) |
Output Schema
| Name | Required | Description |
|---|---|---|
| text | Yes | |
| pages | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds details about input format, size limit, and return schema, complementing annotations. No contradiction.
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?
Concise and well-structured, with front-loaded purpose and examples. Slightly verbose for some, but clear.
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 all essential aspects: purpose, usage, parameters, return format, and alternatives. Complete for a simple extraction tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already describes parameters fully (100% coverage). Description adds examples but not new semantic info.
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?
Clearly states it extracts plain text from PDF or image (base64), and distinguishes from sibling tools like extract_url.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'use when you need raw text for downstream AI analysis' and suggests alternative for public URLs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
extract_urlExtract Text from URLARead-onlyInspect
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" |
Output Schema
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| text | Yes | |
| title | No | |
| final_url | No | |
| word_count | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, openWorldHint) indicate no side effects. Description adds 'Lean mode — no evidence bundle stored, no bundle_id returned', clarifying transient operation. Could mention potential size limits but not necessary.
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?
Concise: 4 sentences, return format, and example prompts. No extraneous info, front-loaded with key action.
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?
Low complexity (1 param, simple output), annotations present, output schema exists. Description covers purpose, usage, behavioral note, return structure, and examples.
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 (url) with 100% schema coverage; schema already provides format and example. Description adds minor context ('Public HTTPS URL') but not significant new meaning beyond 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?
Description clearly states 'Fetch a public HTTPS URL and return extracted text and page metadata', specifying verb, resource, and output. It differentiates from siblings by naming alternatives for summaries, Q&A, translation, and file uploads.
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 ('raw text extraction from web pages and online documents') and when not to use (summaries, Q&A, translation, base64 uploads) with alternatives provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_bundleGet Evidence BundleARead-onlyIdempotentInspect
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" |
Output Schema
| 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and idempotentHint=true. The description adds that it is 'Free — no credits consumed' and clarifies the synchronous nature of retrieving metadata. It does not contradict annotations and provides additional context beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (about 150 words) and well-structured: it starts with the core purpose, then provides usage guidelines, a bulleted list of return fields, and example prompts. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description summarizes return fields for quick reference. It covers when to use, what to expect, and gives concrete examples. For a simple retrieval tool, it is completely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description of the bundle_id parameter. The tool description does not add additional parameter semantics beyond what the schema provides, maintaining the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Retrieve metadata'), the resource ('evidence bundle'), and the scope ('owned by your API key'). It distinguishes the tool from its sibling verify_bundle, which is for 'deep cryptographic integrity verification'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool ('quick status/metadata lookups'), what it is not for ('For deep cryptographic integrity verification...'), and provides an alternative tool ('use verify_bundle instead'). It also notes that it is free and consumes no credits.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_job_statusGet Job StatusARead-onlyIdempotentInspect
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" |
Output Schema
| 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and idempotentHint. The description adds 'Free — no credits consumed' and clarifies polling behavior, which complements annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with purpose, cost, usage, response format, and examples. It is slightly long but front-loaded with key information. Could be trimmed but effective.
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 a single parameter, detailed output schema in description, and annotations covering safety, the description is complete for a polling tool. It addresses all necessary aspects for an agent to use 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 100% coverage with a good job_id description. The description adds extra context about the origin of job_id (returned by async extract or add_document_to_collection) and provides an example format, adding meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: polling async job status. It specifies job types (extract, indexing, batch) and provides detailed response fields, distinguishing it from sibling tools like add_document_to_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 states when to use (after add_document_to_collection or async extract), how to use (poll in a loop until complete/failed), and includes example prompts. The description covers usage context and expected behavior thoroughly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_quotaGet QuotaARead-onlyIdempotentInspect
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 | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| plan_id | Yes | |
| credits_used | Yes | |
| credits_limit | Yes | |
| billing_period | Yes | |
| credits_remaining | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint), the description adds key behavioral context: it's free with no credits consumed, and details the return structure including the status field. Adds value without contradicting 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?
Concisely states purpose, usage note, and return format. Includes example output and prompts which add utility but slight redundancy. Efficient overall.
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 read-only tool with no parameters, the description is very complete: explains what it does, when to use it, what it returns, and even provides example prompts. Output schema exists but description covers it well.
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?
Input schema has 0 parameters, so no parameter documentation is needed. Baseline is 4; description does not need to add parameter info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: get current credit balance and plan details for the API key. It uses specific verbs and resources, and distinguishes from sibling tools that perform different operations like extraction or search.
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 guidance on when to use this tool: before running credit-consuming operations to avoid QUOTA_EXCEEDED errors. Also includes example prompts that illustrate typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_collectionsList CollectionsARead-onlyIdempotentInspect
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 |
Output Schema
| Name | Required | Description |
|---|---|---|
| collections | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and idempotentHint. The description adds that the operation is free (no credits consumed) and supports pagination. No contradictions; adds value beyond 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?
Every sentence adds value: purpose, free usage, context, pagination, return format, and example prompts. Front-loaded with the core action, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema is partially shown, parameter count is low, and annotations cover safety, the description is complete. Includes return structure, usage hints, and 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 coverage is 100% with both parameters described. The description mentions pagination with limit and offset but does not add new meaning beyond the schema. Meets baseline for high 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 clearly states 'List all document collections owned by your API key' with a specific verb and resource. It distinguishes from siblings by directing use before search_collection or 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: 'Use before search_collection or ask_collection when you need the collection ID.' Also mentions it's free. Lacks explicit when-not-to-use or alternatives beyond those two, but provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
notarize_bundleNotarize Bundle On-ChainAIdempotentInspect
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" |
Output Schema
| Name | Required | Description |
|---|---|---|
| receipt | Yes | |
| bundle_id | Yes | |
| attestation | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate idempotent and non-destructive behavior. The description adds critical context: costs gas (ETH), the on-chain record is permanent and cannot be deleted even if the bundle is later purged. This goes beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections, bullet points for the return object, and example prompts. Every sentence adds value, and there is no fluff.
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 complexity (1 parameter, good annotations, output schema provided in description), the description covers all necessary aspects: purpose, usage, behavior, return format, and examples. It is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the single parameter with 100% description coverage. The description adds value by providing an example and reiterating the prerequisite, but does not add new semantic meaning beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool notarizes an evidence bundle on-chain by writing its SHA-256 to the blockchain, and distinguishes it from the sibling tool verify_bundle which is for quick integrity checks without on-chain cost.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (need for immutable on-chain timestamp) and when not to use (for quick checks, use verify_bundle). Also provides prerequisite (bundle status must be 'complete') and recommends checking with get_bundle first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
parse_invoiceParse InvoiceARead-onlyIdempotentInspect
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) |
Output Schema
| Name | Required | Description |
|---|---|---|
| cited | Yes | |
| invoice | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the description's additional behavioral context (uses a quality AI model, returns confidence levels) adds value. It does not contradict annotations. However, it omits some potential traits like error handling or limitations beyond the schema's size limit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a main sentence, usage guidance, a code block for return format, and example prompts. It is not overly verbose, though the example prompts could be considered slightly redundant given the clear description. Overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (parsing invoices) and the presence of a detailed output schema in the description, the description is largely complete. It provides return structure, confidence levels, and an alternative tool. It lacks information on error cases or unparseable documents, but the input schema is thorough.
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 description does not add significant meaning beyond the schema. The schema already describes both parameters with examples. The example prompts implicitly show usage but do not further explain the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: parsing receipts/invoices into structured fields. It distinguishes from sibling extract_text by specifying that this tool is for financial documents, while extract_text is for general text. The returned structure is explicitly defined.
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 usage guidance is provided: 'Use when you need to extract line items, totals, and merchant info from financial documents. For general document text, use extract_text instead.' This clearly tells the agent when to use this tool and when not to, with a direct alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
qa_urlAsk a Question About a URLARead-onlyInspect
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 |
Output Schema
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| answer | No | |
| truncated | Yes | |
| confidence | No | |
| answer_cited | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. Description adds 'Lean mode — no bundle stored' and explains return fields like confidence and truncated. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise (4-5 sentences), front-loaded with purpose, then guidelines, return format, and examples. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, description explains return fields (url, answer, answer_cited, confidence, truncated). Complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. Description provides example prompts but does not add significant meaning beyond the schema's parameter descriptions. Adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Fetch a public HTTPS URL and answer a specific question about its content.' It distinguishes from siblings summarize_url (broad summary) and ask_collection (multi-document 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?
Explicitly says '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.' Provides clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_collectionSearch CollectionARead-onlyIdempotentInspect
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" |
Output Schema
| Name | Required | Description |
|---|---|---|
| results | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint and idempotentHint. Description adds valuable behavioral context beyond annotations: 'Free — no credits consumed' and prerequisite about async indexing. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise and well-structured: main purpose, details, prerequisite, return format, and example prompts. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters and existence of output schema, description covers purpose, usage context, prerequisite, return format, and examples. Complete for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all 3 parameters with 100% description coverage. Description adds extra value by specifying default limit 10, max 50, and provides example values for query and collection_id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs semantic vector search across documents in a collection, returns ranked text chunks with scores. It explicitly distinguishes from sibling tool ask_collection by specifying when to use each.
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 guidance ('Use when you need raw matching chunks...'), identifies alternative (ask_collection), mentions prerequisite (collection populated and indexing complete), and gives example prompts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
summarize_documentSummarize DocumentARead-onlyIdempotentInspect
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 |
Output Schema
| Name | Required | Description |
|---|---|---|
| summary | Yes | |
| strategy | Yes | |
| truncated | Yes | |
| key_points | Yes | |
| summary_cited | Yes | |
| key_points_cited | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds valuable behavioral context: truncation behavior (max_tokens truncates input, not output), and return fields including 'truncated' and 'strategy', which are not in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is informative but slightly lengthy. It includes example prompts and return structure, which are very helpful. Could be slightly more concise, but every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (long document summarization, structured output), the description covers workflow, return fields, behavior with truncation, and example prompts. It is fully complete for an agent's decision-making.
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 description adds meaning beyond the schema. For 'text', it explains how to obtain the text and provides an example. For 'max_tokens', it gives default value and explains effect. This is a best-practice example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Summarize document text into a prose summary and key points with citations.' It distinguishes from siblings like 'qa_url' and 'extract_structured', specifying different use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (after extract_text or extract_url), when not to (for single-sentence Q&A use qa_url, for specific fields use extract_structured), and provides a typical workflow 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_urlSummarize URLARead-onlyInspect
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 |
Output Schema
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| summary | No | |
| truncated | Yes | |
| key_points | No | |
| word_count | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and openWorldHint=true. Description adds 'Lean mode — no bundle stored.' to clarify no persistence, and mentions 'truncated' flag in output. Good but not fully needed beyond 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?
Three concise sentences covering purpose, usage guidelines, and example prompts. No wasted words, clearly structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, annotations present, and schema covers parameters, the description is complete: explains what, when, alternatives, output fields, and usage examples. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% so baseline is 3. Description provides example URL formats and output shape, but does not add meaning beyond what schema already says for parameters url and max_tokens.
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?
Clearly states it fetches a public HTTPS URL and returns a prose summary with key points. Distinguishes from siblings extract_url (raw text) and qa_url (specific questions) by naming 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 says 'Use when you need a condensed understanding of a web page.' and provides alternatives: 'For raw text, use extract_url. For asking a specific question about a page, use qa_url.' Also includes example prompts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
translate_urlTranslate URLARead-onlyInspect
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 |
Output Schema
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| truncated | Yes | |
| target_lang | Yes | |
| translated_text | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. Description adds 'Lean mode — no bundle stored' and clarifies truncation behavior via max_tokens parameter. Also lists return fields (url, translated_text, target_lang, truncated). No contradiction.
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?
Concise: 4 sentences plus return fields and examples. Front-loaded with core action. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given complexity (fetch, translate, truncate) and presence of output schema, description covers purpose, usage, alternative, return fields, and examples. Lacks error handling or authentication notes, but adequate for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description does not add much beyond schema except for max_tokens clarification (1 token ≈ 4 chars, truncates before translation) and example prompts. Modest added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb+resource: 'Fetch a public HTTPS URL and return its content translated into a target language.' Distinguishes from sibling 'extract_url' by explicitly saying 'For extracting raw untranslated text, use extract_url instead.' Also mentions 'lean mode — no bundle stored' which differentiates from other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'Use when you need to understand web content in a different language.' Provides an alternative sibling tool. Does not cover when not to use or other alternatives, but sufficient context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_action_receiptVerify Action ReceiptARead-onlyIdempotentInspect
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" |
Output Schema
| 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds significant behavioral detail beyond annotations: free, no credits, and explains the dual verification (signature and manifest match). Annotations already declare readOnlyHint and idempotentHint, which are consistent.
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?
Concise, front-loaded with purpose, includes example prompts. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Fully explains purpose, input, and output (including return fields). With output schema present, description is complete enough for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter. Description includes an example receipt ID but does not add further semantic meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'verify' and the resource 'action receipt', specifying which tools produce such receipts. It distinguishes from sibling tool 'verify_bundle' by focusing on receipts rather than bundles.
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 mentions use for third-party audit and provides example prompts. Includes context that it's free and consumes no credits. Lacks explicit when-not-to-use, but context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_bundleVerify Evidence BundleARead-onlyIdempotentInspect
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" |
Output Schema
| 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. Description adds behavioral context: 'Free — no credits consumed' and details the return structure, which aids understanding beyond 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?
Description is concise yet comprehensive: first sentence states purpose, then lists checks, usage guidance, return format, and example prompts. No wasted words; well 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 simple parameter set, clear output schema included in description, and annotations covering safety, the description fully addresses all necessary context. Example prompts further aid understanding.
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 (bundle_id). Schema description coverage is 100%, but description adds example and context ('returned by extract or notarize'), going beyond the schema. Baseline 3 + extra context justifies 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool verifies cryptographic integrity of an evidence bundle, specifying what it checks (manifest hash, EIP-191 signature, R2 artifact hashes). It distinguishes itself from 'get_bundle' by emphasizing full crypto verification vs. quick metadata lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage guidance: 'Use when you need to confirm a bundle has not been tampered with.' Directly contrasts with 'get_bundle' for quick lookups, giving clear when-to-use and when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!