ribbo-mcp
Server Quality Checklist
Latest release: v1.0.0
- Disambiguation5/5
Each tool targets a distinct resource and action, with clear boundaries between similar operations like get_payment_link (subscription invoice) and get_order_payment_link (one-off Pix order). Detailed descriptions further prevent ambiguity.
Naming Consistency5/5All tool names follow a consistent verb_noun pattern in snake_case (e.g., list_subscriptions, create_renewal_link, refund_payment). The few compound names like get_gateway_events still fit the pattern with nested nouns.
Tool Count4/524 tools is on the higher end for a single server, but the breadth is justified by the comprehensive billing domain (subscriptions, payments, customers, links). It remains manageable and each tool has a specific purpose.
Completeness3/5The core subscription and payment lifecycles are well covered, but there are notable gaps: no get_customer or create_customer, no apply_coupon or add_coupon, no direct payment method management beyond a link, and no way to list all payments for a subscription. These create dead ends for some workflows.
Average 3.3/5 across 24 of 24 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
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?
With no annotations, the description must carry the burden of behavioral disclosure. It mentions write scope and the 7-day expiration, but does not explain side effects (e.g., changes to subscription state), required permissions, idempotency, or error conditions. This 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, with no wasted words. It could be expanded with parameter hints, but as is, it is efficient.
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?
For a write tool with three parameters and no output schema, the description is far too sparse. It omits parameter semantics, return value, and any preconditions, making it insufficient for an agent to invoke correctly without external knowledge.
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% and the description provides no explanation for subscription_id, offer_slug, or price_cents. The agent gets no cue about what these values mean or how to populate them.
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 states a clear action: generate a standalone renewal link, with an expiry detail. The word 'avulsa' (standalone) helps distinguish it from campaign links, though it doesn't explicitly name sibling tools.
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 like create_payment_method_link, get_renewal_campaign_link, or get_payment_link. The context in which this link is appropriate is not stated.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only mentions '(cursor)', which suggests pagination, but lacks details on how the cursor works, whether read-only, response format, or side effects. The description does not disclose behavior beyond the minimal function.
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 concise sentence, which is efficient, but it is too sparse to be truly useful. It front-loads the main action but omits essential context about parameters and pagination, making it arguably under-specified rather than deliberately concise. It is not poorly structured, but it doesn't sell 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?
Given there is no output schema and no annotations, the description is expected to explain the return value, pagination mechanics, and error handling. It only hints at a cursor and lists links, leaving the agent without enough context to correctly invoke the tool, especially for the 'after' and 'limit' parameters and the expected response structure.
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 covers 0% of parameters in the description, and the description itself does not explain campaign_id, after, or limit. It only says 'links de uma campanha' which vaguely hints at campaign_id but provides no detail. With no parameter explanations, the description adds no value beyond the schema and fails to compensate for the missing schema coverage.
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 todos os links de uma campanha de renovação (cursor)' clearly states the action (list all links) and the resource (renewal campaign links), with a cursor hinting at pagination. The plural 'links' distinguishes it from the singular sibling get_renewal_campaign_link, and the action differs from create_renewal_link, so the purpose is unambiguous.
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. The description does not mention exclusions or alternatives, and while the name implies a listing operation, it doesn't explicitly tell the agent to use get_renewal_campaign_link for a single link or how to handle pagination. No usage context is 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?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states that it queues a charge and is a write operation, but does not mention side effects (e.g., charging the card, potential failures), idempotency, rate limits, or authentication requirements. The reference to '202' is a hint but not a substitute for explicit behavioral transparency.
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, concise sentence that front-loads the core action and scope. It avoids unnecessary fluff and efficiently communicates the essence. However, it lacks any structural segmentation (e.g., separate usage notes) that might otherwise enhance readability, but this is not a major flaw given the brevity.
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?
This is a mutating tool with a side effect (charging a card), and it has no output schema and no annotations. The description is drastically incomplete: it does not mention what response the agent will receive, what errors can occur (e.g., card declined, subscription invalid), whether the operation is asynchronous, or any preconditions. An agent cannot safely invoke it without significant guesswork.
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 was expected to elaborate on the parameter. It only refers to 'subscription' contextually but does not explain what subscription_id is, its format, or any constraints. The agent has to infer that this is likely a subscription identifier from the name and the description's mention of 'assinatura', but no additional meaning is provided.
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 states a specific action ('queue an immediate charge') on a specific resource ('the saved card of the subscription') and explicitly notes the write scope. It is distinguishable from sibling read tools and other mutations, though it does not name alternatives. The mention of HTTP 202 adds a subtle hint about the response behavior.
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, no prerequisites, and no conditions that would trigger its use. An agent cannot determine from the description whether it is appropriate for a given scenario, such as whether the subscription must be active or whether a pending charge already exists.
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?
No annotations are provided, so the description bears the full burden of behavioral disclosure. It does disclose that the response includes a breakdown into plan/bump/interest, which is useful. However, it does not mention that the operation is read-only, what happens if the payment_id is invalid, or any error scenarios. The read-only nature is implied by 'Detalhe' but not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately conveys the primary purpose and the distinctive breakdown. It contains no fluff or unnecessary details, though it is arguably terse given the lack of parameter and usage guidance (which is penalized elsewhere).
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?
This is a simple tool with one parameter and no output schema, so the description must fully explain what it retrieves and how to use it. It mentions breakdown items but does not clarify that it returns a single payment, how to obtain payment_id, or what happens on errors or missing data. The description is incomplete for an agent to confidently invoke 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?
The schema has zero description coverage (0%), and the tool description does not mention the sole parameter payment_id at all. The agent receives no guidance on what payment_id represents or how to obtain it, making it impossible to use the parameter correctly based on the provided text. The description adds no meaning beyond the bare schema type.
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 states a clear purpose: 'Detalhe de um pagamento' (payment details) with a specific breakdown into items (plan/bump/interest). This distinguishes it from list-type siblings like get_customer_payments by specifying the granularity of the detail, though it does not explicitly say it retrieves a single payment vs a list.
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 over alternatives such as get_customer_payments or get_payment_link. No mention of prerequisites, conditions, or exclusions, leaving the agent to infer usage from the name alone.
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?
No annotations are provided, so the description must carry the full behavioral disclosure burden. It mentions gateway synchronization, which is a useful side effect, but it does not address reversibility, authentication requirements, potential side effects beyond the gateway, or any error conditions. For a write operation, this is minimal disclosure and well below what is needed without annotations.
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 extremely concise – a single sentence with no fluff. This is structurally efficient, but it borders on under-specification. While the content is front-loaded, the brevity sacrifices essential information, similar to the 'process' example that scored 2 for being under-specified. This one is slightly more informative, so a 3 is appropriate – it is concise but not complete enough to be highly effective.
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?
This is a simple tool with only two parameters, but the description omits critical context: what 'external_id' refers to, whether the email update is ID-based, what the success/error responses look like, or any validation rules. Since there is no output schema and no annotations, the description should compensate, but it does not. Even for a minimal tool, the agent lacks enough to call it reliably.
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% – the schema only lists parameter names and types with no explanations. The description adds absolutely no information about the semantics of 'external_id' or 'email', their expected formats, relationships, or constraints. With zero parameter guidance from either source, this dimension is critically deficient.
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 ('Atualiza') and resource ('e-mail de um cliente'), and adds the gateway sync detail. It clearly distinguishes itself from the sibling 'update_customer' by focusing on email updates, and the write scope hint reinforces the operation type. This meets the 5-point criterion of a specific verb+resource with sibling differentiation.
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 like 'update_customer' or other write operations. It only notes 'Escopo write', which hints at permissions but does not explain prerequisites, contexts, or exclusions. There is no explicit 'when to use' or 'when not to use' information, so the agent must infer usage from the name alone.
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?
No annotations are provided, so the description carries the full burden. It discloses that this is a write operation (Escopo write) and usefully describes the 422 requires_confirmation=runway edge case with its remedy (confirm_runway=true), which is exactly the kind of behavioral trap an agent needs. However, it omits auth/permission requirements, irreversibility, and what happens on failure — leaving partial coverage for a mutating tool.
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?
Two tight sentences with the core action front-loaded, followed by the critical edge case. No wasted words; the only minor loss is that the write-scope disclosure could have been omitted or merged without lowering clarity.
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 5 parameters, zero schema description coverage, no output schema, and no annotations, the description is insufficiently complete. It covers the purpose and the most important error flow but leaves the revoke parameter (a meaningful enum choice for refunds) and general failure/success behavior undocumented, so an agent cannot fully reason about all valid 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?
Schema description coverage is 0%, so the description must compensate. It adds meaning only to confirm_runway (via the 422 re-send with confirm_runway=true instruction). Other parameters — payment_id, amount_cents, reason, and especially the revoke enum (none/subscription/grant) — are left entirely unexplained, so compensation is incomplete.
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 states a specific verb (Estorna/refunds) and resource (pagamento/payment), and adds the total/partial distinction. It clearly differs from read siblings like get_payment, though it doesn't explicitly name a sibling it is not, so it stops short of a 5.
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, no prerequisites, and no exclusions. The only close guidance is the 422 retry flow, which is a conditional edge-case instruction rather than a general usage guideline for selecting this tool over siblings.
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?
With no annotations, the description carries the full burden. It discloses idempotency, terminality, and the 422 error condition for payable Pix QR, plus 'Escopo write' (write scope). This is significant behavioral context, though side effects beyond cancellation (e.g., billing impact) are not mentioned.
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, compact sentence that conveys the action, key properties (terminal, idempotent), a critical error condition, and scope. No wasted words, and the most important 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?
The description covers the core behavior and a key error condition, but is incomplete for an agent: it does not explain the reason parameter, nor does it describe expected responses or side effects beyond cancellation. Given the lack of annotations and output schema, more context is needed for safe invocation.
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 documents subscription_id (required) and reason (optional), but the description does not mention either. Since schema description coverage is 0%, the description fails to add any meaning to the parameters—particularly the optional reason is left entirely undocumented.
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 action ('Cancela') and resource ('assinatura'), and adds that it is terminal and idempotent. It does not explicitly name a sibling to contrast with, but the action is unambiguous against the read-only sibling tools.
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 like change_plan or cancel_plan_change. The description mentions terminality but does not contextualize when cancellation is appropriate or when another tool should be used instead.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds the detail that the tool returns subscriptions 'of any status', which hints at scope, but it does not mention potential side effects, ordering, pagination, or output format. For a read-only get operation this is a minimal disclosure, but the lack of annotations makes this a significant gap.
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, compact sentence that delivers the essential information without any superfluous words. It is front-loaded with the primary purpose and follows with the parameter usage, achieving maximum clarity with minimal length.
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?
Given the tool's simplicity (one parameter, no output schema), the description is reasonably complete: it states what the operation does and the required input. However, it does not describe the structure of the returned data (e.g., array of subscription objects) or any edge cases like empty results or pagination, which an agent might need for correct handling.
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 schema describes external_id only as a string with no further meaning. The description compensates by clarifying it is the customer's external ID, which is essential for correct invocation. With 0% schema coverage, the description effectively explains the sole parameter, though it could add format constraints if applicable.
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 function with a specific verb (get) and resource (customer subscriptions), and adds scope detail ('any status') and the required identifier (external_id). It is unambiguous about what the tool returns, though it does not explicitly differentiate it from siblings like list_subscriptions.
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 like list_subscriptions or get_subscription. It only states what the tool does, but never mentions conditions, exclusions, or scenarios where a different tool would be more 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?
With no annotations, the description must disclose behavior. It mentions that a 409 is returned if no open invoice exists, which is valuable. However, it does not describe the success response format, authentication requirements, or any side effects, leaving a gap in behavioral transparency.
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 an efficient single sentence plus an error code note, with no redundant wording. All information is relevant and front-loaded, making it easy to parse.
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 tool with a single parameter and no output schema, the description covers the core resource and even the error case. While it does not explicitly state the success return (the link itself is implied by the description), it is sufficiently complete for the tool's simplicity.
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 coverage is 0%, so the description should explain the parameter. It only implicitly refers to subscription_id as 'de uma assinatura' (of a subscription), giving minimal context. It does not clarify the format, required value, or any constraints beyond it being a subscription ID, so the parameter semantics are under-addressed.
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 states it provides a public payment link for the open invoice of a subscription, clearly identifying the resource and purpose. However, it does not explicitly differentiate from sibling tools like get_order_payment_link, which may also deal with payment links. The 409 error mention adds a specific behavioral hint that aids understanding.
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. The description only specifies the condition (open invoice) but does not mention when not to use it or direct to sibling tools for other cases, leaving the agent to infer selection from the name and sibling list.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it is a write operation and lists non-editable fields, which is useful, but it omits any details on side effects, return payload, authentication requirements, or whether the update is partial or full replacement. For a mutation tool, this leaves significant gaps about what happens when the tool is called.
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, compact sentence that front-loads the verb, resource, and key field list, then states the non-editable exclusions. There is no fluff, repetition, or unnecessary detail. Every word earns its place, making it highly efficient for an agent to parse.
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 mutation tool with no annotations and no output schema, the description is notably incomplete. It does not explain what the tool returns on success or failure, whether it is a partial update (PATCH-like) or full replacement, any required permissions or authentication, or the purpose of the mysterious 'doc' field. An agent calling this tool would have to guess at expected response and error behavior. The description covers the basic operation but leaves too many operational details unstated.
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 does add meaning by identifying which fields are updatable (name, email, phone) and clarifying that external_id is used as an identifier and not meant to be edited, even though it is required in the schema. However, it references 'doc' which is not present in the schema, creating potential confusion, and it does not provide formats, constraints, or optionality explanations. Partial 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 clearly states the action (Atualiza = updates) and resource (cliente = customer), lists the specific fields (nome/email/telefone), and explicitly declares what is not editable (doc and external_id). This distinguishes it from the sibling update_customer_email, which is narrowly focused on email only. Purpose is unambiguous and well-scoped.
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 explicit guidance on when to use this tool versus alternatives. It mentions 'Escopo write' but that is generic to all mutation tools and does not help an agent decide between update_customer and update_customer_email or other write tools. There is no mention of conditions, exclusions, or preferred scenarios. The usage context is entirely implicit from the purpose.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only mentions pagination by cursor, which is a key trait, but it does not describe what happens when no payments exist, the response format, or any default behavior (e.g., default limit). For a read-only list operation, this is minimal but misses important runtime details like cursor handling semantics.
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, compact sentence that states the core purpose and the pagination trait. It is front-loaded with the most important information and contains no filler. Every word earns its place, making it highly efficient.
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 there is no output schema, no annotations, and three parameters with zero schema descriptions, the description is too sparse to fully equip an agent. It lacks details on cursor semantics, output shape, and expected behavior. An agent would likely have questions about pagination flow and what fields are returned. This is below the minimum viable completeness for a tool of this complexity.
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 must explain parameter meanings. It does not explicitly tie 'after' to the cursor, nor does it explain 'limit' or the purpose of 'external_id' beyond what the name implies. The only hint is 'paginado por cursor', which indirectly suggests 'after' is a cursor token. This is insufficient given how much responsibility falls on the description.
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 returns a customer's payment history ('Histórico de pagamentos de um cliente') and specifies it covers recurring and one-off payments, plus pagination. This distinguishes it from siblings like get_payment (single payment) and get_customer_subscriptions (subscriptions). The verb+resource is precise and unambiguous.
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 when to use this tool (to fetch a full payment history) but does not explicitly explain when not to use it or name alternatives. It does not contrast with get_payment or other list tools, so an agent must infer the appropriate context. No explicit routing to a sibling tool is 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?
With no annotations provided, the description must disclose behavior itself. It mentions the output (code/link, reward, progress) but does not state whether the operation is read-only, what happens if both parameters are provided or none, or error behavior. Minimal disclosure beyond the basic output.
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, compact sentence with no filler. It front-loads the main output and immediately follows with the key usage instruction. 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 lookup tool, the description covers the core return information and the required identifier. However, it lacks details on behavior when parameters are missing or both provided, error handling, and any side effects. With no output schema or annotations, this is an acceptable but not thorough coverage.
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 adds meaning by clarifying that external_id and email are alternative identifiers (OU), which is not in the schema. However, it does not explain precedence, consequences of providing both, or details about the parameters' formats. Since schema coverage is 0%, it partially compensates but not fully.
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 states that the tool returns a customer's referral code/link plus reward and progress, using a specific verb (get, implied by name) and resource. It is clear enough to distinguish from siblings like get_renewal_campaign_link, 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description instructs to provide external_id or email, indicating a required input condition, but does not specify when to use this tool versus other get tools or any exclusions. Usage context is implied but not made explicit.
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?
No annotations are provided, so the description carries the full burden. It mentions that the tool returns the current status regardless of the subscription's status ('any status'), which adds useful behavioral context. However, it does not disclose potential error handling, pagination, or any side effects, though it is a simple GET 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?
The description is two sentences with no waste. It leads with the core purpose and then adds a specific use case. Every word contributes to understanding the tool's function.
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 tool with a single parameter and no output schema, the description is sufficient to understand the basic purpose, but it lacks explicit parameter documentation and any mention of error behavior. The use case helps, but the absence of guidance on how to provide the subscription_id and what to expect as output leaves some 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?
The schema has 0% coverage for the subscription_id parameter, and the description does not mention this parameter at all. The agent only knows it is a required string, but the description does not clarify that it should be the subscription identifier, leaving interpretation to the tool name. Since the description should compensate for the schema gap, this is inadequate.
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 retrieves the current status of a single subscription, with the qualifier 'any status' to indicate it works across all subscription states. This differentiates it from sibling listing tools like list_subscriptions or get_customer_subscriptions, though it doesn't name them explicitly.
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 provides a concrete use case ('reconciling a lost webhook') which implies when to use it, but does not explicitly state when not to use it or contrast it with alternatives. The singular 'one subscription' implicitly suggests using it when you have a specific subscription_id, but the guidance is not fully developed.
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?
With no annotations provided, the description carries the full burden. It discloses the read-style operation (list), filtering behavior, and pagination mechanism (cursor), but does not explicitly state that it is read-only, mention authentication requirements, or describe the response format. It gives useful behavioral hints but omits some key expectations.
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, compact sentence that immediately states the primary purpose and then lists the optional filters. It is front-loaded and free of fluff, making it easy for an agent to scan and understand quickly.
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 straightforward list tool, the description covers the essential functionality: data to list, filters, and pagination. However, it lacks explicit read-only confirmation, and without an output schema, the agent must infer the return shape. Given the low schema coverage and no annotations, a bit more detail (e.g., response format, auth) would be expected.
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 only 25% (only 'status' has a description). The description compensates by naming all four parameters (status, offer_slug, limit, after) and adding context for pagination ('cursor'). However, it only provides an example for status (CSV) and does not clarify the cursor format or offer_slug syntax beyond what the schema implies.
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 action (list) and resource (tenant subscriptions). The phrase 'do tenant' distinguishes it from sibling tools like get_customer_subscriptions, though it doesn't explicitly name the sibling or the distinction. The optional filters (status, offer_slug, pagination) further specify scope.
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 vs alternatives such as get_customer_subscriptions or get_subscription. Sibling tools offer similar listing capabilities (e.g., get_customer_subscriptions) but the description provides no selection criteria, leaving the agent to infer.
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?
With no annotations, the description discloses the read-only nature (a timeline) and lists event types, which helps the agent understand what data to expect. However, it omits details like ordering, pagination, time range, or whether pending events are included. It adds some behavioral context but not comprehensive.
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 with zero waste. It immediately communicates the core purpose and event types, making it highly efficient.
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?
Given the simplicity (1 parameter, no output schema), the description is adequate but not complete. It explains what events are returned but lacks details about the response structure, ordering, or edge cases. Without annotations or an output schema, a bit more guidance (e.g., 'returns a list of events, most recent first') would improve completeness.
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 elaborate on the 'subscription_id' parameter beyond its name. It does not provide examples, format, or constraints. The parameter name is self-explanatory, but the description adds no value, failing to compensate for the missing schema 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 states a specific verb ('timeline of gateway responses') and a clear resource ('subscription'), listing distinct event types (approval, refusal, refund, chargeback). It clearly differentiates from siblings like get_subscription or list_subscriptions by focusing on event history.
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. While the purpose implies it for event history, it does not explicitly state when not to use it or mention sibling tools like get_subscription for current status. The agent must infer usage from the name and 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?
With no annotations provided, the description carries the full disclosure burden. It does reveal a meaningful behavioral trait — the 409 error when there is no pending Pix to reopen — and implies the 'pending' status requirement. But it does not state the return format (presumably a link/URL), authentication needs, or side effects, so disclosure is partial despite the good error signal.
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?
Two compact sentences with the core purpose front-loaded in the first clause and the key error behavior appended second. No filler or repetition. Slightly dense phrasing in Portuguese ('compra avulsa OU adiantamento de renovação') but economical overall.
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 (one required param, no output schema, no nested objects), so the definition is reasonably complete: purpose and error case are covered. However, it omits what the successful response returns (the payment link itself) and any precondition/prerequisite notes, leaving a small but real gap for a tool that an agent must invoke to obtain a link.
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 for the single order_id parameter. The description implies order_id refers to the pending order whose Pix needs re-access, but it never explains the parameter's meaning, format, or constraints directly. The compensation is minimal and leaves most parameter semantics to the parameter name itself.
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 states a clear verb+resource — 'Link de re-acesso ao Pix de um pedido pendente' — and gives the specific domain (Pix payment re-access for pending orders, standalone purchase or renewal advance) and the '2ª via' framing. It distinguishes itself from the generic sibling get_payment_link by scoping to pending Pix and mentioning the 409 behavior. It stops short of naming direct sibling comparisons, so it's clear but not maximally differentiated.
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 purpose clause 'para reenviar ao cliente' implies the usage context (resend a payment link to a customer), and the '409 se não há Pix pendente' acts as an implicit condition for when the call will fail. However, there is no explicit when-to-use/when-not-to-use guidance and no named alternative among the many get_*/create_* siblings, leaving selection partly to inference.
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?
No annotations are provided, so the description carries the full burden. It does disclose that only future cycles are affected ('ciclos futuros') and states the write scope, which conveys mutation. However, it omits potential failure modes, idempotency, or reversibility, though these are less critical for a simple removal 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?
The description is extremely concise: a single sentence of 10 words followed by a two-word scope tag. It is front-loaded with the action and resource, with no filler or repetition.
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 one-parameter mutation tool with no output schema, the description covers the essential behavior (what is removed and from which period) but omits any indication of the return value or success/failure signaling. Given the simplicity, this is adequate but not exhaustive.
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 must compensate for parameter meaning. It only indirectly implies that a subscription must be identified via 'de uma assinatura', without explicitly naming or describing the subscription_id parameter. The parameter is self-evident, but the description adds minimal 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 uses a specific verb ('Remove') with a clear resource ('o cupom dos ciclos futuros de uma assinatura'), making the action and scope unambiguous. It is distinct from sibling tools, none of which target coupons, so no confusion exists.
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 this tool should be used versus alternatives, prerequisites (e.g., subscription must exist, coupon must be active), or conditions under which it should not be used. The description simply states the action.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does reveal that the operation is 'Escopo write' (write scope) and that it is idempotent per (customer, offer), which are useful behavioral traits. However, it does not explain permissions, reversibility, response behavior, or error conditions. For a write tool with zero annotations, this is a moderate disclosure, more than just 'creates', but still lacking richer detail. A 3 is justified.
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 with no filler. It front-loads the primary purpose and then adds the key constraint of idempotency and write scope. Every word 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?
With 10 parameters, only 2 required, no output schema, and no annotations, this is a complex write operation. The description is brief and does not clarify important aspects like how to choose between Pix manual and migration flows, which parameters are essential (such as external_id and offer_slug), the role of current_period_end for migration, or any side effects. It leaves the agent to infer too much from the schema. A 2 is appropriate for this incompleteness.
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 only 20% description coverage, with only 'phone' and 'current_period_end' having descriptions. The overall description mentions 'cliente' and 'oferta' in the idempotency note, but does not map them to specific parameter names (external_id, offer_slug). It provides no guidance on required fields, the meaning of collection_method, coupon_code, or activation. The description adds essentially no parameter semantics beyond the schema, failing to compensate for the low coverage. Thus a 1.
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 precisely what the tool does: 'Cria uma assinatura SEM cartão (Pix manual ou migração)'. It specifies the resource (assinatura/subscription) and the mode (without card, via Pix manual or migration), and distinguishes it from sibling tools like get_subscription, cancel_subscription, and change_plan. It is a specific verb+resource statement with clear 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 gives clear context: use this tool to create a subscription without a card, either via manual Pix or migration. It also mentions idempotency by (customer, offer), which implies when the tool can be safely re-invoked. However, it does not explicitly state when to use an alternative (e.g., card-based subscription creation), but that is not among the siblings. There are no exclusions or alternatives named, so a 4 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?
With no annotations, the description carries the full burden. It discloses that the operation is create-or-get and idempotent, and requires write scope. However, it does not mention the return value (the link) or potential side effects beyond creation, which is a notable gap for a mutating 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?
The description is extremely concise with no filler. It front-loads the primary purpose and key characteristics (idempotent, write scope) in a single sentence. Every phrase 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?
Given the tool's complexity (create-or-get mutation), the lack of an output schema, and zero annotation coverage, the description is incomplete. It omits what the tool returns (the link) and does not clarify parameter semantics, which an agent needs to call it 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 0% and the description does not explain the two parameters. It only gives general context that the link is for a customer in a campaign, leaving campaign_id and external_id ambiguous. This is insufficient for an agent to know exactly what values to pass.
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 verb 'cria-ou-obtém' (create-or-get), the resource (renewal link for a customer in a campaign), and notes idempotency. This distinguishes it from siblings like create_renewal_link and list_renewal_campaign_links, which have different behaviors.
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 mentions the prerequisite of 'write scope' but does not explicitly state when to use this tool versus alternatives. It implies this is the appropriate tool when you need an idempotent create-or-get behavior, but does not name sibling tools or exclusions.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It openly states the write scope ('Escopo write') and the timing semantics (immediate vs scheduled, proration), which are genuine behavioral traits. It does not cover reversibility or failure behavior, but the core mutating nature and scheduling nuances are disclosed.
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 compact sentence that front-loads the core purpose and packs in the timing/proration behavior without waste. It is appropriately sized for the tool.
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?
Given the tool has 3 parameters, no output schema, and no annotations, the description provides solid behavioral context but leaves the semantics of the parameters (especially keep_coupon) and the return/confirmation behavior undocumented. It is adequate but has clear gaps an agent would need filled.
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 must compensate for the undocumented parameters, but it does not explain any of them. offer_slug's expected format is unknown, and keep_coupon — an optional boolean — is entirely unexplained, leaving an agent to guess its meaning when calling the tool.
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 ('Troca o plano de uma assinatura') and adds precise behavioral detail: immediate upgrade with proration versus scheduled downgrade/cycle change. This clearly distinguishes it from its sibling cancel_plan_change, leaving no ambiguity about what the tool does.
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 conveys context by explaining that upgrades take effect immediately with proration while downgrades/cycle changes are scheduled, which helps an agent decide when calling this tool is appropriate. However, it never names an alternative tool or an explicit when-not-to-use condition, leaving the trade-off against siblings like cancel_plan_change to inference.
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?
With no annotations provided, the description carries the full burden and does well: it discloses that the link is single-use, expires in 7 days, and incurs no charge. It also labels the scope as 'write' (Escopo write), indicating a mutation. Missing details like permissions or reversibility are minor given the specific business constraints already disclosed.
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, compact sentence that front-loads the purpose and then lists key constraints. It is efficient and well-structured with no filler words.
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 one parameter and no output schema, the description does not explain subscription_id or what the tool returns. It does not mention the response format (e.g., the link itself) or any prerequisites. The core action is clear but essential operational details are missing.
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 only parameter, subscription_id, has no description in the schema (0% coverage) and the tool description does not mention it at all. The agent must infer that the link is generated for the given subscription, but this is not explicit. The description fails to add any meaning to the parameter beyond its name.
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 verb 'Gera' (generates), the resource 'link para o cliente trocar de forma de pagamento' (link for the customer to change payment method), and adds specific properties (no charge, single-use, 7 days). This distinguishes it from siblings like get_payment_link (retrieve vs create) and create_renewal_link (renewal vs payment method change).
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 gives clear context: it is for generating a link so a customer can change their payment method. It also states constraints (no charge, single-use, 7 days). However, it does not explicitly mention alternatives or when not to use it, but the context is sufficient for an agent to select this tool when a customer requests a payment method change.
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?
No annotations are provided, so the description must disclose behavioral traits. It states 'Escopo write' (write scope) and the 422 error, which are useful. However, it does not describe success responses, idempotency, or side effects. Given the simplicity of the operation, this is adequate but not rich; the write scope and error condition add some transparency but leave gaps.
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 extremely concise: two short sentences that state the core purpose and a key error. It is front-loaded with the action and includes only relevant information. No wasted words, perfectly sized for the simple operation.
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 tool with one parameter and no output schema, the description covers the essential purpose and one error condition, but lacks a description of the input parameter and any caveats (e.g., whether the subscription must exist, whether cancellation is reversible). Given the simplicity and the lack of annotations, the description is minimally adequate but not fully complete for an agent to call it without ambiguity.
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 input schema has one parameter (subscription_id) with zero description coverage (0%). The tool description does not mention the parameter at all, so it adds no meaning beyond the schema. The parameter name is somewhat indicative, but the description fails to explain that it identifies the subscription whose scheduled change should be cancelled, leaving the agent to infer its purpose.
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 (cancel) and the resource (a scheduled plan change), distinguishes it from cancel_subscription and change_plan by emphasizing 'AGENDADA' (scheduled). It also mentions the 422 error, which specifies a key behavior. This is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates that this tool is for scheduled plan changes only, which implicitly tells an agent when to use it versus other sibling tools like change_plan or cancel_subscription. It also mentions the 422 condition as a usage constraint. However, it does not explicitly name an alternative or state when *not* to use it, so it falls short of full exclusion guidance.
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?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It states it is a 'Consulta' (read-only) operation, which implies safety, but it lacks details on authentication needs, rate limits, side effects, or error behavior. It does not contradict annotations (none exist), but it is minimal—just the basic read nature.
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, front-loading the core purpose and then stating the input requirement. Every sentence contributes information; there is no filler. It is appropriately sized for a simple lookup tool.
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 mention the return format or what happens if neither parameter is provided or if both are given. It also doesn't clarify whether 'vivas' (active) subscriptions is a filter that could affect results. For a basic read tool, this is a moderate gap; an agent might call it with incorrect parameters and not know what to expect.
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 description coverage is 0%, so the description is the only source of parameter meaning. It adds significant value by explaining that 'external_id OR email' are alternatives—one must be provided—and clarifies the purpose of each parameter as a customer identifier. This goes beyond the bare schema which only lists them as optional strings.
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 ('Consulta') and the resource ('capacidades (entitlements) das assinaturas vivas de um cliente'), making it obvious this retrieves entitlements for a customer's active subscriptions. It distinguishes itself from siblings like list_subscriptions or get_subscription by focusing on capabilities/entitlements rather than subscription details, so an agent can select it correctly.
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 provides input guidance ('Informe external_id OU email') but does not explain when to use this tool versus the many sibling tools (e.g., list_subscriptions, get_subscription). There is no explicit when-not or alternative recommendation. The context is clear for a specific read operation, but exclusions and comparisons are absent.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does state the key behavior that it does NOT charge, and requires a future date (ISO-8601). However, it does not disclose what happens if the subscription is inactive, whether the operation is reversible, or any error conditions. This is minimal but not comprehensive for a mutation tool without 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 extremely concise, with two short sentences. The primary action and the critical clarification ('NÃO cobra') are front-loaded. The date constraint is stated efficiently. 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 write operation with two parameters and no output schema, the description covers the essential aspects: what it does, what it does not do, and a key input constraint. It omits return value and error handling, but these are less critical for a straightforward reschedule action. It is sufficiently complete for an agent to call it correctly.
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 explain parameters. It explains the constraint on next_billing_at (must be future, ISO-8601) but gives no explanation for subscription_id, which is left to inference from the name. This adds value for one parameter but not the other, so a 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 states a specific action: 'Reagenda a próxima cobrança' (reschedules the next charge), and explicitly clarifies it does NOT charge. This clearly distinguishes it from siblings like charge_now and other billing-related tools. The purpose is unambiguous and immediately actionable.
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 gives clear context: it reschedules the next billing date without charging. This clearly implies that if the intent is to charge immediately, a different tool (e.g., charge_now) should be used. However, it does not explicitly name alternative tools or state when not to use this one, so it earns a 4 rather than a 5.
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/andrespadeto/ribbo-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server