Document API for AI-native software: render PDFs, e-sign, PAdES-seal, and verify.
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.1/5 across 12 of 12 tools scored. Lowest: 3.3/5.
Each tool targets a distinct action: asking questions, extracting data, rendering, signing (e-signature and PKI), verifying, listing, generating code, and providing instructions. No two tools have overlapping purposes.
All tool names follow a consistent verb_noun pattern using snake_case, e.g., create_signature_request, list_templates, verify_pdf_signature. Even pki_sign_pdf fits the pattern with 'pki' as a prefix.
12 tools is well-scoped for a document/e-signature server, covering key operations without being overwhelming. Each tool fills a specific role in the workflow.
The toolset covers rendering, extraction, signing, verification, listing, and integration. Minor gaps exist (e.g., no update/cancel for signature requests, no template creation), but core workflows are fully supported.
ask_kamyAsk KamyAAsk Kamy Brain a question about Kamy usage, templates, plans, or errors. Sends the question to Kamy's public assistant endpoint and returns a paragraph answer.
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | The question to ask Kamy about — how to render a template, why a render failed, what plan to pick, etc. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only and non-destructive. The description adds that it sends the question to a public assistant endpoint and returns a paragraph answer, providing useful context about the network call and output format 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 a single, front-loaded sentence that states the purpose, mechanism, and output without any wasted words. It is appropriately sized for a simple 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?
For a one-parameter tool with no output schema, the description covers the tool's purpose, what kinds of questions to ask, and what the response format is (a paragraph answer). Annotations cover safety, so the overall context 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%: the 'question' parameter is fully described with examples ('how to render a template, why a render failed, what plan to pick'). The tool description's topic list overlaps with the schema examples and adds no new parameter-level semantics, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Ask'), names the resource ('Kamy Brain'), and specifies the topics ('usage, templates, plans, or errors'). It clearly distinguishes this from all sibling tools, none of which are Q&A-oriented.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It identifies when to use the tool by listing question categories, and the context makes it obvious that it is for informational queries. It does not explicitly name alternatives, but no sibling tool provides a competing assistant Q&A function, so the guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_signature_requestSend for e-signatureAInspectSend a previously rendered PDF to a signer for e-signature when a Kamy API key is configured. Without a key, returns dashboard setup instructions.
| Name | Required | Description | Default |
|---|---|---|---|
| message | No | Optional message rendered in the email invitation body. | |
| ccEmails | No | Up to 10 observer addresses CC'd on the invite and the completion notice. Not signers themselves. | |
| position | No | Optional sender-chosen signature placement in PDF points (72 dpi, origin bottom-left). Defaults to bottom-right of the last page sized 220×64 pt; when omitted, the signer can drag the placeholder on the sign page. | |
| renderId | Yes | Render UUID returned by render_pdf or any /v1/render call. The render's PDF is the document the signer will receive. | |
| expiresIn | No | How long (seconds) the sign link stays valid. Defaults to 30 days. Min 1 hour, max 30 days. | |
| authMethod | No | Identity-verification mode. `link` (default) — possession of the secret URL is the only check. `email_otp` — sign page renders a 6-digit OTP gate; code emailed to `signerEmail`. `sms_otp` — same gate, code texted to `signerPhone` (which must then be supplied). Recommend `email_otp` for higher-value transactions. | |
| signerName | Yes | Recipient full name. Must be typed verbatim by the signer to confirm intent. | |
| signerEmail | Yes | Recipient email address. | |
| signerPhone | No | E.164 phone number. Required when `authMethod` is `sms_otp`; ignored otherwise. Example: `+14155551234`. | |
| placedFields | No | Up to 100 sender-defined fillable fields stamped onto the PDF at sign time. Use for flat PDFs that don't ship AcroForm widgets. Names must be unique. | |
| requireStamp | No | Require the signer to upload a company stamp / seal alongside their personal signature (UAE, KSA, JP, KR, IN, CN B2B workflows). Server refuses to seal without one. | |
| signOnEveryPage | No | When true, the server stamps the signer's signature on every page of the source PDF instead of only the configured position. Common B2B contract pattern. | |
| signatureTemplateId | No | Apply a signature template's defaults (placedFields, position, message, expiresIn, ccEmails). Request-level fields override the template. | |
| reminderCadenceHours | No | When set (24–168), the auto-reminder cron resends the invite every N hours while the request stays pending, up to 3 reminders. Omit for no auto-reminders. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a non-read-only, non-destructive mutation. The description adds the key-based conditional behavior and the fallback instruction response, but does not detail side effects such as emailing the signer, creating a persisted signature request, or the eventual lifecycle. With annotations present, this is adequate but not rich.
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 two sentences, front-loaded with the primary action and condition, and contains zero unnecessary words. It is appropriately concise 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 tool's complexity (14 params, nested objects, no output schema), the description is minimal. It does not explain return values on success, the full signing workflow, or how the signature request will be tracked. However, the comprehensive schema compensates for many parameter-level details, making this adequate but incomplete.
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 fully documents all 14 parameters. The description adds no parameter-specific detail beyond what the schema already provides, such as the relationship of renderId to prior render calls. Baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sends a previously rendered PDF for e-signature, with a specific precondition (Kamy API key) and a distinct fallback behavior. This clearly differentiates it from sibling tools like render_pdf or pki_sign_pdf, which handle other parts of the document workflow.
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 indicates a prerequisite (API key configured) and implies the tool is used after rendering, but it does not explicitly state when not to use it or name alternative tools like pki_sign_pdf for certificate-based signing. The guidance is present but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
extract_documentExtract document (Kamy Ingest)AInspectExtract structured data from a PDF (invoice, receipt, contract, ID document, or any form). Returns the parsed JSON plus a public verify URL that proves the extraction matches the source. Use this when an agent needs to read an inbound document and act on it.
| Name | Required | Description | Default |
|---|---|---|---|
| template | Yes | Predefined template id. invoice/receipt for AP and POS docs, contract for legal agreements, id_document for passports/IDs, generic_form for anything else. | |
| source_url | No | Public URL to a PDF (preferred). One of source_url or source_base64 is required. | |
| source_base64 | No | Base64-encoded PDF bytes. Use when the source isn't publicly fetchable. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description directly contradicts the annotations. readOnlyHint is false, yet the description frames the tool as a read-only operation ('read an inbound document', 'Extract'), implying no side effects. This is a serious inconsistency that could mislead an agent about the tool's side effects.
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 two sentences long, front-loaded with the action and object, and every sentence serves a purpose: stating the function and providing usage guidance plus return value details. There is no wasted text.
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 explains return values (parsed JSON and verify URL) which is necessary since there is no output schema. It also covers typical input types. However, it omits any mention of side effects or persistence that the 'Ingest' title implies, and the read-only framing contradicts annotations, leaving key context incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% parameter coverage with descriptions for all three parameters. The description adds no extra parameter-level semantics beyond what the schema offers, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Extract structured data from a PDF' and enumerates common document types (invoice, receipt, contract, ID document, any form). This clearly distinguishes it from sibling tools like render_pdf or verify_pdf_signature, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context: 'Use this when an agent needs to read an inbound document and act on it.' This tells the agent when to choose this tool, though it doesn't explicitly mention when not to use it or name alternatives. The guidance is clear but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_integration_codeGenerate integration codeAGenerate copy-paste integration code for a specific Kamy template and framework.
| Name | Required | Description | Default |
|---|---|---|---|
| template | Yes | Template slug (e.g., 'invoice') | |
| framework | Yes | Target framework |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a non-mutating operation. The description adds no extra behavioral context beyond implying the output is copy-paste code, but this is consistent and sufficient for such a simple tool.
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 a single front-loaded sentence with no unnecessary words. It immediately conveys the core purpose and is appropriately sized for the tool's simplicity.
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 only 2 parameters, no output schema, and no nested objects, the description is fully sufficient. It states what the tool generates and for what inputs, and the annotations cover safety. No additional information is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters (template and framework) already documented in the schema. The description adds no new parameter-level meaning but does not need to, as the schema provides complete semantic information.
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 ('Generate copy-paste integration code') and its scope ('for a specific Kamy template and framework'). This distinguishes it from sibling tools like get_template_schema or install_sdk, which focus on schema retrieval or SDK installation.
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 no explicit guidance on when to use this tool versus alternatives or any prerequisites. It simply states what it does without addressing usage context, such as 'use this when you need copy-paste code' or 'if you need schema, use get_template_schema instead.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_api_key_instructionsGet API key instructionsAReturn step-by-step instructions for creating a Kamy API key in the dashboard. Does not open the browser.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds value by stating 'Does not open the browser,' which clarifies that no external action occurs. This is a simple, safe read-only tool, and the description adequately covers behavior 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 two short sentences, immediately stating the verb and resource. Every word serves a purpose, including the useful clarification about browser behavior. No filler or redundant 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 zero-parameter, read-only informational tool with no output schema, the description fully covers what the agent needs: what the tool returns (steps) and that it does not interact with the outside world. No additional details are necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline of 4 applies. The description provides no parameter-specific details, but none are needed given the empty input schema. It correctly conveys that the tool takes no arguments.
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 (return step-by-step instructions) and the specific resource (creating a Kamy API key). It distinguishes itself from sibling tools which perform actions like creating signatures or extracting documents. The additional note about not opening the browser removes ambiguity about side effects.
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 tool's purpose is self-explanatory and clearly differentiates from all sibling tools. The description implies it should be used when an agent needs instructions for API key creation. It does not explicitly mention alternatives or exclusions, but no competing tool exists for this task, so the context is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_signature_certificateGet Certificate of Completion URLAReturns the authenticated download URL for a signature request's Certificate of Completion PDF — the process audit trail (invite → opened → consent → signed, with IP / user-agent) that legal teams expect. Only available after the request reaches a terminal state. Without a key, returns dashboard setup instructions.
| Name | Required | Description | Default |
|---|---|---|---|
| signatureRequestId | Yes | ID of the signature_request to fetch the Certificate of Completion for. Must be in a terminal state (signed / declined / delegated / voided / expired); pending requests return 409. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral context beyond annotations: the URL is authenticated, availability depends on terminal state, and the error path when no key is present. This is consistent with the annotations and enhances 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?
The description is concise, consisting of only two sentences plus a parenthetical. It front-loads the main purpose, then adds the audit trail context and usage constraints without any redundancy or 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?
With no output schema, the description sufficiently explains the return value (authenticated download URL) and what the PDF contains. It also covers key usage constraints (terminal state, API key behavior). The parameter is fully documented in the schema, so the description is complete for this simple 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 the signatureRequestId parameter fully described including the terminal-state requirement and 409 error. The description adds context about the certificate's purpose but does not provide additional parameter-level semantics beyond what the schema already documents.
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 'Returns' and the specific resource 'authenticated download URL for a signature request's Certificate of Completion PDF'. It distinguishes itself from sibling tools by focusing on the audit trail content, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use the tool ('Only available after the request reaches a terminal state') and notes the requirement for an API key. However, it does not name alternative tools for related actions (e.g., retrieving the signed document), so it lacks a full when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_template_schemaGet template schemaAFetch the JSON Schema (exact data shape) and a copy-pasteable sample payload for a Kamy system template by slug. Call this before render_pdf so you fill the right fields with the right types instead of guessing. No authentication required.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Template slug — e.g. 'invoice', 'receipt', 'uae-tax-invoice'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds value by disclosing 'No authentication required' and describing the return content (JSON Schema + sample payload), which enhances behavioral understanding 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 two sentences long, front-loaded with the main action, and every sentence earns its place ('Fetch...', 'Call this before render_pdf...', 'No authentication required'). No fluff 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's simplicity (one parameter, no output schema), the description is complete: it states what is returned (JSON Schema and sample payload), why it should be used (to fill correct fields/types), and the authentication requirement. No additional context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for the single parameter 'slug' with a clear description and example. The tool description only repeats 'by slug' without adding additional semantic detail, so it does not go 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 uses a specific verb 'Fetch' and clearly names the resource: 'the JSON Schema (exact data shape) and a copy-pasteable sample payload for a Kamy system template by slug.' It also distinguishes itself from siblings by positioning as a prerequisite to render_pdf, which is a distinct 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?
The description explicitly states when to use it: 'Call this before render_pdf so you fill the right fields with the right types instead of guessing.' This provides clear context and names the related tool render_pdf, but it does not explicitly list when-not-to-use scenarios or mention alternative tools like list_templates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
install_sdkInstall Kamy SDKAGet install commands and setup code for @kamydev/sdk in your framework.
| Name | Required | Description | Default |
|---|---|---|---|
| framework | Yes | The framework the user is working with | |
| packageManager | No | Package manager to use | npm |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and destructiveHint=false, so the safe read-only nature is clear. The description adds that it returns commands and setup code, but does not disclose additional behavior such as whether the commands are static templates or fetched dynamically. With annotations covering safety, this is adequate but not rich.
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 a single, front-loaded sentence that conveys the essential purpose without unnecessary words. Every word contributes 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 informational tool with comprehensive annotations and fully described parameters, the description is sufficient. It does not need to explain return values (no output schema), but a note about the output format (e.g., plain text commands) could add clarity. Overall, it is complete enough for the tool's 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 both parameters described. The description adds a bit of meaning by referencing 'in your framework', which aligns with the framework parameter, but it does not elaborate on how packageManager affects output. Since the schema already covers semantics, the description provides marginal additional value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('install commands and setup code for @kamydev/sdk') and scopes it by framework. This clearly distinguishes it from sibling tools like generate_integration_code, which focuses on code generation rather than installation.
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 implies usage when the user needs to install the SDK, and the framework parameter is mentioned ('in your framework'). However, there is no explicit guidance on when not to use this tool or how it differs from generate_integration_code or get_api_key_instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_signature_requestsList signature requestsAList signature requests created by the configured Kamy account, newest first. Without a key, returns dashboard setup instructions.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Default 50. | |
| offset | No | Default 0. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and non-destructive, so the description adds value by specifying the "newest first" ordering and the special behavior of returning dashboard setup instructions when no key is present. This gives the agent awareness of an edge case beyond just a read operation.
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?
Two sentences, direct and information-dense. The main purpose is stated first, with a valuable caveat in the second sentence. No whitespace 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?
For a simple list tool with two optional parameters and clear annotations, the description covers the core function, ordering, and a critical edge case. It doesn't detail the response structure, but that is not fully required given no output schema and the simplicity of the expected result.
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?
Both parameters limit and offset are fully described in the schema with defaults and constraints, so the description doesn't need to add anything. The description provides no additional parameter context, matching the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb "List" and identifies the resource as "signature requests" scoped to "configured Kamy account" with "newest first" ordering, clearly distinguishing it from sibling tools like list_templates or create_signature_request.
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 implies usage for listing signature requests but does not explicitly mention alternatives or exclusions, such as using list_templates for templates. The "without a key" note provides some contextual guidance but not comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_templatesList templatesAList Kamy's public system PDF templates. No authentication required.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral context: it specifies that the list covers only 'public system' templates and explicitly notes 'No authentication required', which goes beyond what annotations provide. It does not contradict 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 two short sentences, front-loaded with the essential action and resource. Every word earns its place, and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless list tool with no output schema and annotations already covering safety, the description is complete: it tells what is listed, the scope, and the authentication requirement. No further information is needed for an agent to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is trivially 100%. Per the guidelines, a baseline of 4 applies for no-parameter tools. The description does not need to explain parameters, and it does not add any parameter-related noise.
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 ('List'), the resource ('Kamy's public system PDF templates'), and the scope ('public'). This distinguishes it from sibling tools like get_template_schema or list_signature_requests, which target different resources or actions.
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 clear context by specifying the exact set of templates (public system PDF templates) and notes that no authentication is required. It does not explicitly name alternatives or exclusions, but the context is sufficient for an agent to determine when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pki_sign_pdfPKI-sign PDFAInspectCryptographically sign an existing render with PAdES when a Kamy API key is configured. Without a key, returns dashboard setup instructions.
| Name | Required | Description | Default |
|---|---|---|---|
| reason | No | Optional /Sig dictionary Reason — surfaced in Acrobat's signature panel. ASCII-coerced server-side. | |
| location | No | Optional /Sig dictionary Location. | |
| renderId | Yes | Render UUID returned by render_pdf or any /v1/render call. The PDF will be sealed with a Kamy-issued X.509 leaf certificate. | |
| signerName | No | Override the signer display name. Defaults to the account's full_name. | |
| signerEmail | No | Override the signer email. Defaults to the account's email. | |
| withTimestamp | No | When false, skip the RFC 3161 timestamp call (PAdES-B-B instead of B-T). Default: true. | |
| withRevocationInfo | No | When false, skip embedding the Kamy CA CRL into the PKCS#7 SignedData (PAdES-B-T instead of B-LT). Online verifiers can still fetch the CRL via the Distribution Point on the leaf cert. Default: true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false, providing minimal safety signals. The description adds valuable non-obvious context: the cryptographic nature (PAdES), the API key requirement, and the conditional return of setup instructions. However, it does not disclose other behaviors like idempotency, side effects on the render, or failure modes beyond the missing key.
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?
Two sentences, front-loaded with the primary action and the key condition. No filler words; every phrase adds information. The conditional 'Without a key' is an efficient way to describe the no-key scenario.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 7 parameters and no output schema. The description covers the prerequisite and fallback output, but does not mention what a successful signing returns (e.g., a signed PDF, a status object, or a render ID). It also omits any warnings about irreversibility or the need for the render to be in a valid state. Given the parameter richness is handled by the schema, this gap prevents a higher score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and each parameter has a clear description in the schema itself. The tool description adds no parameter-specific meaning beyond what the schema documents, but that is acceptable because the schema carries the full burden. A baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('sign') and resource ('existing render') with the method ('PAdES'), clearly distinguishing it from sibling tools like render_pdf (creates renders) and verify_pdf_signature (verifies). The phrase 'existing render' reinforces it is a follow-on action.
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 the prerequisite ('when a Kamy API key is configured') and the fallback behavior when the key is missing. It implies usage on existing renders rather than new ones, which distinguishes it from render_pdf, but it does not explicitly name alternative tools or when not to use it (e.g., for verification).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
render_pdfRender PDFAInspectRender a PDF from a Kamy template and data when a Kamy API key is configured. Without a key, returns dashboard setup instructions.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | Data to populate the template | |
| format | No | a4 | |
| template | Yes | Template slug (e.g., 'invoice') or template UUID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals an important behavioral trait: without an API key, it returns setup instructions instead of rendering. It also implies that an API key is required for the core functionality. However, it does not disclose potential side effects like sending data to an external Kamy API or what the successful response format is, which are relevant beyond the minimal 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 a single sentence that front-loads the core purpose and then adds a critical conditional. Every word earns its place; there is no redundancy or filler. It is highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain what the tool returns on success, but it only mentions the fallback return (dashboard setup instructions) when no key is present. It does not state whether the PDF is returned as a file, base64, URL, or any other format, leaving a significant gap for an agent to know what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for 'data' and 'template', and the 'format' parameter is self-explanatory via its enum and default. The description adds no additional parameter meaning. With 67% schema coverage, the description is not required to compensate, so the 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's function with a specific verb 'render' and explicit resources ('PDF from a Kamy template and data'). It effectively distinguishes from sibling tools like 'pki_sign_pdf' or 'verify_pdf_signature' by focusing on rendering rather than signing or verifying.
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 clear conditions for use: it only works 'when a Kamy API key is configured', and without a key it returns dashboard setup instructions. This gives the agent context on when to invoke the tool, though it does not explicitly mention alternatives or when not to use it beyond the key condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
validate_payloadValidate payloadADry-run a render payload against a template's schema WITHOUT producing a PDF or using quota. Returns per-field self-healing errors (expected type, value received, allowed values, an example) so you can fix the data before render_pdf. Requires a Kamy API key.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | The data payload to validate against the template schema. | |
| template | Yes | Template slug (e.g. 'invoice') or template UUID. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly, non-destructive), the description adds valuable behavioral details: it does not generate a PDF or use quota, requires a Kamy API key, and returns self-healing per-field errors including expected type, value received, allowed values, and an example. This exceeds the annotation baseline and provides significant operational context.
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-loads the primary action, and every clause adds value—mentioning the dry-run nature, the return error format, the parallel to render_pdf, and the auth requirement. Nothing is redundant or wasted.
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, the description covers the purpose, usage timing, return behavior, and auth requirement. Since there is no output schema, the description sufficiently explains what the tool returns (self-healing errors). It leaves minimal gaps for an agent to misuse 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 description coverage is 100%, with both parameters already described ('data' as the payload and 'template' as slug or UUID). The description does not add extra meaning beyond the schema, so it stays at 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 validates a payload against a template schema, with a specific verb ('Dry-run'), and distinguishes itself from render_pdf by explicitly noting it does NOT produce a PDF or consume quota. This makes the purpose unambiguous and differentiates it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context by saying it lets you 'fix the data before render_pdf,' implying it should be used prior to rendering. However, it does not explicitly mention when not to use it or name alternative tools like get_template_schema, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_pdf_signatureVerify PDF signatureACompute the kamy.dev/verify URL for a PDF without making a Kamy API call. Pass the PDF as base64; the MCP Worker hashes it in-memory and does not store or forward it.
| Name | Required | Description | Default |
|---|---|---|---|
| pdfBase64 | Yes | Base64-encoded PDF bytes. The MCP Worker hashes the file in-memory and does not store or forward it. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite readOnlyHint and destructiveHint annotations, the description adds critical context: the worker hashes the PDF in-memory, does not store or forward it, and no API call is made. This goes beyond annotations by disclosing privacy and side-effect-free behavior, which is valuable for trust and safe usage.
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 a single, front-loaded sentence that conveys purpose, usage, and privacy in a compact way. Every clause earns its place with no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema, the description covers the essential aspects: what it does (compute URL), how to call it (base64), and key behavioral guarantees (no API call, no storage). The return value (the URL) is implied by the purpose, making it complete for this simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes pdfBase64 (base64-encoded PDF bytes, in-memory hash, no storage). The description repeats this info ('Pass the PDF as base64') without adding new semantics, so it neither improves nor detracts from schema coverage. 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 computes a kamy.dev/verify URL for a PDF, using a specific verb ('compute') and resource (URL for a PDF). This distinguishes it from sibling tools like pki_sign_pdf (which signs) and extract_document (which extracts).
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 the primary use case: generate the verify URL without making a Kamy API call, and instructs to pass the PDF as base64. It implies when to use this tool (when you have a PDF and want the URL locally) but does not explicitly name alternatives or state when not to use it.
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!
Sign in to create a connector for this server.
