api
Server Details
AI document intelligence: extract, summarize, claim-check, notarize, and signed action receipts.
- 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 21 of 21 tools scored.
Each tool targets a distinct operation (extraction, summarization, Q&A, collection management, verification, etc.) with clear boundaries. No two tools serve the same purpose; even similar ones like ask_collection vs qa_url are differentiated by scope (collection vs single URL).
All tool names follow a consistent verb_noun or verb_noun_preposition pattern (e.g., extract_text, list_collections, verify_bundle). No mixing of camelCase or snake_case, and verbs are descriptive and aligned with the action.
21 tools is well-scoped for a document AI server. It covers the core workflows (extract, summarize, Q&A, search, verify) without being bloated. The count allows each tool to have a clear role without unnecessary overlap.
The tool surface covers the major document processing lifecycle: extraction, summarization, translation, Q&A, collections, and verification. Minor gap: no tool to delete or update collections/bundles, but the domain is focused on reading and analysis, not full CRUD management.
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?
The description discloses async indexing behavior, polling via get_job_status, prerequisites, and return values. Annotations indicate idempotent and non-destructive, which aligns with the description. 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?
The description is concise with clear sections (prerequisite, returns, example prompts). It is well-structured and front-loaded with the main 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 the async nature and prerequisites, the description covers all necessary information: what it does, when to use, prerequisites, post-indexing behavior, and return format. Output schema exists but not needed for completeness.
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 the description adds value by clarifying optionality of title, bundle status requirement, and collection ownership. Examples further aid interpretation.
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 adds an evidence bundle to a collection and triggers async indexing. It distinguishes from sibling tools by specifying the action and prerequisites.
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 says to use after create_collection and mentions that documents become searchable via search_collection and ask_collection after indexing. It includes prerequisites but doesn't explicitly state 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.
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 description aligns by stating it retrieves chunks and synthesizes a cited answer (no destructive actions). Adds behavioral detail beyond annotations: describes the retrieval-synthesis process and source attribution. 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?
Description is well-structured with a clear opening, usage guidance, prerequisite, return format, and examples. It is slightly longer than minimal but every sentence adds value. Could be marginally shorter, but overall 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?
Given the tool complexity (3 parameters, annotations, output schema exists), the description covers purpose, usage, prerequisite, and even includes a return structure block. It is complete for an AI agent to select and invoke 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% with good per-parameter descriptions. The tool description does not add further meaning beyond what the schema provides for parameters. Hence baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb+resource: 'Answer a question using RAG over a document collection.' It clearly distinguishes from siblings by naming search_collection (raw chunks) and qa_url (single-document Q&A). It also includes example prompts that reinforce purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'when you need a direct answer grounded in your collection documents.' Provides alternatives: search_collection for raw chunks, qa_url for single-document. Also mentions prerequisite about collection being populated and indexed, and includes example prompts.
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 indicate readOnlyHint=true and idempotentHint=true. The description adds significant behavioral context: it uses a quality AI model, returns citation-level evidence with quotes and paragraphs, and mentions truncation of input text. The output format is also described, providing transparency beyond 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?
The description is efficient, front-loading the purpose, then usage guidelines, then structured output format, then example prompts. Every sentence adds value without redundancy. It's well-organized and easy to parse.
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 params, output schema present, annotations), the description covers purpose, usage, behavioral traits, output format, and examples. It is fully sufficient for an AI agent to understand and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with detailed parameter descriptions and examples. The description adds some value by explaining the workflow and providing example prompts, but the schema already does the heavy lifting. Baseline 3 is appropriate as per rubric 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 the tool's purpose: 'Verify a list of factual claims against document text.' It specifies the verb 'verify', the resource 'claims against document text', and distinguishes from siblings like qa_url and ask_collection by mentioning alternatives. It also highlights use of a quality AI model with citation-level evidence, making the purpose precise and differentiated.
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 provides when to use this tool ('Use after extract_text or extract_url when you need to validate specific factual assertions'), when not to ('For open-ended questions... use qa_url', 'For multi-document investigation, use ask_collection'), and a typical workflow ('extract_text/extract_url → check_claims'). This is comprehensive guidance.
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?
Annotations indicate readOnlyHint=false (write operation), idempotentHint=false, destructiveHint=false. The description adds that the tool is free and consumes no credits, that collections start empty, and that indexing is asynchronous. This disclosure goes 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?
The description is concise, well-structured, and front-loaded with essential information. It includes example prompts and a clear return type without unnecessary verbosity.
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 (one parameter, no nested objects), the description covers all necessary aspects: purpose, usage, return format, and limitations. The output schema is implied in the description, making the definition self-contained.
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 parameter description. The tool description provides example names and alternative phrasings but does not add significant new semantic meaning beyond the schema. The baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a named collection for cross-document search and RAG-based Q&A. It explicitly distinguishes its purpose from sibling tools like search_collection and ask_collection by stating when to use this tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (grouping evidence bundles for search/QA) and provides example prompts. It also notes that collections start empty and that indexing is async, guiding users on subsequent steps. It lacks explicit exclusion criteria but is otherwise 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?
Annotations already show readOnlyHint and idempotentHint; description adds 'Uses a quality AI model with retry logic' and details return format, adding context 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?
Well-structured: purpose, behavior, usage guidance, schema format, return format, and examples. Every sentence provides 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?
Covers all aspects: purpose, usage, behavior, parameters, return values, and examples. Complete for a tool with output schema and nested objects.
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 descriptions; description adds example schema format and prompts, making parameter usage clearer.
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 'Extract typed fields from document text using a caller-defined schema' — specific verb, resource, and differentiates from siblings like extract_text and parse_invoice.
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 ('when you need specific data points') and provides alternatives: parse_invoice for invoices, summarize_document for summarization.
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 declare readOnlyHint=true and idempotentHint=true. Description adds the output structure (pages, text) and specifies Markdown format. No contradictions. Slightly more detail on constraints (e.g., file size) would elevate further.
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 yet informative: front-loaded with core action, followed by usage guidance, output structure, and example prompts. Every sentence contributes 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?
Given only 2 required parameters with complete schema descriptions and an inline output schema, the description thoroughly covers purpose, usage, and expected returns. No gaps for this complexity level.
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 detailed parameter descriptions and examples. The description does not add additional meaning beyond the schema for the parameters, which meets the baseline of 3.
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 explicitly states the verb 'extract', the resource 'tables and forms as Markdown from a PDF or image', and distinguishes from sibling tools like extract_text. Example prompts reinforce the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clear when-to-use (structured tabular data) and when-not-to-use (plain prose, recommending extract_text instead). Example prompts provide concrete context for invocation.
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?
The description adds value beyond the annotations by stating the return format ({ pages: number, text: string }) and providing example prompts. The annotations already declare readOnlyHint=true and idempotentHint=true, so the tool's safety is clear. The description does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (three main sentences) with essential information front-loaded. It efficiently covers action, usage guidance, alternative, return format, and includes helpful example prompts. No extraneous content.
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 (2 parameters, clear return format) and the presence of an output schema, the description is complete. It covers what the tool does, when to use it, the alternative, return structure, and example usage. An AI agent has all necessary information to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add significant parameter information beyond what the schema already provides (the schema includes detailed descriptions and examples for both parameters). The examples in the description reinforce usage but do not add new semantic details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: extract plain text from a PDF or image (base64-encoded). It specifies the resource type and action, and distinguishes from the sibling tool extract_url by noting the alternative for public URLs.
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 says when to use the tool: 'Use when you need raw text for downstream AI analysis' and provides a clear alternative: 'For documents at a public URL, use extract_url instead (no base64 encoding needed).' This gives both context and exclusion guidance.
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 already signal readOnlyHint and openWorldHint. Description adds behavioral context: 'Lean mode — no evidence bundle stored, no bundle_id returned' and mentions 'final_url (after redirects).' 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 well-structured with a clear purpose, usage alternatives, return format, and examples. Slightly long but efficient for the content.
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 high schema coverage, clear annotations, and an output schema, the description covers all necessary context (usage, behavior, return fields). Minimal 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 a detailed description and example for the url parameter. Description adds no additional 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?
Explicitly states 'Fetch a public HTTPS URL and return extracted text and page metadata.' Clearly distinguishes from siblings like summarize_url, qa_url, translate_url, and extract_text.
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: 'Lean mode — no evidence bundle stored, no bundle_id returned. Use summarize_url for summaries, qa_url for Q&A, translate_url for translation, extract_text for base64 file uploads.' Also gives example prompts.
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 declare readOnlyHint=true and idempotentHint=true, and the description adds useful behavioral context: 'Free — no credits consumed', ownership by API key, and status values. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, well-structured with clearly separated sections for when to use, return fields, and example prompts. Every sentence provides useful information 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?
The description fully covers the tool's purpose, usage, parameters, and return fields. With one parameter and an output schema, there are no gaps. 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?
Schema coverage is 100% and the description enriches the parameter meaning: it explains the bundle_id format (ev_...), its origin (returned by extract or notarize_bundle), and provides a full example. This adds significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves metadata for an evidence bundle (ev_...) owned by the API key. It specifies the action (retrieve metadata) and resource, and distinguishes from verify_bundle by noting it is for quick lookups, not deep cryptographic 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 provides explicit guidance: use for quick status/metadata lookups like checking completeness, notarization status, retention/legal hold info. It also explicitly states when not to use: for deep integrity verification, use verify_bundle. Example prompts reinforce usage.
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?
Beyond readOnlyHint and idempotentHint annotations, the description adds that the tool is free (no credits consumed), describes the polling loop behavior, and details the response fields including bundle_id and result_json on completion. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: first sentence states purpose, then cost, usage instructions, polling pattern, response structure, and example prompts. It is concise without unnecessary words, and key info 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 param, output schema described), the description covers all necessary context: what the tool does, when to use, how to use, what the response looks like, and example invocations. Annotations and schema complete the picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage for the single parameter job_id, so baseline is 3. The description adds value by explaining where the job_id comes from (async extract or add_document_to_collection) and providing an example, which reinforces schema meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool polls the status of async jobs (extract, indexing, batch) and explicitly mentions use after add_document_to_collection or async extract. It is a specific verb-resource pair, and it distinguishes from sibling tools like add_document_to_collection which create jobs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: after async operations, and instructs to poll in a loop until 'complete' or 'failed'. It also gives example prompts, covering both context and correct invocation pattern.
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?
Annotations already declare readOnlyHint and idempotentHint. The description adds that it is free (no credits consumed) and provides the exact return structure, which adds value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Efficiently structured: first sentence states purpose, then usage guidance, return format, and example prompts. No wasted text; front-loaded with key 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 read-only tool with no parameters, the description covers all essential aspects: purpose, when to use, return format, and example prompts. The inline output schema compensates for the lack of a formal one.
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?
No parameters; schema coverage is 100%. Baseline for zero parameters is 4, and no additional parameter documentation is needed.
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 retrieves current credit balance and plan details for the user's API key. It is distinct from sibling tools that perform credit-consuming operations like extract, summarize, etc.
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 advises checking this tool before running credit-consuming operations to avoid QUOTA_EXCEEDED errors. Example prompts further clarify when to use it.
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 declare readOnlyHint and idempotentHint true, but description adds value with 'Free — no credits consumed', and explicitly states the return format. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three brief sentences plus a structured return type and example prompts. Front-loaded with purpose, 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 the simplicity of the tool (list with pagination), the description covers all necessary aspects: purpose, usage context, parameters, return format, and example prompts. Output schema is present in description.
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 descriptions and examples for limit and offset. The description mentions pagination but does not add significant meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all document collections owned by the API key, using specific verb 'list' and resource 'document collections'. It distinguishes from siblings by mentioning usage before search_collection or ask_collection to get collection ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance: use before search_collection or ask_collection when needing collection ID. Also mentions it's free and supports pagination, providing clear context for when to invoke.
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?
Expands on annotations: confirms idempotent (returns existing if already notarized), warns about gas cost (ETH), and notes that the on-chain record is permanent and cannot be deleted. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with key action, then usage, prerequisite, and warnings. Well-structured but slightly lengthy; example prompts add value for invocation. No superfluous content.
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 one parameter, full annotations, and presence of output schema (return values described), the description covers all necessary aspects: purpose, usage, behavioral traits, prerequisites, cost, and examples. Highly 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 a well-described bundle_id parameter including example and status condition. Description reinforces the prerequisite but adds little new semantic detail 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 the action: notarize a bundle on-chain by writing its SHA-256 to the blockchain. Distinguishes from sibling verify_bundle by contrasting on-chain cost vs. quick integrity checks.
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 (immutable timestamp) and when not (use verify_bundle for quick checks). Includes prerequisite that bundle status must be 'complete', with instruction to check via get_bundle.
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. The description adds that it uses a quality AI model and provides detailed output structure with confidence levels and citations, giving the agent insight into output reliability and behavior 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?
The description is well-structured and front-loaded, with each sentence contributing value. Example prompts and return structure are included but not excessively verbose. Minor redundancy but overall concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has only 2 parameters, a full output schema (described in text), and annotations present, the description is complete. It covers purpose, usage, alternatives, and output format without needing additional details.
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 clear parameter descriptions. The description adds context by specifying document types (receipt/invoice), which adds meaning beyond the schema's MIME type and base64 encoding 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 tool parses invoices/receipts into structured fields including line items, totals, and merchant info. It distinguishes itself from extract_text by specifying that this tool is for financial documents, while extract_text is for general text.
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 says 'Use when you need to extract line items, totals, and merchant info from financial documents' and 'For general document text, use extract_text instead,' providing clear usage context and an 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?
Beyond annotations (readOnlyHint, openWorldHint), description adds 'lean mode — no bundle stored', explains max_tokens truncation effect on fetched content, and discloses return fields including truncated flag.
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 with purpose first, then usage guidance, return format, and examples. Slightly wordy but no 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?
With 3 parameters fully described, output structure documented, and behavioral notes, the description is complete for a Q&A tool. 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 3. Description adds value with example prompts for url and question, and explains max_tokens behavior (truncates page content, not answer).
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 specific verb+resource ('Fetch a public HTTPS URL and answer a specific question') and clearly distinguishes from siblings (summarize_url, 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 states when to use ('precise question') and provides alternatives for broad summary or multi-document Q&A, with sibling tool names.
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 already indicate readOnly and idempotent. Description adds value by noting 'Free — no credits consumed' and explaining prerequisite async behavior. Does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise and well-structured: purpose, return info, alternative, prerequisite, return format, 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?
Given the tool's 3 parameters, output schema exists, and annotations present, the description is complete. Covers prerequisites, return structure, and usage context with 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?
Schema coverage is high (100%) with clear parameter descriptions. The description adds example prompts and return format, which helps contextualize query usage but doesn't meaningfully extend parameter definitions.
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?
Identifies specific verb 'search' and resource 'collection', and clarifies it is a semantic vector search. Clearly distinguishes from ask_collection by contrasting raw chunks vs. synthesized answer.
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 raw matching chunks') and when not to ('use ask_collection for synthesized answer'). Also includes prerequisite about collection population and indexing, aiding correct usage.
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 indicate read-only and idempotent. Description adds details on output structure (summary, key_points, cited variants, truncated, strategy) and notes input 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?
Every sentence adds value. Starts with purpose, then usage guidance, workflow, return type, and examples. Well-organized and appropriately sized.
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 2 parameters, full schema coverage, output schema present, and annotations, the description covers all necessary context: typical workflow, differentiation from siblings, and 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%, so baseline is 3. Description adds example prompts and explains max_tokens truncation behavior, providing context beyond schema. Not exhaustive but sufficient.
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 it summarizes document text into prose summary and key points with citations. It differentiates from siblings like qa_url and extract_structured, and provides typical workflow, making purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: after extract_text or extract_url for condensed understanding. Contrasts with qa_url for Q&A and extract_structured for specific fields. Includes 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 declare readOnlyHint and openWorldHint. The description adds that the tool operates in 'Lean mode — no bundle stored' and returns specific fields, providing extra behavioral context 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?
The description is concise, front-loaded with the main action, followed by usage guidelines, return format, and example prompts. Every sentence is purposeful with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, 2 parameters, presence of output schema, and annotations, the description covers purpose, usage, alternatives, and return structure completely.
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 the baseline is 3. The description provides example values and usage hints, but does not add significant additional semantic meaning beyond the schema's parameter 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 tool fetches a public HTTPS URL and returns a prose summary with key points. It distinguishes itself from siblings by explicitly naming extract_url and qa_url for different use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use when you need a condensed understanding of a web page' and provides alternatives for raw text or specific questions, giving 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.
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=true and openWorldHint=true. The description adds context: 'Lean mode — no bundle stored' (no persistent storage) and mentions the return field '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 4 sentences plus example prompts, efficient and front-loaded with action, purpose, and alternative. 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?
All 3 parameters are covered, output schema exists, and description mentions return fields. No gaps. The tool's behavior is fully described given its clarity and annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description provides example prompts but adds little new semantic meaning beyond the schema's parameter descriptions. 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 it fetches a public HTTPS URL and translates content into a target language. It uses a specific verb+resource ('translate URL') and distinguishes from the sibling 'extract_url' for raw untranslated text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance: 'Use when you need to understand web content in a different language.' Also provides clear alternative: 'For extracting raw untranslated text, use extract_url instead.'
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?
Annotations already declare readOnlyHint and idempotentHint. Description adds that it's free (no credits), explains what exactly it verifies (signature authenticity and manifest match), and lists return fields. 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 well-structured: starts with purpose, then cost, then detailed explanation, use case, output schema, and examples. Every sentence adds value, though slightly longer than minimal.
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 tool with rich annotations, full schema coverage, and an output schema provided, the description covers all necessary aspects: purpose, usage, behavior, output, 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 (receipt_id) with 100% schema coverage and a thorough schema description. The tool description doesn't add new information about the parameter beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool verifies signed action receipts, lists the source tools (get_bundle, verify_bundle, etc.), and distinguishes it from sibling tools like verify_bundle by focusing on action receipts.
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 (for receipts from specific tools, third-party audit). Though no explicit when-not-to-use, the context and sibling names imply alternatives. Could mention verify_bundle as a related but distinct tool.
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?
Goes beyond annotations (readOnlyHint, idempotentHint) by detailing the specific checks performed (manifest hash, EIP-191 signature, R2 artifact hashes), confirming it's free, and providing the full return structure. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured: purpose, details, usage guidance, return schema, example prompts. Every sentence adds value; no redundancy or fluff. Appropriate length for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter and presence of output schema (inlined in description), the description fully covers the tool's behavior, prerequisites (API key ownership), side effects (none, free), and return format. No gaps for an agent to invoke 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?
Input schema has 100% coverage for the single parameter, providing basic description. The tool description adds context that the bundle must be owned by the API key, which is additional beyond the schema. However, the schema itself already provides the parameter purpose well, so description adds marginal but useful extra context.
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 evidence bundles, specifying the verb 'verify' and the resource 'evidence bundle (ev_...)'. It explicitly differentiates from sibling tool get_bundle, which handles quick metadata lookups.
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 ('confirm a bundle has not been tampered with') and when not ('for quick metadata lookups'), and directly names the alternative tool (get_bundle). Provides example prompts for clarity.
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!