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.
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.
Average 4.6/5 across 22 of 22 tools scored.
Each tool has a clearly distinct purpose, grouped by domain (account, bundle, collection, document, job, receipt, url). Descriptions and naming make it easy to differentiate between similar tools like url.extract vs document.extract_text or collection.search vs collection.ask.
All tools follow the same prefix.group_action pattern in snake_case (e.g., account.quota, bundle.get, collection.create). No mixing of conventions, making the API predictable and easy to navigate.
With 22 tools, the server covers a comprehensive set of operations for document and evidence management. Each tool serves a specific purpose, and the count feels well-scoped without being bloated or sparse.
The tool surface lacks explicit create and delete operations for bundles and collections. Bundles appear to be created externally, and there is no tool to remove a bundle or collection. This is a notable gap given the server's stated purpose.
account.quotaGet QuotaAGet current credit balance and plan details for your API key. Free — no credits consumed. Check this before running credit-consuming operations (extract, summarize, etc.) to avoid QUOTA_EXCEEDED errors. Returns plan tier, billing period, and usage breakdown. Returns: { plan_id, billing_period (YYYY-MM), credits_used, credits_limit, credits_remaining, status: "active"|"suspended" } Example prompts:
"How many credits do I have left this month?"
"Check my current quota and plan status."
"Am I going to hit my credit limit soon?"
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| plan_id | Yes | |
| credits_used | Yes | |
| credits_limit | Yes | |
| billing_period | Yes | |
| credits_remaining | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent. Description adds important context: free (no credits consumed) and details of the response including status field, enhancing transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is informative with a logical flow: purpose, cost, usage guidance, return format, example prompts. It is slightly verbose but earns its length by covering key aspects.
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 zero-parameter tool with an output schema described in the description, the explanation is complete. It covers purpose, usage, return structure, 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?
No parameters exist (schema coverage 100%), so baseline is 4. Description adds value by detailing the return object structure, which goes beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The title 'Get Quota' and description 'Get current credit balance and plan details for your API key' clearly state the verb and resource. It is distinct from sibling tools which are document/collection operations, so no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explicitly advises to check this before credit-consuming operations to avoid errors, and notes it's free. This gives clear when-to-use guidance with no alternatives needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bundle.getGet Evidence BundleARetrieve metadata for an evidence bundle (ev_...) owned by your API key. Free — no credits consumed. Use for quick status/metadata lookups such as checking if a bundle is complete, finding its notarization status, or viewing retention/legal hold info. For deep cryptographic integrity verification (hash + signature + artifact checks), use bundle.verify instead. Also returns a signed action receipt (rcpt_...) binding this lookup to the bundle manifest — list with receipt.list, verify with receipt.verify. Returns: { bundle_id, source_url, mode, status: "pending"|"complete"|"failed", manifest_sha256, manifest_signature, signer_address, attestation_tx, attestation_at, eas_uid, parent_bundle_id, superseded_by, legal_hold: boolean, retention_until, created_at, receipt: ActionReceipt|null } Example prompts:
"Show me the metadata for bundle ev_550e8400."
"Check the status and notarization info of my evidence bundle."
"Get me the details of bundle [ev_id] — is it complete?"
| Name | Required | Description | Default |
|---|---|---|---|
| bundle_id | Yes | Evidence bundle ID (ev_...) returned by extract or bundle.notarize. Example: "ev_550e8400-e29b-41d4-a716-446655440000" |
| Name | Required | Description |
|---|---|---|
| mode | Yes | |
| status | Yes | |
| eas_uid | Yes | |
| receipt | Yes | |
| bundle_id | Yes | |
| created_at | Yes | |
| legal_hold | Yes | |
| source_url | Yes | |
| superseded_by | Yes | |
| attestation_at | Yes | |
| attestation_tx | Yes | |
| signer_address | Yes | |
| manifest_sha256 | Yes | |
| retention_until | Yes | |
| parent_bundle_id | Yes | |
| manifest_signature | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and idempotentHint. The description adds that the operation is free ('no credits consumed') and returns a signed action receipt, which are useful behavioral details beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear intro, usage guidance, return fields, and example prompts. It is slightly verbose with examples but remains 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 simplicity (one parameter) and the presence of an output schema in the description, the description is fully complete. It covers purpose, usage, return format, and alternatives.
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 bundle_id. The description adds context by stating the bundle is 'owned by your API key' and provides example prompts, which clarify the parameter's 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?
The description clearly states 'Retrieve metadata for an evidence bundle (ev_...) owned by your API key.' It specifies the exact resource and action, and distinguishes from sibling bundle.verify.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use for quick status/metadata lookups' and directs to bundle.verify for deep integrity verification. Also mentions using receipt.list and receipt.verify for the returned receipt.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bundle.notarizeNotarize Bundle On-ChainANotarize an evidence bundle on-chain by writing its manifest SHA-256 to the blockchain (Base/EVM). Creates a permanent, tamper-evident on-chain record of the document fingerprint. If the bundle is already notarized, returns the existing attestation immediately (idempotent). Use when you need an immutable on-chain timestamp proving a document existed at a point in time. For quick integrity checks without on-chain cost, use bundle.verify instead. Also returns a signed action receipt (rcpt_...) binding this notarize call to the bundle manifest — list with receipt.list, verify with receipt.verify. PREREQUISITE: Bundle status must be "complete". Check status with bundle.get first. NOTE: Costs gas (ETH). The on-chain record is permanent and cannot be deleted even if the bundle is later purged. Returns: { bundle_id, attestation: { tx_hash, network, attested_at, key_id, eas_uid?, schema_uid? }, receipt: ActionReceipt|null } Example prompts:
"Notarize bundle ev_550e8400 on-chain so I have a permanent record."
"Put the fingerprint of my evidence bundle on the blockchain."
"Create an on-chain timestamp for this document bundle."
| Name | Required | Description | Default |
|---|---|---|---|
| bundle_id | Yes | Evidence bundle ID (ev_...) to notarize. Bundle must have status "complete". Example: "ev_550e8400-e29b-41d4-a716-446655440000" |
| Name | Required | Description |
|---|---|---|
| receipt | Yes | |
| bundle_id | Yes | |
| attestation | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide idempotentHint=true and destructiveHint=false. The description adds valuable context: idempotency details, gas costs, and that the on-chain record is permanent and cannot be deleted. 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?
Well-structured with paragraphs, prerequisites, output shape, and example prompts. Some redundancy (e.g., 'bundle_id' description repeated), but overall efficient and 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?
Covers purpose, usage, prerequisites, behavioral details (idempotent, permanent, irreversible), output schema, and alternatives. Output schema is described in the description. Very complete for a single-parameter 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?
Only one parameter (bundle_id) with 100% schema coverage. The description repeats the prerequisite and adds an example, but adds minimal extra meaning beyond the schema's description.
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 action: 'Notarize an evidence bundle on-chain by writing its manifest SHA-256 to the blockchain'. It distinguishes from sibling tool 'bundle.verify' and mentions idempotence, providing a specific verb and resource.
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 an immutable on-chain timestamp) and when not (use bundle.verify for quick integrity checks). Also includes prerequisite: 'Bundle status must be complete' and a cross-reference to 'bundle.get'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bundle.verifyVerify Evidence BundleAVerify the cryptographic integrity of an evidence bundle (ev_...) owned by your API key. Checks manifest hash, EIP-191 signature, and R2 artifact hashes. Free — no credits consumed. Use when you need to confirm a bundle has not been tampered with. For quick metadata lookups (without full crypto verification), use bundle.get instead. Also returns a signed action receipt (rcpt_...) binding this verify call to the bundle manifest — list with receipt.list, verify with receipt.verify. Returns: { valid: boolean, bundle_id, manifest_sha256, checks: { status, manifest_hash, signature, artifacts: [{ name, ok }] }, tampered: string[], signer_address: string|null, attestation_tx: string|null, url: string, captured_at: string, receipt: ActionReceipt|null } Example prompts:
"Verify the cryptographic integrity of bundle ev_550e8400."
"Is this evidence bundle still valid and untampered?"
"Deep-check the manifest hash and signature of my bundle."
| Name | Required | Description | Default |
|---|---|---|---|
| bundle_id | Yes | Evidence bundle ID (ev_...) returned by extract or notarize. Example: "ev_550e8400-e29b-41d4-a716-446655440000" |
| Name | Required | Description |
|---|---|---|
| url | No | |
| valid | Yes | |
| checks | Yes | |
| receipt | Yes | |
| tampered | Yes | |
| bundle_id | Yes | |
| captured_at | No | |
| attestation_tx | No | |
| signer_address | No | |
| manifest_sha256 | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint), the description adds that the tool is free, no credits consumed, and that it returns a signed action receipt (rcpt_...). It also details the full return structure including which checks are performed. 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 front-loaded with the main action and provides essential context. It includes a full output schema and example prompts, which adds length but is structured. Could be slightly more concise, 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 single parameter, clear annotations, and presence of output schema, the description is fully complete. It covers purpose, usage, behavioral details, example prompts, and return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the bundle_id parameter well (100% coverage). The description adds context such as 'owned by your API key' and emphasizes the ev_ prefix. This adds marginal value beyond the schema, so a 4 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 verifies cryptographic integrity of an evidence bundle, explicitly distinguishing from bundle.get for quick metadata lookups. It specifies the verb (verify), resource (evidence bundle), and scope (cryptographic integrity including manifest hash, signature, artifact hashes).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('when you need to confirm a bundle has not been tampered with') and provides an alternative ('For quick metadata lookups (without full crypto verification), use bundle.get instead'). It also mentions related receipt operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
collection.add_documentAdd Document to CollectionAAdd an evidence bundle to a collection and trigger async vector indexing. Use after collection.create to populate a collection with documents. Once indexed, documents become searchable via collection.search and collection.ask. Indexing is async — poll job.status with the returned job_id until status is "complete". Also returns a signed action receipt (rcpt_...) binding this add call to the bundle manifest — list with receipt.list, verify with receipt.verify. PREREQUISITE: Bundle must have status "complete" (check with bundle.get). Collection must be owned by your API key. Returns: { collection_id, bundle_id, job_id (poll for indexing completion), receipt: ActionReceipt|null } Example prompts:
"Add my contract bundle ev_550e8400 to the Q4 Contracts collection."
"Put this evidence bundle into my Due Diligence Docs collection for search."
"Add document [bundle_id] to collection [col_id] with a title."
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | Optional display title for the document in this collection. Example: "Q4 2025 Financial Report" | |
| bundle_id | Yes | Evidence bundle ID (ev_...) to add. Bundle must have status "complete". Example: "ev_550e8400-e29b-41d4-a716-446655440000" | |
| collection_id | Yes | Collection ID (col_...) returned by collection.create. Example: "col_550e8400-e29b-41d4-a716-446655440000" |
| Name | Required | Description |
|---|---|---|
| job_id | Yes | |
| receipt | Yes | |
| bundle_id | Yes | |
| collection_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds beyond annotations by detailing async vector indexing, polling with job_id, and return of a signed receipt. Annotations already indicate idempotent and non-destructive, so description adds significant context 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 clear sections (PREREQUISITE, Returns, Example prompts). Every sentence contributes useful information, though could be slightly trimmed for brevity.
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, output schema present, and complexity of async workflow, the description covers prerequisites, async behavior, polling, receipts, and relationships to sibling tools. It is sufficiently 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%, so baseline is 3. Description adds value by explaining the purpose of each parameter (e.g., 'Optional display title', 'bundle_id' with example, 'collection_id' referencing collection.create).
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 and resource: 'Add an evidence bundle to a collection and trigger async vector indexing.' It distinguishes from sibling tools like collection.create and collection.search by specifying the action of populating a collection and triggering indexing.
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 after collection.create to populate a collection with documents.' Prerequisites (bundle must have status 'complete', collection owned by API key) are stated. It explains post-usage (searchable via collection.search/ask) and polling via job.status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
collection.askAsk CollectionAAnswer a question using RAG over a document collection. Retrieves relevant chunks then synthesizes a cited answer with source attribution. Use when you need a direct answer grounded in your collection documents. For raw matching chunks (without synthesis), use collection.search instead. For single-document Q&A, use url.qa instead. PREREQUISITE: Collection must be populated via collection.add_document and indexed before results appear. Returns: { answer: string, sources: [{ bundle_id, chunk_id }], retrieval: [{ bundle_id, chunk_id, text, score }] } Example prompts:
"What are the key terms of the service agreement in my collection?"
"Based on my due diligence docs, what are the main risks?"
"Answer this question using all documents in the Q4 Contracts collection."
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | Natural language question to answer from collection documents. Example: "What are the key terms of the service agreement?" | |
| max_chunks | No | Max chunks to retrieve for context (default 8). Increase for broad questions, decrease for precision. Example: 12 | |
| collection_id | Yes | Collection ID (col_...) returned by collection.create. Example: "col_550e8400-e29b-41d4-a716-446655440000" |
| Name | Required | Description |
|---|---|---|
| answer | Yes | |
| sources | Yes | |
| retrieval | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint; description adds details about RAG process, chunk retrieval, synthesis, and source attribution. No contradictions; adds valuable 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?
Highly concise yet comprehensive: one paragraph covering purpose, usage, prerequisites, return format, and examples. 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?
Covers all necessary aspects: behavior, prerequisites, return structure, and relationships to siblings. Complete for an agent to confidently 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% with examples; description adds practical guidance like 'Increase for broad questions, decrease for precision' for max_chunks, enhancing semantic understanding beyond 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 answers questions using RAG over a document collection, and distinguishes itself from sibling tools (`collection.search` for raw chunks, `url.qa` for single-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 describes when to use (need direct answer grounded in collection) and alternatives; also provides prerequisites (collection must be populated and indexed) and example prompts to guide usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
collection.createCreate CollectionAInspectCreate a named document collection for cross-document semantic search and RAG-based Q&A. Free — no credits consumed. Use when you want to group related evidence bundles for unified search (collection.search) or question answering (collection.ask). NOTE: Collections start empty. Add evidence bundles with collection.add_document. Indexing is async — once complete, use collection.search or collection.ask. Returns: { collection_id: string (col_...), name: string } Example prompts:
"Create a collection called Q4 Contracts for my quarterly reports."
"Set up a new document group named Due Diligence Docs."
"Make a collection to organize my vendor agreements."
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Human-readable collection name. Example: "Q4 Contracts" or "Due Diligence Docs" |
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| collection_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses behavioral traits beyond annotations: 'Free — no credits consumed', 'Collections start empty', 'Indexing is async', and the 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?
The description is concise and front-loaded with purpose, followed by usage guidance, notes, return format, and examples. 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?
Covers all necessary context: purpose, usage, async behavior, return format, and related tools. Output schema is implied through the return description, making it complete for this 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?
Only one parameter 'name' with schema description and examples. Since schema coverage is 100%, the description adds no new meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a named document collection' for semantic search and RAG Q&A, distinguishing it from siblings like collection.add_document and collection.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?
Explicitly says 'Use when you want to group related evidence bundles' and provides example prompts, guiding the agent on when to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
collection.listList CollectionsAList all document collections owned by your API key. Free — no credits consumed. Use before collection.search or collection.ask when you need the collection ID. Supports pagination with limit and offset. Returns: { collections: [{ id, name, created_at }] } Example prompts:
"List all my document collections."
"Show me the collections I have created."
"What collections do I own? List them."
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max collections to return (default 50, max 100). Example: 20 | |
| offset | No | Pagination offset (default 0). Example: 0 |
| Name | Required | Description |
|---|---|---|
| collections | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only and idempotent behavior. The description adds value by stating it is free, supports pagination, and returns a specific 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?
The description is five sentences long, front-loading the main purpose and including example prompts. It is clear and efficient, though slightly longer than necessary for a simple list tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides all necessary information: purpose, usage context, behavior, parameters with pagination, example return value, and example prompts. It is fully complete for a tool with low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with detailed descriptions for limit and offset including examples. The description mentions pagination but does not add new meaning beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List', the resource 'document collections', and the scope 'owned by your API key'. It also distinguishes this tool from siblings like collection.search and collection.ask by specifying its use case for getting collection IDs.
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 advises using this tool before collection.search or collection.ask when needing the collection ID. It also notes that it is free with no credits consumed, providing clear context for 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.
collection.searchSearch CollectionASemantic (vector) search across documents in a collection. Returns ranked text chunks with relevance scores. Free — no credits consumed. Use when you need raw matching chunks from a collection. For a synthesized cited answer from the same context, use collection.ask instead. PREREQUISITE: Collection must be populated via collection.add_document and async indexing must complete (poll job.status) before results appear. Returns: { results: [{ bundle_id, chunk_id, text, score: number (0–1), title? }] } Example prompts:
"Search my Q4 Contracts collection for mentions of liability cap."
"Find the clause about data retention in my due diligence docs."
"Search for revenue numbers across my quarterly reports."
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max chunks to return (default 10, max 50). Example: 5 | |
| query | Yes | Natural language search query. Example: "What were the revenue numbers for Q4?" | |
| collection_id | Yes | Collection ID (col_...) returned by collection.create. Example: "col_550e8400-e29b-41d4-a716-446655440000" |
| Name | Required | Description |
|---|---|---|
| results | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. Description adds 'Free — no credits consumed' and detailed return format, providing useful 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?
Highly efficient: single paragraph covering purpose, alternative, cost, prerequisites, return format, and examples. No wasted 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?
Output schema is implied by detailed return structure. Covers all needed aspects: parameters, prerequisites, examples, and distinguishes from sibling. Complete for tool 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%, baseline 3. Description adds example prompts and explains limit (max 50), query as natural language, and collection_id format, adding value 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?
The description clearly states the tool performs semantic (vector) search across documents in a collection and returns ranked text chunks, distinguishing it from the sibling tool collection.ask.
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 (raw matching chunks) and when not (use collection.ask for synthesized answer). Also mentions prerequisite of populating collection and waiting for indexing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
document.check_claimsCheck ClaimsAVerify a list of factual claims against document text. Uses a quality AI model with citation-level evidence. Use after document.extract_text or url.extract when you need to validate specific factual assertions. For open-ended questions about a document, use url.qa instead. For multi-document investigation, use collection.ask. Typical workflow: document.extract_text/url.extract → document.check_claims. Returns: { claims: [{ claim, status: "supported"|"contradicted"|"not_found", evidence: { quote, paragraphs[] }, confidence: "high"|"medium"|"low" }], truncated: boolean } Example prompts:
"Check whether this contract mentions a liability cap of $1M."
"Verify these claims against the document: [claims list]."
"Does the report actually say revenue grew 23%?"
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Document text to check claims against. Obtain via document.extract_text or url.extract. Example: "ACME Corp was founded in 2010. Revenue exceeded $1M in 2024." | |
| claims | Yes | Factual statements to verify. Each claim is checked independently against the text. Example: ["Founded in 2010", "Revenue exceeded $1M"] | |
| max_tokens | No | Input length cap (1 token ≈ 4 chars). Default ~3000 tokens. Truncates input text, not the output. Example: 4000 |
| Name | Required | Description |
|---|---|---|
| claims | Yes | |
| truncated | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. Description adds that it uses a 'quality AI model with citation-level evidence' and mentions truncated flag in output. 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?
Concise and well-structured: purpose, when to use, alternatives, workflow, return format. 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?
Covers all aspects: purpose, usage, workflow, return schema, examples. With only 3 params and output schema provided, 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 clear descriptions. Description adds example prompts and typical usage but does not deepen parameter meaning beyond schema. 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?
Clearly states 'verify a list of factual claims against document text' with specific verb and resource. Distinguishes from sibling tools url.qa (open-ended questions) and collection.ask (multi-document investigation).
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 recommends use after document.extract_text or url.extract, and gives alternatives: url.qa for open-ended questions, collection.ask for multi-document. Typical workflow provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
document.extract_structuredExtract Structured DataAExtract typed fields from document text using a caller-defined schema. Uses a quality AI model with retry logic. Use when you need specific data points from a document rather than full text. For invoices with known fields, document.parse_invoice (prebuilt schema) may be simpler. For general summarization, use document.summarize instead. Schema format: { "field_name": "type hint or description" } — e.g. { "contract_date": "ISO date", "party_a": "string", "penalty_usd": "number" }. Returns: { data: { : value }, data_cited: { : { value, confidence: "high"|"medium"|"low", citations: [{ quote, paragraphs[] }] } } } Example prompts:
"Extract the contract date, parties, and penalty amount from this agreement."
"Pull the vendor name, PO number, and total from this document."
"Get me all named fields from this form using my custom schema."
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Document text to extract from. Obtain via document.extract_text or url.extract. Example: "This Service Agreement is entered into on 2025-03-15 between ACME Corp and Beta Inc..." | |
| schema | Yes | Field map: describe each field you want extracted with a type hint. Example: { "total_usd": "number", "vendor": "string", "invoice_date": "ISO date YYYY-MM-DD" } | |
| max_tokens | No | Input length cap (1 token ≈ 4 chars). Default ~2500 tokens. Truncates input, not output. Example: 3000 |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| data_cited | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. Description adds 'Uses a quality AI model with retry logic' and clarifies truncation behavior ('Truncates input, not output'), which 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?
Front-loaded with purpose, then usage, format, return, examples. Every sentence earns its place; 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 3 params, output schema inline, and clear usage guidance, the description is complete for an 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%, baseline 3. Description adds schema format examples, return structure, and example prompts, which significantly enriches understanding beyond the 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?
First sentence clearly states verb (extract), resource (typed fields from document text), and mechanism (caller-defined schema). Differentiates from siblings like document.parse_invoice and document.summarize.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('need specific data points'), provides simpler alternatives for invoices and summarization, 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.
document.extract_tablesExtract TablesAExtract tables and forms as Markdown from a PDF or image (base64-encoded). Use when the document contains structured tabular data such as financial statements, data sheets, or forms. For plain prose documents, use document.extract_text instead. Returns: { pages: number, text: string } — text contains Markdown-formatted tables. Example prompts:
"Extract the tables from this financial statement."
"Pull the data table from this PDF into Markdown format."
"Get the tabular data from this form document."
| Name | Required | Description | Default |
|---|---|---|---|
| mime_type | Yes | MIME type of the document. Example: "application/pdf" for PDF bank statements, "image/jpeg" for photo of a form. | |
| document_base64 | Yes | Base64-encoded PDF or image bytes (max ~15 MB). Example: "JVBERi0xLjcNJeLjz9MNCj..." (truncated PDF base64) |
| Name | Required | Description |
|---|---|---|
| text | Yes | |
| pages | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds the return format (Markdown) and structure ({ pages: number, text: string }). It does not cover edge cases like missing tables, but given annotation coverage, this is acceptable.
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 (3 sentences plus return type and example prompts), front-loaded with purpose, and every sentence adds value. No extraneous 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?
Given the tool's simplicity (2 params, 100% schema coverage, output schema present, annotations provided), the description covers all necessary aspects: purpose, usage guidelines, return format, and examples. It is complete for effective 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 has 100% coverage with clear descriptions and examples for both parameters (mime_type, document_base64). The description does not add further detail beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Extract tables and forms as Markdown from a PDF or image (base64-encoded).' It further distinguishes itself from the sibling tool document.extract_text by specifying the appropriate use case for structured tabular data.
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 the document contains structured tabular data such as financial statements, data sheets, or forms.' Also provides an alternative: 'For plain prose documents, use document.extract_text instead.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
document.extract_textExtract TextAExtract plain text from a PDF or image (base64-encoded). Use when you need raw text for downstream AI analysis (summarization, claim checking, structured extraction). For documents at a public URL, use url.extract instead (no base64 encoding needed). Returns: { pages: number, text: string } Example prompts:
"Extract the text from this scanned contract so I can search it."
"Give me the raw text from this PDF document."
"OCR this image and return the text content."
| Name | Required | Description | Default |
|---|---|---|---|
| mime_type | Yes | MIME type of the document. Example: "application/pdf" for PDFs, "image/png" for PNG screenshots. | |
| document_base64 | Yes | Base64-encoded PDF or image bytes (max ~15 MB). Example: "JVBERi0xLjcNJeLjz9MNCj..." (truncated PDF base64) |
| Name | Required | Description |
|---|---|---|
| text | Yes | |
| pages | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds value by specifying input constraints (base64-encoded, max ~15 MB), hinting at OCR for images, and stating 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?
The description is front-loaded with the core functionality, then usage guidance, then examples. It is concise with minimal redundancy, though the examples could be merged. Still efficient and to the point.
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 exists (returns pages and text), the description doesn't need to explain return values. It covers input format, usage context, alternatives, constraints (size, OCR), and example prompts. 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% with both parameters described. The description provides example base64 strings and MIME types, but these largely duplicate schema examples. It adds usage context but not significantly more semantic clarity. 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 extracts plain text from PDF or image (base64-encoded), using a specific verb and resource. It distinguishes from sibling url.extract by noting the base64 requirement, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use when you need raw text for downstream AI analysis' and provides example prompts. It also tells when not to use it: 'For documents at a public URL, use url.extract instead.' This provides clear guidance on alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
document.parse_invoiceParse InvoiceAParse a receipt or invoice document into structured fields. Uses a quality AI model for accuracy. Use when you need to extract line items, totals, and merchant info from financial documents. For general document text, use document.extract_text instead. Returns: { invoice: { merchant, date (YYYY-MM-DD), line_items[], subtotal, tax, total }, cited: { : { value, confidence: "high"|"medium"|"low", citations: [{ quote, paragraphs[] }] } } } Example prompts:
"Parse this invoice and give me the line items and total."
"Extract the merchant, date, and amounts from this receipt."
"Read this scanned invoice and return structured data."
| Name | Required | Description | Default |
|---|---|---|---|
| mime_type | Yes | MIME type of the document. Example: "application/pdf" for scanned invoice PDF, "image/jpeg" for a receipt photo. | |
| document_base64 | Yes | Base64-encoded PDF or image of the receipt/invoice (max ~15 MB). Example: "JVBERi0xLjcNJeLjz9MNCj..." (base64-encoded invoice PDF) |
| Name | Required | Description |
|---|---|---|
| cited | Yes | |
| invoice | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description avoids repeating that. It adds value by mentioning 'Uses a quality AI model for accuracy' and detailing the return structure, which helps the agent understand capabilities and output format. 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 with clear sections: purpose, usage, return format, and example prompts. Every sentence adds value, no fluff. Front-loaded with purpose and usage.
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 an output schema is provided in the description, and schema coverage is 100%, the description is complete. It covers what the tool does, when to use, output structure, and examples. No missing information for effective 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 description coverage is 100% with detailed descriptions for both parameters (mime_type enum, base64 example with max size). Description does not add per-parameter info but is not needed as schema covers it. 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 'Parse a receipt or invoice document into structured fields.' It specifies the exact resource (financial documents) and action (parse into structured fields). Also distinguishes from sibling tool 'document.extract_text' 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?
Explicitly says 'Use when you need to extract line items, totals, and merchant info from financial documents. For general document text, use document.extract_text instead.' Provides clear context and an alternative, making it easy for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
document.summarizeSummarize DocumentASummarize document text into a prose summary and key points with citations. Use after document.extract_text or url.extract when you need a condensed understanding of a long document. For single-sentence Q&A, use url.qa instead. For extracting specific fields, use document.extract_structured. Typical workflow: document.extract_text/url.extract → document.summarize. Returns: { summary: string, key_points: string[], summary_cited: { value, confidence, citations[] }, key_points_cited: [{ text, citations[] }], truncated: boolean, strategy: "full"|"truncated"|"chunked" } Example prompts:
"Summarize this financial report and give me the key points."
"What are the main takeaways from this document?"
"Give me a concise summary of this 50-page report."
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Document text to summarize. Obtain via document.extract_text or url.extract. Example: "The Q4 2025 financial report shows revenue growth of 23% year-over-year..." | |
| max_tokens | No | Input length cap (1 token ≈ 4 chars). Default ~3000 tokens. Truncates input, not output. Example: 4000 |
| Name | Required | Description |
|---|---|---|
| summary | Yes | |
| strategy | Yes | |
| truncated | Yes | |
| key_points | Yes | |
| summary_cited | Yes | |
| key_points_cited | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds behavioral details: returns structured output with summary, key_points, truncated flag, and strategy field; truncates input based on max_tokens, not output. 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 front-loaded with the action, then usage guidelines, output format, and examples. Every sentence adds value—no fluff. Well-structured and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite complexity (structured output with citations and truncation), the description covers output schema, typical workflow, and examples. It's complete for an agent to understand how and when to use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good descriptions. The description adds example text, explains max_tokens as input cap with truncation behavior, and provides example prompts. This adds useful context beyond the schema, justifying a score above 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 clearly states the tool summarizes document text into a prose summary and key points with citations. It distinguishes from siblings by specifying when to use (after extract_text/url.extract) and when to use alternatives (url.qa, document.extract_structured).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use after document.extract_text or url.extract, and provides alternatives for single-sentence Q&A (url.qa) and specific field extraction (document.extract_structured). The typical workflow is described.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
job.statusGet Job StatusAPoll the status of an async job (extract, indexing, batch). Free — no credits consumed. Use after collection.add_document or async extract to check when processing completes. Poll this endpoint in a loop until status is "complete" or "failed". Completed jobs include the bundle_id or result_json in the response. Jobs are created when you POST /v1/extract with a webhook, or when collection.add_document triggers async indexing. Returns: { id, type: "extract"|"extract_batch"|"index_collection", status: "queued"|"processing"|"complete"|"failed"|"cancelled", progress_pct: number (0–100), progress_message, bundle_id (when complete), result_json (when complete), error (when failed), created_at, completed_at } Example prompts:
"Check the status of my indexing job job_550e8400."
"Is my async extract job done yet?"
"Poll job [job_id] — what is the current progress?"
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | Job ID (job_...) returned by async extract or collection.add_document. Example: "job_550e8400-e29b-41d4-a716-446655440000" |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| type | Yes | |
| error | Yes | |
| status | Yes | |
| bundle_id | Yes | |
| created_at | Yes | |
| result_json | Yes | |
| completed_at | Yes | |
| progress_pct | Yes | |
| collection_id | Yes | |
| progress_message | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, indicating safe repeated calls. The description adds valuable behavior details: it's free, jobs are created by specific endpoints, and the polling loop approach. It also describes the response schema including progress_pct and error fields. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose first, followed by usage, return schema, and example prompts. It is slightly lengthy but each sentence adds value. The inclusion of a full return schema and examples enhances clarity without being wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete given the tool's complexity and the presence of a detailed output schema within the description itself. It covers purpose, usage, polling behavior, job creation triggers, and the full response structure. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the job_id parameter with an example and required status. The description repeats the example but does not add new semantic meaning beyond what the schema provides. With 100% schema coverage, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool polls the status of async jobs (extract, indexing, batch). It specifies the verb 'poll' and the resource 'status of an async job'. It distinguishes itself from sibling tools by being the only status checking endpoint, and provides context on when jobs are created.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: after collection.add_document or async extract, and recommends polling in a loop until status is 'complete' or 'failed'. It does not mention when not to use or provide alternatives, but since there is no other status tool among siblings, this is acceptable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
receipt.listList Action ReceiptsAList signed action receipts (rcpt_...) for an evidence bundle owned by your API key. Free — no credits consumed. Use after bundle.get, bundle.verify, bundle.notarize, or collection.add_document to audit which agent actions were bound to which manifest hash. Pass a receipt_id from the results to receipt.verify for independent signature + manifest-binding verification. Returns: { bundle_id, receipts: [{ receipt_id, bundle_id, agent_id, action, manifest_sha256, signed_at, signature, signer_address, key_id, algorithm }], limit, offset } Example prompts:
"List all signed action receipts for bundle ev_550e8400."
"What agent actions have been recorded against this evidence bundle?"
"Show me the receipts for [bundle_id] so I can verify one."
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max receipts to return (default 50, max 200). Example: 50 | |
| offset | No | Pagination offset (default 0). Example: 0 | |
| bundle_id | Yes | Evidence bundle ID (ev_...) to list receipts for. Example: "ev_550e8400-e29b-41d4-a716-446655440000" |
| Name | Required | Description |
|---|---|---|
| limit | Yes | |
| offset | Yes | |
| receipts | Yes | |
| bundle_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses behavioral traits beyond annotations: free (no credits consumed), returns specific structure with full JSON example. Annotations already indicate readOnlyHint and idempotentHint, so description adds 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?
Concise and well-structured: purpose sentence, usage guidelines, free note, when-to-use, next step, example output, example prompts. Front-loaded with key action and condition.
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?
Complete for a tool with 3 parameters, output schema present, and full annotations. Description covers input, output, usage context, and provides 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 description doesn't need to add much parameter info. However, it provides the output structure in the description with example fields, adding value beyond schema. Baseline 3 raised to 4 for including return format.
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 verb 'List' and resource 'signed action receipts' with context (evidence bundle owned by API key). Distinguishes from sibling receipt.verify by specifying it lists receipts, not verifies 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 instructs when to use this tool: after bundle.get, bundle.verify, bundle.notarize, or collection.add_document. Also tells the next step: pass receipt_id to receipt.verify. Mentions it's free.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
receipt.verifyVerify Action ReceiptAIndependently verify a signed action receipt (rcpt_...) returned by bundle.get, bundle.verify, bundle.notarize, collection.add_document, or listed via receipt.list. Free — no credits consumed. Proves both that the receipt signature is authentic AND that the manifest_sha256 it was bound to still matches the bundle's current manifest — i.e. that the action was not performed against a stale or since-superseded document. Use for third-party audit of an agent's prior actions. Returns: { receipt_id, valid: boolean, signature_valid: boolean, manifest_matches_current: boolean, bundle_id, agent_id, action, manifest_sha256, signer_address, signed_at, tampered: string[] } Example prompts:
"Verify action receipt rcpt_550e8400 is authentic and still current."
"Was this receipt signed against the real document, or a stale copy?"
| Name | Required | Description | Default |
|---|---|---|---|
| receipt_id | Yes | Action receipt ID (rcpt_...) returned in the receipt field of another tool's response. Example: "rcpt_550e8400-e29b-41d4-a716-446655440000" |
| Name | Required | Description |
|---|---|---|
| valid | Yes | |
| action | Yes | |
| agent_id | Yes | |
| tampered | Yes | |
| bundle_id | Yes | |
| signed_at | Yes | |
| receipt_id | Yes | |
| signer_address | Yes | |
| manifest_sha256 | Yes | |
| signature_valid | Yes | |
| manifest_matches_current | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly and idempotent; the description adds value by noting 'Free — no credits consumed' and detailing the dual verification (signature and manifest match), enriching the behavioral understanding.
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, front-loaded with purpose, followed by return type and example prompts. Every sentence adds value 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?
Despite the tool's simplicity, the description covers return fields, use case, and examples, fully sufficient given the rich annotations and output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter; the description adds the 'rcpt_...' prefix pattern and an example, but does not substantially extend 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 verifies a signed action receipt, checking both signature authenticity and manifest match, distinguishing it from siblings like receipt.list (lists) and bundle.verify (different scope).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use for third-party audit' and lists the tools that produce receipts, providing clear context. It does not explicitly state when not to use, but the purpose is well-defined against siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
url.extractExtract Text from URLAFetch a public HTTPS URL and return extracted text and page metadata. Lean mode — no evidence bundle stored, no bundle_id returned. Use for raw text extraction from web pages and online documents. Use url.summarize for summaries, url.qa for Q&A, url.translate for translation, document.extract_text for base64 file uploads. Returns: { url, title, word_count, text, final_url (after redirects) } Example prompts:
"Extract the text from https://example.com/report.pdf for me."
"Get me the raw content of this web page: [URL]."
"Pull the text from this online article so I can analyze it."
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Public HTTPS URL to fetch and extract. Example: "https://example.com/report.pdf" or "https://blog.example.com/article" |
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| text | Yes | |
| title | No | |
| final_url | No | |
| word_count | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. Description adds valuable behavioral details: 'Lean mode — no evidence bundle stored, no bundle_id returned' and mentions return of final_url after redirects.
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 (4-5 sentences) and well-structured: action, mode, usage guidance, return format, 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?
For a simple tool with one parameter, output schema, and annotations, the description is fully complete: it explains purpose, behavior, return value, and usage 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 100% with a good description and example. Description doesn't add significantly beyond the schema for the parameter itself, but example prompts provide helpful usage context, justifying a slight bonus above baseline 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 clearly states it fetches a public HTTPS URL and returns extracted text and metadata. It explicitly distinguishes from siblings by naming alternatives: url.summarize, url.qa, url.translate, document.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?
Explicitly says when to use (raw text extraction from web pages and documents) and when not (summaries, Q&A, translation, base64 uploads), with specific alternative tools mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
url.qaAsk a Question About a URLAFetch a public HTTPS URL and answer a specific question about its content. Lean mode — no bundle stored. Use when you have a precise question about a web page. For a broad summary, use url.summarize. For multi-document Q&A, use collection.ask instead. Returns: { url, answer, answer_cited: { value, confidence, citations[] }, confidence: "high"|"medium"|"low", truncated } Example prompts:
"What is the refund policy at https://docs.example.com/policy?"
"Look at [URL] and tell me what the delivery terms are."
"Answer this question based on the content of [URL]: [question]."
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Public HTTPS URL to fetch and question. Example: "https://docs.example.com/policy" | |
| question | Yes | Specific question to answer from the page content. Example: "What is the refund policy?" | |
| max_tokens | No | Input length cap (1 token ≈ 4 chars). Truncates fetched page content, not the answer. Example: 4000 |
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| answer | No | |
| truncated | Yes | |
| confidence | No | |
| answer_cited | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, openWorldHint), the description discloses 'lean mode — no bundle stored', explaining that content is not persistently stored. It also clarifies that max_tokens truncates fetched page content, not the answer, and lists return fields including confidence and 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?
The description is concise with three clear sections: what it does, when to use it, and example prompts. Every sentence adds value, and the structure is easy to parse. The return format is compactly listed.
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 (fetching and QA) and the presence of an output schema (implied by the return description), the description is complete. It covers purpose, usage, behavior, and parameters without gaps. The sibling context is also well addressed.
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 has 100% coverage with descriptions for all parameters. The description adds further value by including example prompts that demonstrate usage, and explains the effect of max_tokens (truncates input, not output), which is not apparent from 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 it fetches a public HTTPS URL and answers a specific question. It distinguishes itself from siblings like url.summarize (broad summary) and collection.ask (multi-document Q&A), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool (precise question about a web page) and when to use alternatives (url.summarize for broad summary, collection.ask for multi-document Q&A). This provides clear decision criteria for the AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
url.summarizeSummarize URLAFetch a public HTTPS URL and return a prose summary with key points. Lean mode — no bundle stored. Use when you need a condensed understanding of a web page. For raw text, use url.extract. For asking a specific question about a page, use url.qa. Returns: { url, summary, key_points: string[], truncated: boolean, word_count } Example prompts:
"Summarize https://en.wikipedia.org/wiki/Artificial_intelligence for me."
"Give me the key points from this blog post: [URL]."
"What is this article about? Summarize [URL]."
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Public HTTPS URL to fetch and summarize. Example: "https://en.wikipedia.org/wiki/Artificial_intelligence" | |
| max_tokens | No | Input length cap (1 token ≈ 4 chars). Truncates fetched page content, not the output summary. Example: 4000 |
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| summary | No | |
| truncated | Yes | |
| key_points | No | |
| word_count | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds key behavioral context beyond annotations: 'Lean mode — no bundle stored' indicates no persistence. The return object fields (summary, key_points, truncated, word_count) are listed. Annotations indicate read-only and open-world, which description does not contradict.
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 concise sentences plus a return object and examples. Front-loaded with action and mode, followed by usage guidance and alternatives. No unnecessary text; every sentence earns its place.
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 (fetch+summarize), annotations (readOnly, openWorld), and output schema, the description covers all needed context: it specifies public HTTPS only, provides usage guidelines, lists return fields, and shows 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% (both url and max_tokens described). Description does not add new parameter detail but provides example prompts that implicitly show url usage. No additional semantics for max_tokens 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?
The description clearly states the action ('Fetch a public HTTPS URL and return a prose summary with key points') and distinguishes itself from siblings (url.extract for raw text, url.qa for specific questions). The verb 'summarize' aligns with the resource 'URL' and title.
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 a condensed understanding of a web page') and provides specific alternative tools ('For raw text, use url.extract. For asking a specific question about a page, use url.qa'). Includes example prompts that guide correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
url.translateTranslate URLAFetch a public HTTPS URL and return its content translated into a target language. Lean mode — no bundle stored. Use when you need to understand web content in a different language. For extracting raw untranslated text, use url.extract instead. Returns: { url, translated_text, target_lang, truncated } Example prompts:
"Translate https://example.de/artikel into English for me."
"Translate this German article into Spanish: [URL]."
"Fetch [URL] and give me the French translation."
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Public HTTPS URL to fetch and translate. Example: "https://example.de/artikel" | |
| max_tokens | No | Input length cap (1 token ≈ 4 chars). Truncates fetched page content before translation. Example: 4000 | |
| target_lang | Yes | ISO 639-1 language code for the target language. Example: "es" for Spanish, "fr" for French, "de" for German, "ja" for Japanese, "zh" for Chinese |
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| truncated | Yes | |
| target_lang | Yes | |
| translated_text | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. Description adds valuable context: 'Lean mode — no bundle stored' clarifies no data persistence, and explains truncation behavior via max_tokens and the truncated field in the return. This goes beyond annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is brief (4 sentences + return structure + examples) and front-loaded with the core action. Every sentence provides unique value: purpose, lean mode, usage guidance, alternative, and return fields. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters (100% schema coverage), annotations, and a described output schema, the description fully covers: what it does, when to use, alternatives, input parameters, return structure, and behavioral quirks (no storage, truncation). Completeness is high relative to tool 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?
Input schema has 100% coverage with descriptions for all parameters. The description does not add new semantic details beyond the schema; it merely restates examples. Baseline 3 is appropriate as schema already handles parameter documentation.
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 fetches a public HTTPS URL and returns its content translated into a target language. It distinguishes itself from sibling url.extract by noting that url.extract extracts raw untranslated text. The verb 'translate' and resource 'URL content' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use ('when you need to understand web content in a different language') and when not to use ('For extracting raw untranslated text, use url.extract instead'). This provides clear decision guidance with a named alternative. Example prompts reinforce usage scenarios.
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.
No comments yet. Be the first to start the discussion!
