Skip to main content
Glama

kya_renew_prove

Free. Second step of kya_renew: send both signatures of the renewal challenge; the credential is re-issued for 90 days if the e-CNPJ is not revoked and the company is still ATIVA.

Input Schema

NameRequiredDescriptionDefault
challenge_idYeschallenge.id from kya_register (or kya_renew).
credential_idYescredential_id returned by kya_register.
agent_signatureYesSignature of challenge.text by the agent key: EIP-191 personal_sign hex (evm) or raw Ed25519 base64url (web-bot-auth).
ecnpj_signatureYesCMS/PKCS#7 SignedData (detached, base64 DER) of challenge.text, signed with the company's e-CNPJ certificate.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare openWorldHint=true, so the description carries most of the disclosure burden and does it well: it states this call is free, that it consumes a renewal challenge, that success re-issues the credential for 90 days, and that success is conditional on revocation status and company registration status. Missing error behavior, but the outcome model is unusually clear.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One sentence, front-loaded with the cost fact ('Free.') and the sequencing fact, with no filler. Every clause carries information an agent needs before calling.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, and the description compensates by spelling out the return outcome (re-issue for 90 days) and the conditions attached to it. Combined with fully documented parameters and the precondition chain, this is close to complete for a 4-param step tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and each of the four parameters is documented in-schema (signature formats, challenge_id source). The description's 'send both signatures' adds only a light grouping hint beyond the schema, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb+resource: send both signatures of the renewal challenge, with the resulting action (credential re-issued for 90 days) named. It explicitly positions itself as the second step of the sibling kya_renew, so an agent can distinguish it from kya_renew and kya_prove without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Requires the agent to have completed kya_renew first ('Second step of kya_renew'), which is clear sequencing guidance, and states the success preconditions (e-CNPJ not revoked, company ATIVA). It stops short of naming explicit failure branches or what to do if preconditions aren't met.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources