Other PDF MCP servers ask you to install Chrome, manage a local renderer, and ship templates yourself. Kamy MCP is a hosted endpoint — point any MCP client at https://mcp.kamy.dev/mcp, paste an API key, and start asking your AI to "generate an invoice for Acme Corp". Eight production-ready templates ship with the service (invoice, quote, receipt, contract, agreement, certificate, report, shipping-label)
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.2/5 across 14 of 14 tools scored. Lowest: 3.4/5.
Each tool targets a distinct action or resource: Q&A, e-signature, extraction, code generation, API setup, certificate retrieval, schema fetching, SDK install, listing, signing, rendering, validation, and verification. No overlap in intended use.
All tool names follow a consistent verb_noun pattern using lowercase and underscores (e.g., 'extract_document', 'list_templates', 'pki_sign_pdf'). No mixing of styles.
14 tools cover the full document processing lifecycle without being excessive. Each tool serves a clear purpose, matching the domain complexity.
The set covers template discovery, rendering, validation, multiple signing methods, verification, extraction, and developer tooling. No obvious gaps for the stated purpose of PDF/document management with Kamy.
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 readOnlyHint and non-destructive behavior. Description adds that it sends to a public endpoint and returns a paragraph answer, providing useful context 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?
Two sentences with no wasted words; purpose is stated first, followed by technical details. Well-structured and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter and no output schema, the description explains the action, endpoint, and response format fully. No gaps identified.
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% description coverage and includes example topics. Description does not add extra parameter details beyond what the schema provides, meeting the baseline expectation.
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 uses specific verb 'Ask' and resource 'Kamy Brain', lists example topics, and clearly differentiates from sibling tools that perform specific actions like signing or PDF generation.
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 indicates it's for asking questions about Kamy usage and returns an answer. While it doesn't explicitly state when not to use, the read-only annotation and sibling context make usage 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 mark this as a write operation (not read-only, not destructive). The description adds behavioral context: it sends an email and returns setup instructions when the API key is missing. This goes beyond annotations, though it doesn't detail error states or rate limits.
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, immediately stating the primary action and a crucial condition. Every word adds value; no unnecessary elaboration.
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 14 parameters, nested objects, and no output schema, the description provides the core workflow but omits what the tool returns (e.g., a signature request ID). An agent may need to infer the response format from context. Adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all 14 parameters. The tool description reinforces the meaning of renderId by mentioning 'previously rendered PDF', which adds context beyond the schema. However, the description itself does not elaborate on all parameters, but the schema compensates fully.
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 sends a previously rendered PDF for e-signature, specifying the prerequisite (Kamy API key) and the fallback behavior (returns setup instructions without key). This distinguishes it from siblings like render_pdf and other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates when to use (with Kamy API key) and hints at alternatives (setup instructions if no key). It doesn't explicitly name sibling tools like get_api_key_instructions, but the context is sufficient for an agent to infer proper usage.
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?
Annotations show readOnlyHint=false and destructiveHint=false. The description adds the output (parsed JSON + verify URL) but does not clarify if state changes occur (e.g., storing extracted data). Since annotations already hint at non-read-only behavior, the description should ideally explain any side effects or stored state.
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 with no filler. First sentence covers purpose and output, second provides usage guidance. Every word 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 no output schema, the description adequately mentions return values (parsed JSON + verify URL). It does not detail template-specific fields or error handling, but the tool is fairly simple with 3 params and no nested objects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter described. The description adds no further parameter details beyond schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it extracts structured data from PDFs, lists document types (invoice, receipt, contract, ID document, or any form), and mentions return values (parsed JSON plus verify URL). The verb 'extract' combined with the resource (document) is specific, and it distinguishes from siblings as the only extraction tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this when an agent needs to read an inbound document and act on it,' providing clear context. It lacks an explicit 'when not to use' or alternatives, but no direct sibling competes for this purpose, so it's sufficient.
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 codeBGenerate 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?
The description adds minimal behavioral information beyond the annotations. The annotations already indicate readOnlyHint=true and destructiveHint=false. The description's 'generate copy-paste integration code' aligns with those traits but discloses no additional behaviors such as error handling, rate limits, or output format.
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 zero wasted words. It efficiently communicates the tool's core purpose without any 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?
For a simple tool with two parameters and clear annotations, the description reasonably conveys the tool's purpose and usage. However, it lacks details about expected output (since no output schema exists), but the 'copy-paste' phrasing hints at the response type. Given the low complexity, the description is largely 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 both parameters fully described. The description adds no extra meaning beyond what the schema provides (e.g., it does not explain how to obtain template slugs or clarify framework values). Baseline 3 is appropriate as the description neither enhances nor detracts from 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 action ('generate'), the resource ('copy-paste integration code'), and the constraints ('for a specific Kamy template and framework'). It effectively distinguishes this tool from siblings like get_template_schema by focusing on code generation rather than schema retrieval.
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 (e.g., get_template_schema, ask_kamy). It does not state prerequisites, when not to use, or the intended workflow context. The guidance is entirely implicit based on the purpose.
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 indicate read-only and non-destructive behavior. The description adds that the tool does not open the browser, which is a behavioral detail beyond the annotations. 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?
The description is a single sentence that is front-loaded with the core purpose. It is concise and contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema, safe annotations), the description is mostly complete. It could be improved by specifying the format of the instructions, but it is sufficient for an AI agent to understand its purpose.
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 baseline is 4. The description does not need to explain parameters, and the schema coverage is 100% (trivially).
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 returns step-by-step instructions for creating a Kamy API key, and adds that it does not open the browser. This distinguishes it from sibling tools which perform different actions like asking questions, signing, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for obtaining API key instructions but does not explicitly state when to use this tool versus alternatives or when not to use it. With sibling tools covering various operations, some guidance would be helpful.
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 that the result is a URL, explains the terminal state requirement, and mentions a potential error response (409) for pending requests. 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?
Two sentences that front-load the primary purpose and then add conditions. Every sentence serves a purpose with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one parameter, strong annotations, and no output schema, the description covers all necessary context: what it returns, preconditions (terminal state), and fallback behavior (setup instructions). 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 has 100% coverage with a description for signatureRequestId. The description adds essential context: that the ID must belong to a request in a terminal state, and that pending requests return a 409 error. This goes beyond the schema's format and type info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states it returns the authenticated download URL for a Certificate of Completion PDF, an audit trail. This clearly distinguishes it from sibling tools (e.g., list_signature_requests, 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?
Description notes the tool is only available after the request reaches a terminal state and that without a key it returns setup instructions. While it doesn't explicitly list when not to use, the terminal state constraint provides clear guidance, and sibling tools do not overlap.
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 indicate readOnlyHint=true and destructiveHint=false. Description adds value by stating 'No authentication required' and the recommended usage sequence, without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two succinct sentences, front-loaded with main purpose. No unnecessary words; each sentence adds relevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description covers purpose, usage timing, and authentication. No gaps given the 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?
Single parameter 'slug' is fully described in schema with examples. Description does not add additional semantic details beyond what schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it fetches JSON schema and sample payload for a template, with specific verb 'Fetch' and explicit mention of resource. Distinguishes itself by advising to call before render_pdf, differentiating 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?
Explicitly says to call before render_pdf and notes no authentication required. Provides clear context for when to use, though lacks explicit when-not or alternative exclusions.
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 declare readOnlyHint=true and destructiveHint=false. The description adds clarity by stating it returns install commands and setup code, confirming no mutations occur. This aligns with annotations and provides further behavioral 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?
A single, well-structured sentence that communicates the core function without any extraneous words. Every part contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of the tool (retrieving install commands) and no output schema, the description is largely sufficient. It could potentially mention the output format (e.g., returns text or code block), but for a straightforward retrieval operation, it is contextually complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters with enums and descriptions (100% coverage). The description adds no additional semantic detail about the parameters beyond what the schema provides, so 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 verb 'get install commands and setup code for @kamydev/sdk in your framework', defining a specific action on a distinct resource. It immediately distinguishes from sibling tools like create_signature_request or verify_pdf_signature by its focus on 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?
No explicit when-to-use or when-not-to-use guidance is provided. However, the purpose is self-evident among diverse sibling tools, and the description implies it should be used when the user needs installation commands for the Kamy SDK. An exclusion or alternative mention would improve this.
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=true and destructiveHint=false. The description adds behavioral context by specifying that without an API key, the tool returns dashboard setup instructions, which is beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero waste: first states the core function, second adds crucial context about key dependency. Every sentence is necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and simple parameters (2 optional), the description explains ordering and key behavior. It omits exact return structure, but for a list endpoint this is acceptable. Somewhat complete for its 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%, and the schema descriptions for limit and offset are already clear (defaults, ranges). The tool description adds no additional parameter information, so it meets 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 clearly states the tool lists signature requests (verb+resource), scoped to the configured Kamy account, with newest-first ordering. It distinguishes from sibling tools like create_signature_request and extract_document.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly guides usage by noting that without a key it returns setup instructions, but it does not explicitly state when to use this tool versus alternatives like create_signature_request 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_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 that these are public system PDF templates and require no authentication, providing additional context 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 sentence that conveys all necessary information without any fluff. It is perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, complete annotations, and no output schema, the description fully covers what the tool does and an important usage condition (no authentication). 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?
There are no parameters, so the description does not need to provide parameter details. Schema coverage is 100% (trivially), and the description is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (List), the resource (templates), and the scope (Kamy's public system PDF templates). It effectively distinguishes from siblings like list_signature_requests by specifying 'PDF templates'.
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 includes 'No authentication required,' which provides useful context for when to use this tool. It does not explicitly mention when not to use it, but the sibling tools are clearly different in purpose.
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 indicate it is not read-only (readOnlyHint=false), and the description confirms it performs a cryptographic signature, which is a mutation. It also discloses the alternative outcome when no key is configured. No contradictions with annotations. Additional details about the signing standard (PAdES) are provided, but the impact on the original render is not explicitly stated.
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 only two sentences. The first sentence front-loads the main purpose and condition, and the second covers the fallback. 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?
Despite having 7 parameters and no output schema, the description does not explain what the tool returns (e.g., a signed PDF or a new document). It also lacks details on the signing process or prerequisites beyond the API key. Given the complexity of signing, more guidance is needed for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents each parameter well. The tool description does not add extra parameter guidance beyond what the schema provides, meeting the baseline expectation.
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 ('cryptographically sign an existing render with PAdES') and the resource ('existing render'). It distinguishes this tool from siblings like verify_pdf_signature or create_signature_request by specifying the signing action and the condition of having a Kamy API key configured.
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 context for when to use the tool ('when a Kamy API key is configured') and what happens without it ('returns dashboard setup instructions'). However, it does not directly compare with sibling tools or state when not to use this tool, but the conditional guidance is helpful.
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?
Annotations are neutral (readOnlyHint=false, destructiveHint=false). Description adds useful behavioral details: the tool requires a configured API key to function and returns setup instructions otherwise. 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?
Two sentences, no redundancy, front-loaded with the main purpose. Every sentence provides value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description could mention the output format (e.g., PDF file). However, the key dependency and fallback behavior are well covered, making it sufficient for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 67% of parameters with descriptions. The description does not add new parameter-specific information beyond the schema, so baseline score 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?
Clearly states the action (render a PDF) and the resources (Kamy template and data). Distinguishes from sibling tools like ask_kamy or pki_sign_pdf by specifying the Kamy template rendering context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context on when the tool works (with API key) and what happens without it (returns setup instructions). While it doesn't explicitly mention alternatives, the unique Kamy template use case implicitly guides selection.
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?
Annotations already indicate readOnly and non-destructive. Description adds that it's a dry-run, no quota use, returns self-healing errors. 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?
Two clear sentences: first explains operation and return, second mentions API key requirement. 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?
No output schema, but description explains what is returned (per-field self-healing errors). Covers all relevant aspects for a validation 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%, so baseline 3. The description mentions 'Template slug (e.g. invoice) or template UUID' which already appears in schema. Does not add significant new meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it dry-runs a render payload against a template schema without producing a PDF or using quota. Distinguishes from sibling render_pdf by specifying what it does not do.
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 before render_pdf to fix data, implying when to use. Provides context on what it does, but does not explicitly state when not to use or list other alternatives.
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?
The description adds behavioral details beyond annotations, such as hashing in-memory and no storage/forwarding. This aligns with the readOnlyHint and provides clear safety 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?
Two sentences, each earning its place: first states the core action, second provides critical usage detail. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description fully covers what the tool does, how it processes input, and what it returns (the URL). 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?
The description adds meaning to the pdfBase64 parameter by explaining its role in computing the URL and reiterating the in-memory handling, which is already in the schema but reinforced.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool computes a verification URL without making an API call, using a specific verb (compute) and resource (URL). This distinguishes it from siblings like pki_sign_pdf, which perform signing, and ask_kamy, which involves API queries.
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 indicates when to use the tool ('without making a Kamy API call') and provides context about in-memory processing. However, it does not mention when not to use it or list alternatives.
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!
