Safefy MCP
OfficialServer Quality Checklist
Latest release: v1.0.0
- Disambiguation5/5
Each tool targets a distinct resource and action, from configuration and authentication to transactions, cashouts, customers, orders, products, and payment links. The generic api_request tool is clearly scoped as a fallback for routes without dedicated tools, preventing confusion.
Naming Consistency5/5All tools follow a consistent safefy_payment_<verb>_<noun> pattern in snake_case, with only minor deviations like 'authenticate' and 'api_request'. This predictability makes it easy for an agent to infer function from the name.
Tool Count3/5At 29 tools, the set is comprehensive but heavy. While most tools serve a clear purpose for a full payment API, the count edges into the 'too many' range and could be streamlined by consolidating niche operations like simulate and resend-webhook.
Completeness3/5The set covers core operations for transactions, cashouts, customers, orders, products, and payment links, but lacks some lifecycle operations (e.g., refund/cancel transaction, update/delete product, create payment link). The generic api_request mitigates gaps but leaves the dedicated surface incomplete.
Average 3.6/5 across 29 of 29 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto the root of your repository:{ "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": [ "your-github-username" ] }Then . Browse examples.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, but the description adds no behavioral detail beyond the endpoint; it doesn't mention pagination, filtering semantics, or response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, so it is concise, but it offers minimal information beyond the title. It is under-specified rather than efficiently complete.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters and no output schema, the description should explain return structure, pagination, and filtering; it only names the endpoint. This is inadequate for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (just date format for startDate/endDate). The description provides no parameter explanations, leaving page, search, status, pageSize, externalId, and documentType without added meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Lista' and resource 'clientes', and gives the endpoint '/v1/customers'. This clearly indicates a list operation, though it doesn't explicitly distinguish from sibling customer tools beyond the list verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as get_customer, create_customer, or list_transactions. It lacks any context about use cases, prerequisites, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. However, the description adds no behavioral context beyond the word 'filters,' which is already evident from the parameter schema. It does not disclose pagination behavior, filter combination logic, or response format, so it adds minimal value over the structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence, so it is undeniably concise. However, it is essentially a Portuguese restatement of the title and contributes little additional information. It is not verbose, but it under-specifies rather than effectively using its concise form.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with 8 optional parameters and no output schema, the description is incomplete. It omits return value details, pagination defaults, and filter semantics. The strong annotations mitigate safety concerns but do not compensate for the lack of operational context needed to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% for the parameters, so the description needed to compensate. It only states 'with filters,' offering no explanation of the eight parameters, how to combine them, or semantics like date ranges. The schema's enums and defaults provide some structure, but the tool description fails to enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Lista suas transacoes com filtros.' clearly states the tool lists transactions and supports filters, using a specific verb and resource. It distinguishes itself from singular getters like get_transaction and from other list tools by resource (transactions). However, it adds little beyond the title and doesn't explicitly highlight scope or contrast with siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as list_orders or list_cashouts. The description merely restates the function without mentioning other tools or exclusion criteria. This is 'no guidance' rather than implied usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and idempotentHint=false, so the agent knows this is a mutating, non-idempotent operation. The description adds no further behavioral context, such as what side effects occur, whether confirmation is needed, or any rate limits. It merely restates the action without enriching the annotation-provided safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence with no unnecessary words. It is front-loaded with the core action. However, it is so sparse that it borders on under-specification, but as a concise statement it performs well.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with five parameters, a destructive action, and no output schema, the description is highly incomplete. It omits any explanation of the payment method, buyer information, or expected result. It provides only the basic action and endpoint, leaving the agent without enough context to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, placing the full burden on the description. The description only reveals that 'token' appears in the endpoint path, but does not explain the meaning or usage of 'method', 'buyerName', 'buyerEmail', or 'buyerPhone'. With five parameters and no parameter semantics provided, the description fails to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Inicia cobrança de payment link' (starts a payment link charge) and identifies the resource as a payment link. It also provides the specific endpoint, which adds precision. However, it does not explicitly differentiate from siblings like get_payment_link, though the verb 'start' implies an action rather than a read.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. There is no mention of prerequisites, context, or exclusions. The description simply states what the tool does without any usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=true, and the description simply states 'creates order', which aligns. However, it adds no additional behavioral context such as side effects, webhook behavior, authorization needs, or rate limits. The only added detail is the endpoint, which is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core action. It is appropriately sized and contains no filler, earning its place with the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (14 parameters, nested objects, no output schema) and minimal description, the agent is left without critical context about parameter behavior, return values, or side effects. This is completely inadequate for making correct invocations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 14 parameters with 0% description coverage, so the description must compensate. It only mentions 'itens' (items) and 'pagamento' (payment), which loosely map to 'items' and 'method', but does not explain the other 12 parameters like customerId, couponCode, shippingAddress, or metadata. This leaves most parameters ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Cria') and resource ('pedido'), and provides the endpoint ('/v1/orders'). It distinguishes from siblings like create_transaction and create_cashout by focusing on orders, though it does not explicitly compare with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as create_transaction or list_orders. There is no mention of prerequisites, exclusions, or preferred scenarios, leaving the agent to infer usage solely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds the API endpoint path, which provides some context, but does not disclose authentication needs, rate limits, or response behavior beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence containing the action, resource, and endpoint. No redundant phrasing, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, and the description does not describe the response format or possible status values. It also omits how to obtain the token and paymentId (e.g., from start_payment_link), though the endpoint gives some context. For a simple status-check tool this is minimally adequate but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain token or paymentId beyond the endpoint template. The names are somewhat self-explanatory, but the meaning of 'session' and the source of these identifiers are left for the agent to infer.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it queries the charge status of a payment link ('Consulta status de cobrança de payment link') and provides the endpoint. It distinguishes from the sibling get_payment_link by focusing on payment/charge status, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus related tools like get_payment_link or get_transaction. It does not mention prerequisites, session context, or how this status check fits into a broader workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds the endpoint (via /v1/orders) but does not disclose any additional behavioral traits like pagination behavior, response format, or filtering constraints 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the operation and endpoint. No redundant or filler wording exists; it is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no parameter descriptions, the description is incomplete for a list operation with pagination and filters. It does not mention response shape, default page size, or how filtering parameters behave, leaving significant gaps for an agent to operate correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description does not compensate by explaining any of the five parameters (page, status, pageSize, customerId, fulfillmentStatus). An agent receives no guidance on valid values, defaults, or how these parameters affect the result.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists orders via the /v1/orders endpoint, using a specific verb and resource. This distinguishes it from sibling tools like get_order (single order) and create_order (creating an order).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as get_order or list_transactions. There is no mention of exclusions, prerequisites, or selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds the merchant scope and the specific endpoint, but does not disclose pagination, filtering, or response behavior. This is modest added value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that gets to the point without unnecessary words. It is appropriately front-loaded with the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters with low schema coverage and no output schema, the description is minimal. It fails to explain that the tool supports filtering, pagination, or any detail about the expected response. It is insufficient for complex usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 22% (only the date fields have descriptions), and the description does not mention any of the 9 parameters (page, type, search, status, etc.). The description does not compensate for the low schema coverage, leaving the agent without semantic guidance for the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Lista' / lists) and the resource (produtos cadastrados do merchant), and specifies the endpoint /v1/products. This distinguishes it from sibling tools like get_product or list_transactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It only states what it does, without exclusions or references to other list tools that might be more appropriate in certain contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive and non-read-only behavior; the description adds no additional behavioral context such as partial vs full update, required authentication, or effect on existing data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that immediately conveys the core action, with no redundant words or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 16 parameters and no output schema, this minimal description is insufficient; it lacks usage context, parameter details, and behavioral expectations for update operations, making it inadequate for complex selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description provides no parameter semantics; field meanings must be inferred solely from names and types in the schema, and the description does not compensate for this gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Atualiza cliente' - updates customer) and the endpoint, distinguishing it from sibling tools like create_customer and get_customer. It is specific about the resource and operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as create or list customers; the description only states the action without context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true and readOnlyHint=false, but the description does not explain what destructive means here (e.g., duplicate webhook delivery). It only mentions the 'completed' webhook type, adding minimal 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no extraneous information. It includes the endpoint and states the action concisely, making it appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a destructiveHint and no output schema, yet the description fails to clarify consequences, success/failure behavior, or when it should be used. This incomplete context is risky for an action with potential side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description does not explain the transactionId parameter beyond showing it in the URL template. No additional semantics are provided; the schema already defines format and required status.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool resends a transaction webhook and provides the specific endpoint path, distinguishing it from sibling tools like get_transaction or simulate_transaction. The verb 'resend' and resource 'webhook' are explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No information about when to use this tool, when not to, or alternatives. It lacks context about prerequisites (e.g., transaction must be completed) or situations where resending a webhook is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive and non-read-only behavior. The description adds the 'sandbox' context, which is useful for understanding that this is a test environment operation. However, it does not explain what the simulation actually does (e.g., changes status, triggers events) or the side effects 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately states the core function and endpoint. There is no redundant information, and it is well-structured for quick parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema and the existence of an enum parameter, the description is incomplete. It does not explain the possible actions ('complete', 'fail', 'reject') or what the tool returns. The overall context is minimal and leaves the agent to infer too much from the schema and tool name.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate, but it does not. It only mentions the endpoint and resource, not the 'id' or 'action' parameters. The schema itself provides enum values for action, but the description adds no additional meaning or context for parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool simulates a cashout in sandbox environment, with the specific endpoint /v1/cashouts/{id}/simulate. It distinguishes from sibling tools like simulate_transaction by explicitly mentioning 'saque' (cashout) and the resource-specific path.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It does not mention that it should be used for testing cashout outcomes or that it differs from simulation of transactions. No exclusions or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate this is not read-only and is open-world, but the description adds no further behavioral context such as side effects, authentication requirements, or error handling. The single sentence merely says it executes a real call, which doesn't disclose potential consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, two-clause sentence, making it very concise and front-loaded with the core purpose. It is minimal but not wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and low parameter documentation, the description fails to explain how to use the generic tool effectively, such as constructing paths, expected response shapes, or authentication behavior. A generic fallback tool for an entire API requires more context to be safely invoked.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% (only 'path' has a description), and the description itself provides no parameter semantics for body, query, method, or requireAuth. The agent is left to infer the meaning of these parameters from their schema types alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: executing a real call to any route of the payments API. It also distinguishes itself from siblings by indicating it is a generic fallback when no dedicated tool exists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly instructs to use this tool when there is no dedicated tool, providing clear usage guidance. However, it does not name specific alternatives or provide explicit exclusions beyond the implied condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context that no merchant ID is needed and that the tool is always connected to the API. However, it incorrectly states that email is optional, while the schema requires email, misrepresenting the required fields. This misleading behavioral guidance lowers the score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at three sentences and front-loads the main action. It contains practical guidance but is marred by the inaccuracy about email being optional.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 15 parameters, no output schema, and no schema descriptions, so the description is the only source of context. It lacks details on most parameters, return values, or constraints, and the email contradiction makes it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must explain the parameters. It only mentions name as the minimum requirement and labels email and others as optional, which is factually wrong for email. No semantics are provided for document, address fields, metadata, or documentType.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action: 'Cria um cliente na API' (creates a customer in the API), with a specific verb and resource. This distinguishes it from sibling tools like get_customer, list_customers, and update_customer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a direct trigger example: if the user says 'cria cliente chamado Jorge', call with name='Jorge'. It also instructs not to ask about API vs panel, indicating it's always the API path. However, it doesn't mention alternatives like update_customer or when not 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.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description only adds the API endpoint, which is a minor behavioral detail. It does not disclose return format, error behaviors, or any constraints beyond what annotations and schema already provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately states the action, resource, and endpoint. It front-loads the core purpose with no wasted words. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID tool with strong annotations, the description is minimally viable. However, there is no output schema, so the description could be expected to mention what it returns (e.g., the customer object). It doesn't, but the tool name and endpoint strongly imply the outcome. This is adequate but with a clear gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description mentions 'por ID' but that only restates the parameter name 'id' and the tool name. The schema already provides format and pattern. The description does not meaningfully compensate for the low schema coverage or add semantic detail beyond what is self-evident.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Obtém cliente por ID' (gets customer by ID) with the specific endpoint /v1/customers/{id}. This is a specific verb+resource+scope that distinguishes it from sibling tools like create_customer, list_customers, and update_customer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied: use when you need a customer by ID. However, there is no explicit guidance on when not to use it or mention of alternatives such as list_customers for collections or update_customer for modifications. The endpoint provides a clear context, but no exclusions or alternatives are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only states the function and endpoint. Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, covering the safety profile. The description adds no additional behavioral context such as auth requirements, rate limits, or error conditions. With annotations present, the bar is lower, but there is still no extra information, so a neutral 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the purpose and endpoint. It is free of extraneous information and every word contributes to the tool's understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only get-by-ID tool with one parameter, the description is minimal but adequate in combination with the schema and annotations. However, it does not state what the response contains or any edge cases, and there is no output schema to fill that gap. Given the low complexity, the description is incomplete but functional.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is one required parameter productId with a comprehensive schema (type, format, pattern) but no description. The description's 'por ID' merely echoes the parameter name and the endpoint, adding no additional semantics beyond what the schema provides. Since schema description coverage is 0%, the description should compensate but does not meaningfully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Obtém produto por ID' (gets product by ID) and specifies the REST endpoint /v1/products/{productId}. This is a specific verb and resource that clearly distinguishes it from sibling tools like list_products or get_order.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when you have a product ID and need a single product, but it does not explicitly exclude alternatives or state when not to use it. Sibling tools like list_products exist, but no comparative guidance is given beyond the inherent difference in function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the agent knows this is a mutating, non-idempotent operation. The description adds 'Valores em centavos' (amounts in cents), which is a formatting detail, and 'agora' (now), but does not disclose further behavioral implications like balance requirements or result information. 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences: the first states the action, the second provides trigger phrases and the cents note. Every phrase serves a purpose, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a financial tool with six parameters and no output schema, the description provides trigger phrases and amount unit but omits return behavior, prerequisites, or error conditions. Annotations give basic safety signals. This is adequate but leaves gaps for an agent to know what happens after creation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explicitly states 'Valores em centavos', clarifying that the amount parameter must be provided in cents, which is not directly stated in the schema. However, the other five parameters (pixKey, externalId, pixKeyType, callbackUrl, payoutAccountId) receive no explanatory text, and schema coverage is 0%. Thus the description only partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'solicita saque' (requests a withdrawal) and provides example user utterances ('solicita um saque de R$X', 'quero sacar R$X') that should trigger it. This distinguishes it from other cashout-related siblings like list_cashouts or cancel_cashout, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent when to call it: when the user says 'solicita um saque de R$X' or 'quero sacar R$X'. This is a direct usage trigger. It doesn't mention exclusions (e.g., when to use simulate_cashout instead), but the examples are actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a mutating, non-destructive, non-idempotent operation. The description adds the critical context that this is a simulation restricted to Sandbox, which is a meaningful behavioral trait beyond the raw hints. However, it doesn't disclose potential side effects of individual actions, so it's not a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that conveys the essential purpose and endpoint without extraneous words. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the core purpose is clear, the description omits explanation of the action enum values and any behavioral consequences of the simulation. With no output schema and no parameter semantics coverage, the agent is left without enough context to correctly invoke the tool for all intended scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides zero parameter information. The endpoint includes {transactionId}, but the critical 'action' parameter is completely unexplained. With 0% schema coverage in the description, the agent must rely solely on the schema's enum list without understanding what each action does.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool simulates a transaction status change in Sandbox, using a specific verb and resource with the exact endpoint. This distinguishes it from sibling tools like safefy_payment_simulate_cashout.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions 'em Sandbox', providing clear context that this tool is for simulated/testing environments. It doesn't spell out exclusions or alternatives, but the purpose is unambiguous for choosing this tool over production-affecting ones.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is clear. The description adds the endpoint but no extra behavioral context such as error handling or authentication requirements. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence in Portuguese, front-loaded with the action and resource. It contains no unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only get-by-ID tool, the description is mostly complete: it states the action and endpoint. It doesn't describe the return value or error cases, but annotations and the tool's simplicity make it sufficient for correct invocation. A bit more detail on the response would be beneficial, but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It says 'por ID' and the endpoint includes {id}, clarifying the single parameter's role. The schema already specifies UUID format, so the description adds moderate value but doesn't go beyond the obvious.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Obtém saque por ID via /v1/cashouts/{id}' clearly states the action (get) and resource (cashout) with a specific identifier. It distinguishes from sibling tools like list_cashouts and create_cashout by focusing on retrieval by ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (you need an ID to fetch a single cashout) but provides no explicit guidance about when to use this versus list_cashouts or cancel_cashout. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive. The description adds the endpoint and the fact that the link is public, but does not explain response contents, error behavior, or rate limits. With annotations covering the safety profile, the added context is modest.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence in Portuguese, front-loaded with the key action and resource. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple GET-by-token tool, the description plus annotations cover purpose, auth (public), and safety. It does not describe the return payload, but the simplicity of the tool makes this a minor gap; still, no output schema means some detail would be useful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description explicitly shows token as a path parameter via /v1/payment-links/{token}, making its role clear. For a single parameter, this is sufficient compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb 'Consulta' (query) and resource 'link de pagamento público', identifying exactly what it retrieves. The API path /v1/payment-links/{token} distinguishes it from siblings like get_payment_link_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not state when to use this over the sibling get_payment_link_status, when the token is available, or any prerequisites or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate mutating (readOnlyHint=false), idempotent (idempotentHint=true), and non-destructive (destructiveHint=false) behavior. The description adds the concrete side effect of updating the access token, which is useful context. However, it does not disclose failure modes, whether old tokens are invalidated, or any rate limits. 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of a single, front-loaded sentence with no filler or redundant information. It communicates the core action efficiently, and the structure is appropriate for a simple tool of this scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters, but the description does not explain when authentication is required (e.g., before other API calls) or what the result looks like (no output schema). For a basic re-authentication action, the description is minimally adequate but leaves the agent without guidance on its role in the broader workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is trivially complete. There is no parameter information to explain, and the baseline for zero-parameter tools is 4. The description adds no unnecessary parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Faz login novamente na API e atualiza o token de acesso' (re-logs into the API and updates the access token). This is a specific verb+resource combination that is distinct from all sibling tools, which focus on data operations like listing, getting, or creating.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use guidance is provided. The word 'novamente' (again) implies re-authentication but does not specify conditions such as token expiry or contrast with alternatives like configure_credentials. Usage is implied rather than explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag this as destructive/non-idempotent; the description adds useful post-action behavior (display pixCopyPaste for PIX, boletoDigitableLine for boleto) and notes that values are in cents. It does not contradict annotations, and the added context supplements the structured hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise and front-loaded with the core purpose, followed by explicit directives and post-creation reminders. Minor redundancy exists ('na API agora' and 'voce JA ESTA conectado a API') but overall it earns its space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 18 parameters and no output schema, the description covers the primary PIX/boleto flows well but omits card-specific details, optional parameter behavior, error handling, and the broader return structure beyond two fields. It is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must explain parameters, but it only covers method and amount with examples. The remaining 16 parameters (cardToken, customerId, installments, etc.) are completely undocumented, leaving the agent without guidance for optional but important fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a PIX, boleto, or card charge directly via the API, distinguishing it from sibling tools like simulate_transaction or create_cashout. It gives concrete examples ('gera um PIX de R$50') that map user requests to tool invocation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-not guidance ('NAO pergunte via API ou painel') and maps natural language utterances to specific method/amount values. It does not name alternatives like simulate_transaction for testing, 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false, so the description does not need to restate safety. It adds the endpoint and pagination context, but does not disclose any additional behavioral traits such as filtering options or default ordering, making it 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, front-loading the core action and resource. It earns its place by adding endpoint and pagination context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, and the description only says it lists cashouts with pagination. It does not mention the available filters (status, startDate, endDate) or what fields are returned, leaving some gaps. However, the rich annotations and self-explanatory schema parameters compensate partially, making it minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 40%, with date fields documented in the schema. The description mentions pagination, which aligns with page/pageSize, but does not explain the status filter or date range semantics beyond the schema. Since the schema covers some details and the remaining params are self-explanatory, a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Lista') and resource ('saques'), and adds pagination detail and the API endpoint, clearly distinguishing it from get_cashout, create_cashout, and other siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates when to use this tool: when you need a list of cashouts with pagination. However, it does not mention alternatives or when not to use it, such as for retrieving a single cashout, so it misses explicit exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare destructiveHint=true and readOnlyHint=false, so the description doesn't need to repeat that. It adds the specific API path but does not disclose additional behavioral details such as irreversibility or permissions. The endpoint reference is modest extra context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that is front-loaded with the action and endpoint. Every word earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 1-parameter destructive operation with accurate annotations, the description and endpoint are mostly sufficient. It lacks return/error behavior details, but the low complexity and annotation coverage make the tool adequately specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description compensates by showing the ID in the URL template: '/v1/cashouts/{id}/cancel'. This clarifies that 'id' is the cashout identifier, adding meaning beyond the generic schema property name and format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Cancela saque') and the resource (cashout) with an explicit API endpoint. It distinguishes from sibling tools like create_cashout, get_cashout, and simulate_cashout by specifying the cancel operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied by the action and endpoint, but there is no explicit guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. It is not misleading, but it lacks direct usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds the endpoint path but doesn't disclose additional behavioral traits such as error handling, required authentication, or response format. It is minimally adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, zero wasted words. The endpoint path adds useful context without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID tool with strong annotations and a self-explanatory parameter, the description is sufficient. It doesn't mention return format, but no output schema exists and the operation is straightforward.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides full details for orderId (UUID format with pattern). The description adds no extra meaning beyond 'by ID', so it doesn't compensate for the 0% schema description coverage, but for a single obvious parameter, this is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves an order by ID via a specific endpoint, distinguishing it from list/create/update operations and other get_* tools like get_transaction or get_customer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: use this when you need a single order by its ID. It doesn't explicitly mention alternatives or exclusions, but the verb+resource pattern makes the intended usage obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the endpoint path but no extra behavioral context like error handling, return format, or pagination. This matches the baseline for a simple read operation with good annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately states the operation and the endpoint. There is zero wasted verbiage, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID operation with a single parameter and good annotations, the description is largely sufficient. It includes the endpoint and the parameter. The lack of an output schema means return values are not explicitly described, but for a retrieval tool this is implied. Slight gap: it doesn't mention that the transaction must exist or that a 404 may occur, but this is minor given the simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter, transactionId, with type string, format uuid, and a pattern. Schema description coverage is 0%, but the parameter name is self-explanatory, and the description's 'por ID' reinforces its meaning. The endpoint path also clarifies it is the path parameter. This is adequate compensation for the lack of schema descriptions on a single, obvious parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a transaction by ID, using a specific verb ('Obtém' = Gets) and resource ('transação'). It also includes the endpoint path, and the name itself distinguishes it from sibling tools like list_transactions and create_transaction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool: when you have a transaction ID and need to retrieve that specific transaction. It doesn't explicitly state when not to use it or name alternatives, but the 'por ID' and the contrast with list_transactions make the usage context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds no extra behavioral context (e.g., response format, limitations). It is consistent but adds little 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences convey the essential purpose and usage condition without any filler. Perfectly concise for a simple informational tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only guide tool with comprehensive annotations, the description is sufficient. It identifies when to use, what it shows, and the main variants. The lack of an output schema or detailed parameter explanation is minor given the tool's simplicity and the schema's enums.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not mention the 'mode' or 'language' parameters at all. Although the enums are self-explanatory (sdk_node/direct_api, various languages), the description fails to compensate for the missing schema documentation, leaving the agent to infer parameter meaning solely from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool shows a step-by-step integration guide, with specific options (SDK Node or direct API). It distinguishes itself from siblings like get_payment_link or create_transaction, which are operational tools rather than documentation/help tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states to use only when the user asks for help integrating, providing a clear usage condition. Although it doesn't name alternatives, the 'use only when' phrase effectively excludes other contexts, making the guideline unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the environment is automatically detected from the key prefix (pk_sandbox_ or pk_production_) and that environment/baseUrl are configured automatically. This goes beyond the annotations, which only indicate readOnlyHint=false and idempotentHint=false, adding valuable 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the purpose, and includes clear do/don't instructions. Every sentence earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple credential configuration tool, the description covers the essential behavior: what it does, which parameters to ask for, and auto-detection of the environment. It doesn't mention the authenticateNow parameter's effect or potential post-configuration actions, but given the tool's simplicity and the annotations, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for publicKey and secretKey with prefix examples, and the description essentially reinforces this. However, authenticateNow has no description in the schema and is not addressed in the tool description, leaving a gap. The description does clarify the auto-detection mechanism, which adds some value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Configura as credenciais da conta' (Configures account credentials). It uses a specific verb and resource, and distinguishes itself from sibling tools like get_configuration and authenticate by focusing on credential setup. The explicit mention of publicKey and secretKey further clarifies the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: it tells the agent to ask only for publicKey and secretKey, and explicitly says not to ask for environment or baseUrl. While it doesn't name alternative tools, the context implies this is the initial configuration step, and the do/don't guidance is useful for correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnlyHint, idempotentHint, non-destructive). The description adds value by noting the balance is 'atual' (current) and gives trigger phrases, but doesn't describe edge cases like auth requirements or rate limits. This is acceptable given the strong annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with appended examples, front-loaded with the core action and result. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, zero-parameter, read-only balance tool with strong annotations, the description covers what it returns (balance) and when to use it. It could specify currency or formatting, but the basic context is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description has no parameters to explain. The schema is empty and the description adds no parameter info, but the 0-parameter baseline is 4, and there is nothing needed beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Consulta e retorna') with a clear resource ('saldo atual'), and provides example user queries. This unambiguously identifies the tool's purpose and differentiates it from siblings that handle transactions, customers, products, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to invoke the tool: 'Chame imediatamente quando o usuario perguntar...' with concrete query examples. Though alternatives are not mentioned, no sibling tool serves a similar purpose, so the guidance is complete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld, and non-destructive. The description adds sequencing context (call before any operation) and the purpose of the check (to know whether to ask for credentials), which enriches behavioral understanding 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences with no fluff. Every word contributes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter status check tool with thorough annotations, the description fully explains what it does and when to call it. It even indicates the output's purpose, making it self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline is 4. The description adds no parameter information, but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks whether credentials are configured, using a specific verb ('Verifica') and resource ('credenciais'). It distinguishes itself from sibling tools like configure_credentials and authenticate by focusing on checking configuration status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to call before any operation to determine if credentials need to be requested, providing clear situational guidance. It doesn't name alternatives but makes the use case unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the annotations: 'Nao executa operacoes financeiras, apenas informa capacidades' (Does not execute financial operations, only informs capabilities). While annotations already indicate readOnlyHint and non-destructive, the description clarifies the tool's role as an informational listing, which is useful for the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose, and uses explicit warnings. No unnecessary words or redundancy, earning the highest score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameterless, read-only discovery tool, the description fully covers what it does, what it doesn't do, and when not to use it. No output schema is present, but the return value is implied to be a list of capabilities. Complete for this context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty (100% coverage). The description does not need to explain parameters. Baseline for 0 params is 4, as there is nothing to clarify.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Mostra tudo que este MCP consegue fazer' (Shows everything this MCP can do), clearly establishing it as a capabilities listing tool. This distinguishes it from sibling execution tools like create_transaction or create_customer, which perform concrete financial actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: 'NAO use este tool quando o usuario pedir uma acao concreta (criar cliente, PIX, etc.) — nesses casos va direto para a tool de execucao' (Do not use this tool when the user asks for a concrete action—go directly to the execution tool). This clearly states when NOT to use and points to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Safefy-Pay/safefy-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server