Conexa MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Most tools have distinct purposes with clear descriptions, but the sheer number (83) and some overlapping entities (e.g., sale vs charge vs bill) may cause occasional confusion. Overall, well-differentiated.
Naming Consistency5/5
All tool names follow a consistent verb_noun snake_case pattern (e.g., create_customer, list_contracts). Only minor exceptions like 'end_contract' (instead of delete) remain predictable.
Tool Count2/5
83 tools is far beyond the typical well-scoped range (3-15). While the domain is broad, this size makes agent navigation difficult and increases the risk of misselection.
Completeness4/5
CRUD operations exist for most core entities (customers, contracts, plans, persons, products, sales, charges, etc.). Minor gaps (no update_supplier, missing deletes for some reference entities) but overall surface covers the domain well.
Average 3.7/5 across 83 of 83 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 9 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 passing
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.json to 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 indicate readOnlyHint=false and destructiveHint=false. The description adds no behavioral details beyond the creation intent, offering minimal additional 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with one sentence and an example, all front-loaded. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Missing comprehensive information: no mention of required fields beyond the example, no output description, no error conditions. The openWorldHint suggests additional fields may be accepted, but this is not clarified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter 'body' has a vague description deferring to the tool description. The example provides field names but no definitions, formats, or required/optional status, insufficiently compensating for the lack of schema definition for internal fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool creates an individual charge in Conexa. It is specific but does not differentiate from sibling create tools like create_bill or create_sale.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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 over alternatives. The example shows fields but no context on prerequisites or exclusions.
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 provide destructiveHint=true and readOnlyHint=false. The description adds no extra behavioral context (e.g., irreversibility, cascading effects, or authorization needs) beyond what the annotations convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but underspecified. It conveys the core purpose without waste, but it could include additional useful context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and the destructive nature (destructiveHint=true), the description should explain what happens after deletion (e.g., success response, side effects). It does not, leaving the agent without sufficient understanding of the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a description for the 'id' parameter. The tool description adds no additional semantic meaning or usage hints for the parameter, so it meets the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Exclusão de um plano no Conexa.' clearly indicates the tool deletes a plan (verb+resource). The name and title reinforce this, but the description lacks differentiation from other 'delete_*' siblings beyond the resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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 (e.g., other delete tools or update_plan). There is no mention of prerequisites, consequences, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds minimal value beyond annotations. It states 'retrieval of expense data,' consistent with readOnlyHint=true, but fails to disclose that the promised table of returned fields is missing. No additional behavioral traits are described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief (2 sentences) but the second sentence refers to a non-existent table, making it misleading. Conciseness is acceptable but the missing content is a flaw.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity (1 parameter, no output schema, annotations present), the description should at least specify what fields are returned. Instead, it promises a table that is not provided, leaving the agent uninformed about the response structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single 'id' parameter. The description does not add any semantics or usage details beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves expense (despesa) data by ID, distinguishing it from list_bills (which lists multiple) and other get_* tools. However, it mentions a table that is not present, slightly reducing clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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, such as list_bills for querying multiple bills or other get_* tools. There is no mention of prerequisites or context.
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 destructiveHint=true and readOnlyHint=false, so the description adds minimal value. It does not elaborate on consequences, authorization needs, or irreversible effects, which would be helpful for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. Although brief, it efficiently conveys the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with no output schema and clear annotations, the description is minimally adequate. However, it could mention that the sale is permanently removed and provide error context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (id parameter documented), so baseline is 3. The description adds no additional meaning beyond the schema, such as format constraints or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Exclusão de uma venda recorrente' (deletion of a recurring sale), providing a specific verb and resource. However, it does not differentiate from sibling tools like 'delete_sale' or 'end_recurring_sale', missing an opportunity to clarify 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/5
Does 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, nor any conditions or prerequisites. The description lacks context for appropriate 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 declare readOnlyHint=true and destructiveHint=false, but the description adds no behavioral details (e.g., what data is returned, possible errors, or id format). Without an output schema, the agent lacks information about the response.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence. It is front-loaded and to the point, but could benefit from additional structure or elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, annotations present), the description is minimally adequate but lacks details on return value and usage context, leaving gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single 'id' parameter. The description does not add any extra semantic meaning beyond the schema's parameter description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Recuperação dos dados da Categoria da Despesa' (retrieve expense category data) clearly states the action and resource. It distinguishes from list_bill_categories by implying a single entity retrieval, but does not explicitly contrast with get_bill_subcategory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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 like list_bill_categories or get_bill_subcategory. The description offers no context for selection.
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 and destructiveHint=false, indicating a safe read operation. The description adds no extra behavioral disclosures (e.g., response format, pagination, or rate limits), providing minimal additional value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately conveys the core purpose. It is efficiently front-loaded with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (single parameter, no output schema), the description is adequate but lacks detail on what data is returned (e.g., field names). The Portuguese language may also reduce clarity for English-speaking agents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description for the id parameter. The tool description adds no further meaning beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Recuperação dos dados da Subcategoria da Despesa' clearly indicates retrieval of expense subcategory data by ID. However, it does not explicitly differentiate from sibling tools like get_bill_category or list_bill_subcategories, which have similar retrieval functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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 (e.g., list_bill_subcategories for multiple records). It lacks context about prerequisites or conditions for use.
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 provide readOnlyHint=true, openWorldHint=true, and destructiveHint=false. The description adds no behavioral details beyond the annotations, such as behavior for missing IDs, error handling, or data completeness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise and front-loaded. Every word is necessary; no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should explain what data is returned (e.g., all cost center fields). It only says 'data' without specifics, making it incomplete for an agent to understand the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear parameter description. The tool description does not add any additional meaning beyond what is already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states the verb 'Retrieval' and resource 'Cost Center data' clearly. However, it does not differentiate from other get_* tools like get_customer, which also retrieve data 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 Guidelines2/5
Does 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 list_cost_centers or other similar tools. The description simply states what it does without usage context.
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 declare readOnlyHint=false and destructiveHint=false, but the description adds no behavioral context beyond the field list. It does not explain that unprovided fields remain unchanged (implied by PATCH), or mention required permissions, side effects, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is excessively long (over 50 lines) and structured as a flat bullet list without clear separation between nested objects (e.g., naturalPerson, legalPerson). It reads like a dump of the API documentation rather than a concise tool definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of nested objects and numerous optional fields, the description covers most field details but omits information about return values, idempotency, or error handling. No output schema is provided, so the agent knows the input structure but not what to expect back.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines id and body with minimal descriptions. The tool description compensates by providing a comprehensive list of body fields with types, formats, and examples (e.g., date format 'yyyy-MM-dd', enum values for maritalStatus). However, it does not indicate which fields are required within the body.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Edição de uma ou n informações de um cliente' which clearly indicates updating customer information. The title 'PATCH /customer/:id (Customer)' reinforces this. It distinguishes from siblings like create_customer and get_customer, but could be more explicit about 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 Guidelines2/5
Does 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 create_customer or delete_customer. It does not mention prerequisites, such as the customer must already exist, or when a partial update is appropriate versus a full replacement.
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 indicate readOnlyHint=false (write operation) and destructiveHint=false (non-destructive), but the description does not add beyond these. It fails to disclose important behaviors such as partial update semantics, required permissions, or potential side effects implied by openWorldHint=true. The description focuses on field definitions instead of operational behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely long (over 60 lines) and lists all fields in a flat structure. While it uses bullet points, it is not concise. The first sentence is clear, but the bulk of the text could be shortened or moved to a separate schema definition. Every sentence does not earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all fields and their constraints, which is comprehensive for parameter semantics. However, it lacks information about return values (no output schema), error handling, prerequisites, or an explicit statement that updates are partial. Given the tool's complexity, more context on usage and behavior would be needed for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% but the schema only defines 'id' and 'body' minimally. The description provides extensive details for body fields, including types, format constraints, and conditional requirements (e.g., 'cpf' considered if isForeign false). This adds significant meaning beyond the schema, though the verbose listing could be better structured.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Edição de uma ou n informações de uma pessoa' (editing one or more pieces of information of a person), specifying the verb (update) and resource (person). It distinguishes from sibling tools like create_person and delete_person. However, it does not explicitly differentiate from other update tools, slightly reducing clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a vague warning about unnecessary fields ('Fique atento ao produto do seu sistema. Há campos que não são necessários!') but does not provide explicit guidance on when to use this tool versus alternatives like get_person or create_person. No specific contexts 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 indicate a write (readOnlyHint=false) and non-destructive operation. The description adds example fields but no behavioral traits beyond what annotations imply, such as side effects or authentication needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose but includes a large example block. It could be more concise while retaining utility. The Portuguese language may limit accessibility for English-speaking agents.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Though an example is given, the description does not clarify which fields are required, what the response contains (no output schema), or error handling. For a creation tool, this leaves critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single 'body' parameter is described as containing fields in the tool description. The detailed example JSON adds meaning beyond the generic schema object, showing many nested fields and their structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states it registers a potential customer (CRM deal) in Conexa, which is a specific verb+resource. However, it does not distinguish from sibling tool create_customer, which likely does a similar function for regular customers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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 like create_customer. No when-not or prerequisite conditions. The description only provides an example body without contextual usage advice.
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 it's not read-only and not destructive. The description adds minimal behavioral context beyond the creation purpose. It warns about unnecessary fields but does not disclose side effects, idempotency, or authorization requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement, a warning, and a bulleted list of fields. It is front-loaded but could be slightly more concise without losing essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description adequately explains input parameters. However, it lacks context about return values, error handling, and how this tool relates to siblings like 'create_sale' or 'create_charge'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description lists all fields in the body with types, required status, and brief explanations (e.g., 'customerId: ID do cliente'). Since the input schema does not define these properties, the description carries the full burden and provides meaningful semantics for each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a recurring sale ('Criação de uma Venda Recorrente') and specifies the product types (Service/Item or Package of Hours). It distinguishes from similar tools like 'create_sale' by the recurring nature, though it does not explicitly contrast 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 'create_sale' or other creation tools. The description warns about unnecessary fields but does not provide context 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). Description adds example of input but no additional behavioral details such as authentication, error handling, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose stated concisely in one sentence. Example body is lengthy but necessary given the complex nested structure. Front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks return value or response description. Does not specify which fields in body are required. Annotations indicate openWorldHint=true, but description does not clarify flexibility. Incomplete for a complex creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema only defines a single 'body' parameter with note to see tool description. Description provides an example body that lists many fields, but does not clarify requiredness, constraints, or data types for each field. The example is helpful but insufficient for complete parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it creates a supplier in the Conexa system. Title and name are self-explanatory. However, no explicit differentiation from sibling tools like create_person or create_customer, which may create similar entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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. Does not specify prerequisites, typical scenarios, or when not to use.
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 read-only safe operation. The description adds that returned data depends on software version (via a referenced table), which provides some context beyond annotations, but fails to disclose other behavioral traits like authentication requirements or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the purpose, but the vague reference to a table that is not included makes it incomplete. Every sentence should earn its place; the second sentence is unhelpful without the table.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter, no output schema, and annotations present, the description is partially complete. It mentions a table of return values but does not provide it, leaving the return format ambiguous. For a simple retrieval tool, more explicit output details would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the description adds no extra meaning beyond the schema's parameter description. Both state the parameter is the ID from the route. No examples or format details are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves customer data, matching the tool name and title. However, it does not explicitly differentiate from sibling tools like list_customers or search, and the mention of an absent table reduces clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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. It does not specify that it fetches a single customer by ID while list_customers is for list operations.
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 and destructiveHint=false, indicating safe read behavior. The description adds no additional behavioral context (e.g., data freshness, authorization, or side effects), providing minimal extra 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no unnecessary words. It is front-loaded and directly communicates the tool's purpose, earning its place without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, no output schema), the description is adequate but could specify what data is returned (e.g., 'returns the receiving method object'). The lack of output schema means the description should provide more context, but it remains minimally sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters, with the 'id' parameter described in the schema. The description does not add any further meaning or usage hints for the parameter, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves data of a receiving method ("Recuperação dos dados do Meio de Recebimento."), which is specific and aligns with the tool name. It is distinct from sibling tools like list_receiving_methods, though not explicitly differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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 (e.g., list_receiving_methods). The description only states the action without context for optimal usage.
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, aligning with the description's 'retrieval of data.' The description adds no behavioral details beyond this, but it does not contradict annotations. It could mention that no side effects occur, but given annotations, a score of 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, making it concise and easy to digest. It is appropriately sized for a simple retrieval tool, though it could include more detail without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema, the description should explain what data is retrieved, but it only says 'data from a room reservation.' This is vague. For a tool with low complexity and good annotations, more detail on the return value would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'id' has a schema description that explains it as the value from the route. With 100% schema coverage, the description adds no additional meaning. The description does not elaborate on id format or constraints, so it meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Retrieval of data from a Room Reservation at Conexa' clearly states the verb (retrieval) and resource (room reservation), making the purpose obvious. It distinguishes from sibling tools like list_room_bookings, which list multiple bookings, by focusing on a single booking retrieval. However, it lacks specificity about what data is returned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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 does not mention that this tool retrieves a single booking by ID, while list_room_bookings lists many. The description offers no context about prerequisites or typical usage scenarios.
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=false (mutation), destructiveHint=false (not destructive), and openWorldHint=true (flexible schema). The description adds an example body but does not disclose additional behavioral traits like authentication requirements, validation rules, error handling, or side effects. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with one sentence stating the purpose and a code block example. The key information is front-loaded. The example is large but helpful. Could be slightly more structured (e.g., list fields separately) to improve readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, and the description does not mention what the tool returns (likely the created bill object). For a creation tool, this is a significant gap. The description covers input well but lacks completeness regarding response behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single body parameter, but the schema itself is vague (additionalProperties: {}). The description compensates by providing a detailed JSON example showing required fields (companyId, dueDate, amount, etc.) and their structure. However, it does not explicitly list field types or constraints beyond the example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates an individual expense ('Criação de uma despesa avulsa') in the Conexa system. The verb 'create' and resource 'bill' are specific, and the tool is distinct from siblings like create_charge or create_sale. However, the description is in Portuguese while sibling names are in English, slightly reducing clarity for non-Portuguese speakers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description mentions 'despesa avulsa' (individual expense) implying one-time use, but does not contrast with recurring or other bill-related tools (e.g., create_recurring_sale). No when-not-to-use or prerequisite information is provided.
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 and readOnlyHint=false, so the description does not need to restate destructive nature. However, it adds no further behavioral context (e.g., irreversibility, cascading effects, auth requirements). Baseline 3 is appropriate since annotations exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded, using a single sentence. It is concise but perhaps too terse for non-Portuguese speakers. Still, it wastes no words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple deletion tool with no output schema, the description is minimally complete. However, it lacks information on what the response looks like or any confirmation. Given the tool's simplicity and the annotations, a score of 3 is reasonable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%; the parameter 'id' is already described in the schema. The description adds no additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Exclusão de um contrato' (deletion of a contract), which is a specific verb and resource. It distinguishes from sibling tools like 'end_contract' which may not delete. However, it could be more explicit about what 'contrato' means in this system.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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 'end_contract' or other delete tools. No mention of prerequisites or contexts where deletion 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 (readOnlyHint=true, destructiveHint=false) already indicate a safe read operation. The description adds that some fields may not be returned depending on the product, which is useful. However, no further behavioral details (e.g., auth, rate limits) are provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first clearly states purpose, second warns about field variability. Concise and front-loaded, though the warning could be more specific.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so description should compensate by explaining return structure. It mentions a table of possible values but does not elaborate. Adequate for a simple retrieval, but could be more detailed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a description for the 'id' parameter. The tool description does not add additional meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves a charge by ID ('Recuperação da cobrança dado o seu ID'), with a specific verb and resource. Among siblings like 'get_bill' or 'get_customer', it distinguishes itself by focusing on charges, but does not explicitly differentiate from other get 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 'list_charges' or other retrieval tools. The warning about product-specific fields is context, but not a usage boundary.
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=false (write) and destructiveHint=false. The description adds the list of editable fields but does not disclose any side effects (e.g., whether updates trigger emails despite email flags) or constraints like partial update behavior. It relies on annotations for basic transparency, so a 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear opening sentence and a bullet list of body fields. It is well-structured and avoids unnecessary verbosity, though it could benefit from grouping related fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lists editable fields but lacks information about update behavior (e.g., partial update, required fields, error handling, return format). No output schema is provided, so the description should have explained response details. It leaves significant gaps for an update tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for id and body parameters, but the description adds significant value by detailing the expected fields inside the body object (e.g., personId, date, startTime, visitors with subfields). This compensates for the body schema's generic additionalProperties.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it edits fields of a room booking ('Edição de campos de uma Reseva de Sala de Reunião'). It is specific about the resource and action, though it could explicitly mention it updates an existing booking to differentiate from create_room_booking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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 like create_room_booking, cancel_room_booking, or checkout_room_booking. The description only lists editable fields without usage context.
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 indicate it is not read-only (write operation) and not destructive. The description does not add behavioral details beyond field listing, such as authentication needs or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very long and contains a wall of text listing all fields. While it has some structure with indentation, it is not concise and buries the essential purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with many nested objects, the description is complete in documenting all fields. However, it lacks broader context about expected usage or outcomes, though no output schema exists to cover return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With a minimal input schema, the description provides exhaustive parameter semantics including types, required flags, formats, and enumerated values, fully compensating for the schema's lack of detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it creates a customer in the Conexa system, which is clear. However, it does not differentiate from sibling tools like create_person or create_potential_customer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description warns about unnecessary fields but provides no explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites or constraints.
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 readOnlyHint=false and destructiveHint=false, but the description adds no extra behavioral context such as auth requirements, rate limits, or side effects. It merely lists input fields, which is already covered by the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a long list of fields. While structured, it is verbose and could be more succinct. Each sentence earns its place, but the overall length detracts from readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all input fields thoroughly but lacks mention of the return value or output behavior. Given no output schema, an agent would benefit from knowing what the response contains. For a creation tool, this is a moderate gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines a generic 'body' property, but the description fully enumerates all fields (customerId, personId, roomId, etc.) with formats and notes. This compensates for the minimal schema, providing meaningful semantics beyond the schema itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Cadastro de uma Reserva de Sala de Reunião' (Registration of a meeting room reservation), which is a specific verb and resource. It distinguishes from siblings like cancel_room_booking, update_room_booking, and get_room_booking by focusing on creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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 such as update_room_booking or cancel_room_booking. The description does not mention prerequisites or context for using this creation endpoint.
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 clear. The description adds that it retrieves main data for any sale type, but does not elaborate on authorization, rate limits, or what 'main data' entails. This is adequate but not exceptional.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core purpose. It could be improved by adding structure (e.g., bullet points for usage notes), but it is not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should specify what fields are returned by 'principais dados'. It also lacks information on prerequisites or permissions. For a simple read tool, this is a notable gap reducing completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description for the sole parameter 'id'. The tool description does not add any additional meaning beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Recuperação' (retrieve) and the resource 'principais dados de uma venda' (main data of a sale), and explicitly covers both single and recurring sales, distinguishing it from sibling tools like get_recurring_sale and list_sales.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool versus alternatives such as get_recurring_sale or list_sales. No explicit when-to-use, when-not-to-use, or contextual hints are given.
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 adds behavioral context beyond annotations by explaining that retroactive check-ins are allowed and require a checkout datetime. However, it does not clarify what happens when the datetime parameter is omitted (presumably uses current time) or what the tool returns upon success. Annotations already indicate a write operation (readOnlyHint=false) and no destructive effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably structured with warnings and a field list, but it is somewhat verbose with emojis and repeated caution. It could be more concise while retaining clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks information about the tool's return value or success confirmation, which is important for an agent to know the outcome. It also does not specify default behavior for the datetime field. Given no output schema, the description should provide more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only describes a generic body object, so the description provides all parameter semantics: it lists all fields (personId, workspaceId, notes, datetime, checkoutDatetime), specifies which are required, and gives format constraints for datetime (W3C format). This fully compensates for the minimal schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a check-in record (Registro de Check-In) for a person and workspace in the Conexa Coworking system. It distinguishes itself from sibling tools which create other entities like bills or customers, but there is no other check-in tool, so differentiation is not needed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions it is only available for Conexa Coworking but provides no guidance on when to use this tool versus alternative methods or when not to use it. There is no explicit comparison with sibling tools or conditions for preferred usage.
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 destructiveHint=true and readOnlyHint=false. The description adds that it can both end an active sale and update the closing date, but does not explain side effects or recovery options. No additional behavioral details beyond 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences and a JSON example. No unnecessary words. Information is 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple but lacks return value information. With no output schema, the description does not explain what happens after ending (e.g., whether the sale becomes inactive). Sibling tools are complex, so more context would aid selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% but only gives minimal descriptions for 'id' and 'body'. The tool description provides an example body with the 'date' field, which clarifies the expected structure beyond the schema's generic 'JSON object' description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool ends an active recurring sale or updates its closing date. It mentions a specific resource ('recurring sale') and action ('end' or 'update closing date'). However, it does not explicitly differentiate from the 'update_recurring_sale' tool, which might update the same field.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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 like 'delete_recurring_sale' or 'update_recurring_sale'. The description lacks context on prerequisites or scenarios for each option.
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 (readOnlyHint=true, destructiveHint=false) already indicate a safe read operation. The description adds no further behavioral context, such as return format or performance implications. It is consistent with annotations but doesn't provide additional value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence in Portuguese with no unnecessary words. It is front-loaded with the core purpose. However, it could be slightly more informative without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one required parameter, read-only), but the description lacks details about the response (no output schema). It could mention that it returns the full extra field object or note it complements list_extra_fields. Adequate but minimal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the parameter description ('Valor de :id na rota /extraField/:id') is clear. The tool description does not add any extra meaning beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves data of an extra field ('Recuperação dos dados de um Campo Extra'). It uses a specific verb and resource, and distinguishes from siblings like list_extra_fields (list) and create_extra_field (create).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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 like list_extra_fields or other get tools. The description doesn't mention that it fetches a single record by ID or provide context for when it 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 readOnlyHint=true and destructiveHint=false, making the non-mutating nature clear. The description adds no extra behavioral details, such as whether the retrieval is by ID or what happens if the ID is invalid. With annotations present, the description is adequate but 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is appropriately sized for a simple retrieval tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple GET-by-ID tool with one parameter and no output schema, the description is sufficient. It clearly states the purpose, and annotations cover safety. However, adding a brief note about what an invoicing method is could improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'id' is fully described in the input schema (100% coverage). The description does not elaborate on the parameter, which is acceptable given the schema covers it. No additional semantics are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves data of an invoicing method, matching the tool's name and HTTP GET method. However, it does not differentiate from similar sibling tools like get_receiving_method or get_payment_method, which could cause confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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 (e.g., list_invoicing_methods, get_receiving_method). There is no context about prerequisites or scenarios where this tool 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 declare readOnlyHint and destructiveHint. The description adds no new behavioral details (e.g., return format, authorization needs). With annotations present, the description is adequate but does not provide 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence in Portuguese. It is front-loaded with the core action, no wasted words. Could be slightly more descriptive but efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with one parameter and annotations, the description is minimally complete. However, no information about what the returned data contains or if there are any constraints is given. Could be improved with a brief note on the scope of data returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and description does not add meaning beyond the schema. Parameter 'id' is fully defined in the schema, so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Recuperação dos dados de Categoria de Serviço' clearly indicates retrieval of service category data, distinguishing it from sibling 'list_service_categories' which would return multiple. It implies a single entity fetch, aided by the required id parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 'list_service_categories'. Usage is implied by the parameter and name, but lacking explicit context for agents.
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 indicate readOnlyHint=false and destructiveHint=false, so the tool modifies state but is not destructive. The description adds no additional behavioral details such as side effects (e.g., email sending), required permissions, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with one sentence and an example body. It front-loads the purpose but could be slightly more structured. However, it avoids unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a complex body parameter and no output schema, the description does not explain return values or error scenarios. With openWorldHint=true, it is acceptable but incomplete for full understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100% with descriptions for 'id' and 'body', the body parameter's description defers to the tool description. The example JSON in the description provides concrete fields (settlementDate, receivingMethod, etc.), adding meaningful semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Manual settlement of a charge' which is a specific verb and resource. Among sibling tools, no other tool performs settlement, so it is well-distinguished.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives (e.g., when a charge is pending or should be settled automatically). No when-not-to-use or prerequisite information is given.
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 it's a read/write operation (readOnlyHint=false, destructiveHint=false). The description adds no additional behavioral context such as whether updates are partial or full replacements, idempotency, or validation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a clear list of fields, easy to scan. No redundant sentences, but could be more concise by omitting the translation header.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description covers the input fields, it lacks information about the return value, error handling, or behavior after update. With no output schema, this gap is noticeable but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% but the body parameter description points to the tool description. The description adds meaning by detailing all allowed fields (name, price, etc.) beyond the minimal schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Edição de campos de um Item/Serviço' (editing fields of a product) and lists the updatable fields. It distinguishes from siblings like create_product, delete_product, and list_products.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives (e.g., create_product or delete_product). No mention of prerequisites or constraints.
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 indicate it modifies data (readOnlyHint=false) and is not destructive. The description only lists editable fields, lacking details on side effects, authorization needs, or behavior when fields are omitted. The openWorldHint is present but not explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two short paragraphs: first states purpose, second lists fields. No unnecessary information. Efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, no description of response or errors. The description does not explain the PATCH semantics (partial update) or what happens to omitted fields. Lacks completeness for a mutation tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters (id and body) but body's inner structure is unspecified. The description lists the editable fields (requesterId, amount, quantity, etc.), adding significant value beyond the schema. It helps the agent understand what can be updated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it edits fields of a recurring sale, using the verb 'Edição de campos' (editing fields). The title indicates PATCH method and resource. It is well-distinguished from sibling tools like create, delete, end, and get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. It does not provide context for prerequisites or exclusions, leaving the agent to infer usage based on the resource name alone.
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 destructive and not read-only. Description adds details on optional cancellation of associated sale and email notifications, providing behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is short and to the point, with a clear purpose line followed by parameter details. No wasted words, but could be better structured with an intro sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers parameters and effects but lacks information on response format, error conditions, or prerequisites. For a destructive tool, more context on side effects or required permissions would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% but only defines body as object; description lists all body fields (cancelSale, sendEmailCustomer, etc.) with types, defaults, and meanings, adding essential semantics not in schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it cancels a room reservation in Conexa, with a specific verb and resource. However, it does not distinguish from sibling tools like checkout_room_booking or update_room_booking, missing 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/5
Does 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. The description only states the action without context on prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds no additional behavioral context (e.g., auth needs, rate limits), but this is acceptable given annotations; still, no extra value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the primary action. Every word is necessary; no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (one param, no output schema), the description is minimally adequate but lacks details about return values or what the payment method data includes. Annotations provide safety context, but the output is undefined.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description only repeats the schema's parameter explanation ('Valor de :id na rota /paymentMethod/:id'). No additional meaning is added beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Recuperação dos dados do Meio de Recebimento' (Retrieval of payment method data) clearly states the verb (retrieval) and resource (payment method data), distinguishing it from sibling tools like list_payment_methods and other get_ 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/5
Does 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 such as list_payment_methods for listing or other get_ tools for different resources. The agent must infer from 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 indicate readOnlyHint=false and destructiveHint=false, which are consistent with a mutation that is not destructive. The description adds context about the integration (D4Sign) and the process (PDF generation from template, sending via email/whatsapp), but does not disclose side effects, such as whether a signature request record is created or if there are idempotency guarantees.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose with a long list of fields, but it is well-structured with headings and clear field definitions. The purpose is front-loaded, but the length could be reduced without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description thoroughly covers input parameters but omits output or return values. There is no explanation of what happens after a successful request (e.g., response status, signature request ID). Also, error conditions and prerequisites are not mentioned. Given the tool's complexity, this is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines id and body, leaving body fields unspecified. The description compensates by listing all required and optional body fields with their types, constraints (obrigatório), and allowed values (e.g., email, whatsapp). This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to request sending a contract for electronic signature via D4Sign integration. It specifies the endpoint and distinguishes it from sibling tools like create_contract or delete_contract.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. While the purpose implies it's for signature requests after contract creation, there is no mention of prerequisites, conditions, or alternative tools for similar tasks.
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 description does not need to reiterate safety. It adds minimal context (system name 'Conexa') but does not disclose any additional behavioral traits like authentication needs or response characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler. It is front-loaded and every word contributes meaning. Ideal conciseness for a simple retrieval tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given 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 what data is returned (e.g., 'full company data' or specific fields). It only states 'dados' (data), which is vague. More detail would be helpful for the agent to understand the response structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema fully documents the 'id' parameter. The description adds no extra meaning beyond what is in the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves data of a specific resource ('Unidade' / company) in the Conexa system. This distinguishes it from sibling tools like 'list_companies' which return multiple items. The verb 'recuperação' (retrieval) is specific and the resource is named.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus siblings. The context implies usage when a specific company ID is known, but no alternatives or exclusions are mentioned. The agent must infer from the resource name and parameter requirement.
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, so the description adds no extra behavioral context. It does not describe what happens if the ID is missing or invalid, but it is consistent with 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the purpose without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID operation, the description is adequate. No output schema exists, but the expected return is clear from the context. Lacks mention of error handling or edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a description for the single parameter. The description does not add additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves contract information by ID, using a specific verb (recupera) and resource (Contrato). It distinguishes from sibling tools like list_contracts which list multiple contracts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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 list_contracts or other get tools. The description does not provide context 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true. The description adds value by disclosing pagination behavior, the requirement for the 'limit' parameter for new pagination, and the deprecation timeline. It also notes that array parameters accept multiple comma-separated values, which is not fully covered by the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of three sentences: purpose, note about array parameters, and a pagination warning. It is relatively concise and front-loaded with the most critical information. The warning about mandatory 'limit' is important and placed as the last sentence, which is acceptable. Could be slightly more streamlined but overall effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should clarify the return format (e.g., an array of company objects). It does not mention what fields are returned, pagination structure (e.g., next page token), or any default ordering. For a list tool with 8 optional parameters and no output schema, the description is incomplete. Additionally, the use of Portuguese may reduce comprehensibility for some agents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter having a description. The tool description adds general guidance that parameters defined as array can accept multiple comma-separated values, which complements the schema. While some parameters like 'city' lack that detail in schema, the description provides a helpful overarching rule. The baseline is 3 due to high coverage, but the extra context justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Listagem paginada de Unidades' which indicates a paginated listing of units (companies). The tool name and title reinforce that it lists companies. It distinguishes from sibling list_* tools by specifying the resource. However, the Portuguese term 'Unidades' may be unclear to some English-speaking agents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing companies with pagination and provides a crucial warning about the mandatory 'limit' parameter for new pagination. However, it does not explicitly mention when to use this tool versus alternatives like get_company or other list_* tools, leaving the agent to infer based on resource 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 indicate readOnlyHint=true and destructiveHint=false. The description adds useful context about array parameter formats and the critical new pagination requirement, but the included example body (username/password) is irrelevant for a GET endpoint and may mislead about the tool's behavior. 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise but includes an unnecessary example body that does not relate to the tool's operation. The most important information is front-loaded, but the extraneous content reduces clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain the response structure, but it only references a vague example and does not describe returned fields. The example body is irrelevant, leaving the agent underinformed about what the tool returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all parameters described. The description adds value by clarifying that array-valued parameters accept comma-separated values and by highlighting the mandatory 'limit' parameter for the new pagination model, which is not fully captured in the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Listagem paginada de pessoas' (paginated listing of persons), which clearly identifies the verb and resource. The tool name 'list_persons' aligns perfectly, and it is distinguished from sibling tools like 'get_person' (single) and 'create_person'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing persons but does not explicitly state when to use this tool over alternatives. It mentions pagination constraints but lacks direct guidance on when-not-to-use or comparisons with siblings. The example body is irrelevant and may confuse.
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 destructiveHint=true and readOnlyHint=false. The description adds that the tool applies to active contracts and can update end dates, and includes an example body. However, it does not disclose side effects (e.g., whether associated reservations are affected) or behavior beyond the stated action, which is minimally additive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence stating purpose followed by a compact JSON example. No extraneous information, and the key action is front-loaded. Every element serves a purpose without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with two parameters and no output schema, the description covers the core action and example body but omits important context: required vs optional subfields, possible values for reasonId, effect of unlinkCustomer, and expected response. The lack of behavioral details beyond the example leaves gaps for the agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the body parameter's schema only references the description. The description adds meaning by listing three fields (date, reasonId, unlinkCustomer) with an example, helping the agent construct the request. However, it lacks explanations of each field's semantics, constraints, or defaults, so not fully compensatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool ends an active contract or updates its end date ('Encerra um contrato ativo ou atualiza a data de encerramento'). This differentiates it from siblings like delete_contract (permanent deletion) and update_contract (general updates), making the purpose specific and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives. It does not mention conditions like 'use this to end a contract without deleting it' or contrast with delete_contract or update_contract. The description only states the action without usage context.
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?
Adds context beyond annotations: mentions pagination behavior, that multiple values for array items are comma-separated, and a deprecation notice. No contradiction with readOnlyHint=true and destructiveHint=false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences effectively convey purpose and key usage notes. Front-loaded with purpose. Could be slightly more concise but generally well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite high schema coverage, the description lacks information about return structure (e.g., fields returned, pagination metadata). No output schema exists, so the description should at least hint at what the response contains. This is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description repeats that multiple values are comma-separated, adding minimal new meaning. The description does not provide deeper parameter semantics beyond what the schema already conveys.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Listagem paginada de vendas' (paginated listing of sales) and distinguishes from sibling tools like get_sale and create_sale by being a list operation. It also notes it covers both one-off and recurring sales.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides usage guidance on pagination parameters and a deprecation warning, but does not explicitly specify when to use this tool vs other list tools or alternatives. The context of being a listing tool is implicit.
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 write (readOnlyHint=false) and non-destructive (destructiveHint=false) operations. The description adds behavioral detail about datetime defaulting to current time and the ability to create pending checkouts, but does not cover other behaviors like authorization or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary line and bullet points for fields. It is slightly verbose but every sentence adds value, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a write operation with no output schema, the description adequately covers required and optional parameters, default behavior, and datetime format. It is comprehensive enough for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines a generic 'body' object with no parameter details. The description fully compensates by listing all parameters (personId, workspaceId, datetime, notes), their types, required status, and datetime format, adding essential meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is for registering a checkout with person, workspace, and datetime. It specifies the system (Conexa) and the fields, but does not explicitly differentiate from sibling tools like create_checkin or checkout_room_booking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage context such as default datetime behavior when not provided and the ability to do a pending checkout by specifying datetime. However, it does not discuss when to use this tool versus alternatives or provide 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?
Annotations indicate a write operation that is not destructive. The description adds valuable behavioral context by stating that sensitive card data (number and CVC) are stored encrypted only in Cielo, which goes beyond the annotation 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a clear paragraph followed by a detailed example. It is front-loaded with the purpose and maintains efficiency, though the example could be slightly trimmed without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, input structure, and a security note, but lacks details on the output/response. For a write-intensive tool, knowing what is returned (e.g., the created card ID) would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines a generic 'body' object with no internal properties, but the description provides an example with fields (customerId, number, name, etc.), effectively describing the parameters. Schema coverage is considered 100% due to the reference to the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool registers a customer's credit card via Cielo, distinguishing it from other create tools like create_sale by focusing on card storage. The example further clarifies the resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives such as create_charge or create_sale. It only notes a security detail without contextual usage advice.
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 indicate this is a mutable but non-destructive operation. However, the description adds no additional behavioral context beyond creation; it omits what the response contains, authentication requirements, or potential side effects. Without an output schema, agents receive insufficient behavioral information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence followed by a clear bulleted list. It is front-loaded with the purpose and then efficiently covers each parameter. Every line is necessary and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers all parameters but lacks important context: no mention of the HTTP method (though title hints POST), no response format, no error conditions, and no permissions or prerequisites. For a creation tool with no output schema, this leaves agents with missing information for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is minimal (only a body object with no properties), so the description carries the full burden of parameter documentation. It lists all 8 fields with types, required status, and meaningful descriptions (e.g., 'Deve ser um valor maior que zero' for quantity). This adds significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Criação de uma venda avulsa', clearly indicating a one-time sale creation. It distinguishes from sibling tools like create_recurring_sale and create_product by specifying the resource and the 'avulsa' (one-off) nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (for one-off sales) via the word 'avulsa', but does not explicitly state when not to use it or provide direct alternatives. Agents may infer from sibling names, but no explicit guidance is given.
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 destructiveHint=true and readOnlyHint=false, so the description's 'Exclusão' is consistent with deletion. However, it adds no further behavioral details (e.g., reversibility, permissions, or side effects) beyond the constraint of non-invoiced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that directly states the tool's purpose with no extraneous words, making it highly efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with one parameter, the description reasonably captures the key constraint (non-invoiced) and purpose. It could mention error handling or success behavior, but the context is largely adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single 'id' parameter, and the schema description accurately explains its role. The tool description does not add any additional meaning or usage nuance beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool deletes an individual sale that is not invoiced ('Exclusão de uma venda avulsa no Conexa não faturada'), which clearly distinguishes it from sibling tools like delete_customer or delete_product.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage only for non-invoiced sales via 'não faturada', but it does not explicitly state when to use this tool versus other delete operations or provide any when-not or alternative 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the tool is clearly safe for reads. The description adds no additional behavioral traits beyond restating the purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that conveys the purpose with no extraneous words. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one parameter, no output schema, annotations covering safety), the description is sufficient for a simple retrieval tool. It could mention return fields but is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter, and the description does not provide any additional meaning beyond the schema's description. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves bank account data, using a specific verb ('recuperação') and resource ('Conta Bancária'). It distinguishes from sibling tools like list_accounts and other get_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly mention when to use this tool versus alternatives like list_accounts. Usage is implied by the purpose, but no when-not or alternative guidance is provided.
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 readOnlyHint=true and destructiveHint=false. The description ('returns') is consistent and adds the specific scope of 'Pix generated', but does not elaborate on failure modes or security.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence that effectively communicates the tool's function without any unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one required param, no output schema, safety annotations), the description is mostly complete. However, mentioning the typical response structure would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter id. The description repeats the route parameter meaning without adding new context beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns the Pix generated for a given charge ID, which distinguishes it from sibling tools like get_charge and list_charges.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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, nor any context on prerequisites or scenarios.
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, making the safe read-only nature clear. The description adds no further behavioral context 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence with no extraneous information. It efficiently conveys the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only retrieval with one parameter and no output schema, the description is mostly adequate. However, it could mention typical fields of the supplier entity but overall suffices given annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters (id) with a clear description matching the route. The tool description does not add any additional semantic meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Retrieval of Supplier data', which clearly indicates fetching a supplier record. This distinguishes it from list_suppliers (which retrieves multiple) and other get_ tools for different entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the tool name and parameter (requires an ID), but no explicit guidance on when to use versus alternatives like list_suppliers or other get_ tools is provided.
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?
Beyond the annotations (readOnlyHint=true, openWorldHint=true, destructiveHint=false), the description adds behavioral traits: array parameters accept comma-separated values, and pagination behavior depends on the 'limit' parameter. This enriches agent 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences covering purpose, array behavior, and pagination warning. It is relatively concise and front-loads the purpose, but the warning is slightly lengthy. Could be more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 6 parameters, no output schema, and no required parameters, the description explains pagination and array behavior but omits details about the response structure, sorting, or the relationship between subcategories and categories. This leaves gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds a general note about array parameters and the pagination migration, but does not provide additional meaning for individual parameters beyond what the schema already offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Listagem paginada de Subcategorias de Despesa' (paged listing of expense subcategories). This differentiates from sibling tools like list_bill_categories and get_bill_subcategory, though it does not explicitly compare them. The title further clarifies the resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use the new pagination (by providing the 'limit' parameter) and warns about the old pagination being deprecated. However, it does not compare this tool to alternatives like list_bill_categories or get_bill_subcategory, leaving some ambiguity.
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 non-read-only and non-destructive. The description adds the note that sellerId must be used with API Token authentication, and lists fields, but does not clarify update semantics (partial vs full replace, behavior of omitted fields). More context on how the update works would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy due to the many fields, but it is structured with a header and list. However, it could be more concise by reducing redundancy or grouping related fields. The key action is front-loaded in the first line, but the large block of text may overwhelm agents.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully covers the input parameters, which is the main complexity. However, it lacks information about the return value (likely the updated contract) and possible error conditions. This gap reduces completeness, especially given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides only id and body as parameters, with body simply described as 'Corpo JSON'. The description extensively documents all allowed body fields with types and meanings, thus adding essential semantics beyond the schema. This is critical for correct tool invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Edição de um contrato' (editing a contract) and the tool name 'update_contract' and title 'PATCH /contract/:id (Contract)' unambiguously indicate the action and resource. It is easily distinguished from siblings like create_contract, delete_contract, and end_contract.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose is implied by the name and description ('Edição de um contrato'), but there is no explicit guidance on when to use this tool vs alternatives (e.g., create_contract for new contracts, delete_contract for removal). No when-not or context provided.
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=false and destructiveHint=false, which are consistent with the update operation described. The description adds no additional behavioral context (e.g., permissions, side effects, partial update behavior). It merely restates the update action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description starts with a clear one-line summary, then lists all body fields in an organized manner. While the list is long, it is necessary given the complexity of the plan object. The structure is logical, but could be slightly more concise by using a table or reference. However, it remains easily parseable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high number of parameters and no output schema, the description does a good job covering the input fields, including required markers and allowed values. However, it lacks information about return values, error handling, or update semantics (e.g., whether omitted fields are preserved or reset). The annotations provide basic safety context but not full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines two parameters (id and body) with minimal descriptions. The tool description provides exhaustive detail for all body fields, including data types, required status (marked as [obrigatório]), and constraints (e.g., unique name, periodicity options). This adds significant meaning beyond the schema's simple description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Atualiza um plano' (Updates a plan), which is a specific verb+resource. It distinguishes from sibling tools like create_plan and delete_plan, but does not explicitly differentiate from other update tools like update_contract or update_product. The context 'utilizado no cadastro de contrato' adds usage context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives one usage context ('utilizado no cadastro de contrato') but does not specify when to use this tool vs alternatives (e.g., create_plan for new plans, delete_plan for removal). No explicit when-not-to-use or prerequisite information is provided.
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 non-read-only (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds no behavioral traits beyond stating it's a 'registration' of checkout. No contradictory information, but it lacks details like prerequisites or side effects (e.g., status updates, email sending).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: first states purpose, second lists body field. No redundant information, front-loaded with the core action. Every sentence is essential and well-structured for quick parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given 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 explain the response or return value. For a checkout operation, it would be helpful to know what is returned (e.g., confirmation, updated booking). The description is complete for input but lacks output context, given the tool's moderate complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers both parameters (id, body) with 100% coverage. The description adds value by explaining the body field contains sendEmail boolean, which is not detailed in the schema. It also clarifies that id is the bookingId. The schema's additionalProperties allows flexibility, but the description provides concrete guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The title and description clearly state it's for checking out a room booking by ID ('Registro de Check-Out de Sala através do ID da reserva'). It uses a specific verb ('checkout') and resource ('room booking'), distinguishing it from siblings like create_checkin or create_checkout.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates usage for checkout via booking ID but does not explicitly state when to use this tool versus alternatives like create_checkout or cancel_room_booking. No when-not or alternative guidance is provided, though the purpose is clear enough for an AI 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?
Annotations indicate readOnlyHint=false and destructiveHint=false, meaning it is a non-destructive write operation. The description does not contradict annotations but adds behavioral context through detailed field descriptions (e.g., required fields, formats, enums). However, it omits side effects, failure handling, or authentication requirements, which annotations alone do not provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose, listing over 30 fields with nested objects. It is well-structured with bullet points and front-loaded purpose statement, but could be shortened by grouping similar fields or using tables. Every sentence earns its place given complexity, yet conciseness suffers.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description thoroughly covers all input parameters, including types, requirements, formats, and allowed values. However, it lacks description of the output or return value (no output schema) and does not address error scenarios or confirmation details. For a creation tool with complex input, parameter coverage is excellent, but behavioral context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines a 'body' property as an object with no internal structure. The description provides exhaustive details for all body fields: types, required status, formats, allowed values (enums), and nested object structures. This adds immense value beyond the sparse schema, making parameter semantics very clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Cadastro de um contrato para um Cliente no sistema Conexa', which specifies the verb (create/register), resource (contract), and context (for a client in the Conexa system). This distinguishes it from siblings like update_contract, delete_contract, and end_contract.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives. It implicitly covers contract creation but lacks 'when-not-to-use' or comparison with similar tools like create_plan or create_recurring_sale. Usage is implied by the tool name and purpose, but no exclusions or prerequisites 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?
Annotations provide readOnlyHint=false, destructiveHint=false, and openWorldHint=true. The description adds no additional behavioral traits beyond the example body; it does not disclose side effects, permissions, or response behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus a focused example body. No redundant information; purpose is immediately clear. The example is necessary for parameter clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, and the description does not explain what the tool returns (e.g., created entity ID). For a creation tool, this is a notable gap, though annotations and example provide partial context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has only a generic 'body' parameter with a description referencing the tool's description. The description provides a detailed example body with fields like name, price, companyId, etc., compensating for the schema's lack of explicit property definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Criação de um Item/Serviço no sistema Conexa', which is a specific verb (create) and resource (product/service). It distinguishes from sibling tools like create_charge or create_sale.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives (e.g., create_plan or create_sale). The example body implies usage context but lacks when-not-to-use or prerequisite information.
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 destructiveHint=true, so the destructive nature is clear. The description adds the important behavioral constraint that deletion only occurs when no linked records exist. However, it does not disclose what happens if the condition fails (e.g., error response) or any other side effects. With annotations covering the base safety profile, the description provides some additional context but not full 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the action and condition. It contains no unnecessary words and is efficiently structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with one parameter and no output schema, the description covers the core action and precondition. However, it lacks information about error behavior if the condition isn't met, or how the result is communicated. Given the tool's simplicity, it is minimally viable but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is only one parameter 'id' with schema description already covering its purpose (the route parameter). The description does not add any extra meaning or context about the parameter. Since schema coverage is 100%, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool deletes a customer, and adds a specific condition (only when no linked records exist). This distinguishes it from other delete tools like delete_contract or delete_person. The verb 'delete' combined with the resource 'customer' 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies when to use the tool: when there are no linked records (sales, charges, etc.). This provides clear context, but it does not explicitly state when not to use it (e.g., if customer has linked records) or mention alternative tools. However, the condition implicitly guides usage.
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 destructiveHint: true. Description adds the important behavioral detail that the item must be deactivated for deletion to succeed, which goes beyond the annotation. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two sentences that convey the purpose and a key precondition without any extraneous information. Front-loaded for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with one parameter, the description covers the essential precondition. However, it does not mention the return value or expected outcome on success/failure, which would improve completeness. Given the complexity, it is adequate but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description does not add any additional meaning to the single 'id' parameter beyond what the schema already provides. Baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it is for deleting a service/item in Conexa, with a critical precondition. It distinguishes from sibling delete tools by specifying the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states that the item must be deactivated before deletion, providing a usage condition. However, no guidance is given on when to use this tool over other delete tools (e.g., delete_contract, delete_customer).
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 readOnlyHint=true and destructiveHint=false, so the description adds value by explaining pagination behavior, multi-value array syntax, and the deprecation warning for the old pagination model. This enriches the behavioral understanding 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences plus an attention notice), front-loaded with purpose, and every sentence adds value. The attention note is crucial and is placed appropriately without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (list, read-only, no output schema), the description covers purpose, pagination, and multi-value behavior. However, it lacks any indication of the return structure (e.g., fields included in the listing), which the agent might need to know for downstream processing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter having a clear description. The description adds general info about comma-separated values for array items, which partially overlaps with the schema's description for 'id' but adds a broader clarification for other parameters like 'name' that lack it. Overall, the description adds marginal semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Listagem paginada de Categorias de Despesa' (Paginated listing of Expense Categories), specifying the verb and resource. It implicitly distinguishes from sibling tools like get_bill_category (singular) and list_bill_subcategories (different resource).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides important usage information about pagination and the limit parameter behavior, but does not explicitly guide on when to use this tool versus alternatives like get_bill_category. The guidance is primarily technical, not contextual.
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?
Beyond the annotations (readOnlyHint, destructiveHint), the description discloses the dual pagination behavior depending on the limit parameter and its future deprecation. This adds context about operational modes, though it does not detail output structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, efficiently stating purpose, a note on array inputs, and a critical pagination warning. No fluff, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should hint at the return structure (e.g., fields of invoicing methods), but it does not. The pagination warning is helpful but incomplete without specifying the new pagination model details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the tool description adds little new parameter meaning beyond repeating that array-valued parameters accept comma-separated values. The warning about limit is useful but not semantic expansion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a 'Listagem paginada de Meios de Faturamento' (paginated listing of invoicing methods), using a specific verb and resource. It also differentiates from the sibling 'get_invoicing_method' implicitly through the listing focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit when-to-use or when-not-to-use guidance compared to siblings. It includes a warning about the limit parameter for pagination but lacks direct comparison with other list or get tools.
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 readOnlyHint=true and destructiveHint=false, so the description's main contribution is the deprecation warning about the pagination model and the note about comma-separated values. These add useful behavioral 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no unnecessary text. The first sentence delivers purpose, the second adds a critical caveat. Efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 optional parameters and no output schema, the description covers pagination and the comma-separated filter pattern. However, it omits the default limit (20) and does not explain how filters combine or provide examples. Adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage, so the description adds little beyond repeating schema notes (e.g., comma-separated values). The warning about requiring limit for new pagination is relevant but does not deepen parameter understanding. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Listagem' (listing) and resource 'Categorias de Serviço' (Service Categories), and distinguishes from the sibling get_service_category by implying pagination. It leaves no ambiguity about the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool over alternatives like get_service_category or other list tools. It provides context about pagination but lacks comparative guidance. The warning about the deprecated pagination model is useful but operates at a lower level.
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 mark destructiveHint=true and readOnlyHint=false. The description adds critical context: deletion is permanent and cascades to linked values. This goes beyond annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences—concise and front-loaded. The first sentence states purpose, the second adds key warnings. No extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with one parameter and no output schema, the description is nearly complete. It explains the action and consequence. Missing elements like required permissions are minor given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single 'id' parameter described as 'Valor de :id na rota /extraField/:id'. The description does not add new meaning to this parameter, so it meets the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool deletes an extra field ('Exclusão de um Campo Extra'). The verb and resource are specific, and it distinguishes from sibling delete tools like delete_contract and delete_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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies usage for deletion but does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives like updating the field to inactive. The warning about permanence is helpful context but not direct usage guidance.
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 readOnlyHint and destructiveHint. The description adds value by warning that certain fields may be missing depending on optional modules or contracted system type, which is a key behavioral trait.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence with a front-loaded warning. Every word is necessary; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description adequately covers the tool's purpose and the notable caveat about missing fields. For a simple retrieval tool, this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already documents the parameter. The description simply restates the route binding, adding minimal semantic value beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves data of a person ('Recuperação dos dados de uma pessoa'), which is a specific verb-resource pair. It distinguishes well from siblings like create_person, list_persons, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like list_persons. However, as a GET-by-ID operation, usage is implicitly understood for retrieving a single person's data.
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 readOnlyHint, openWorldHint, and destructiveHint. The description goes beyond by explicitly warning that 'some fields will not be returned' depending on the product, which adds valuable behavioral context 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: first clearly states the purpose, second provides a critical warning. No wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with good annotations, the description is adequate. It warns about missing fields, which is the main behavioral note. Lacks specifics on output structure but no output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the id parameter fully described in the schema. The tool description adds no additional parameter information, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves Plan data ('Recuperação dos dados de um Plano'), with a specific resource and verb. It distinguishes from sibling tools (e.g., list_plans) by focusing on a single plan retrieval, and adds a warning about field variability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving a specific plan by ID, but does not explicitly state when to use versus alternatives like list_plans or other get tools. No exclusions or alternative recommendations are provided.
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 mark it as read-only and non-destructive. The description adds valuable context about version-dependent field returns and a warning that some fields may not be returned, which exceeds annotation scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with essential information front-loaded. The warning is concise and relevant. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and existing annotations, the description covers the main behavioral nuance (version-dependent fields). The absence of an output schema is partially compensated by mentioning a table of returned fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the parameter is adequately described in the schema. The description does not add additional semantic meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it retrieves product data ('Recuperação dos dados de Itens/Serviços (produtos)') and distinguishes from siblings like list_products and create_product by focusing on a single product retrieval. The warning about version-specific fields adds clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for fetching a specific product by ID, but no explicit guidance on when to use this tool vs. list_products or alternatives. The version warning provides context but not usage boundaries.
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 readOnlyHint=true, openWorldHint=true, and destructiveHint=false, which the description does not contradict. The description adds valuable context: a warning that some fields may not be returned depending on the product/system. This goes beyond the annotations by alerting the agent to variability in 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences that front-load the purpose and provide a critical warning. Every word serves a purpose. No redundancy or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval with one parameter, no output schema, and strong annotations (readOnlyHint, openWorldHint), the description is complete. It explains what the tool does, the required input, and a caveat about variable output. Not detailing the response structure is acceptable given the openWorldHint and the warning.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter description ('Valor de :id na rota /recurringSale/:id') essentially restates the route parameter. The description adds no additional meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Recuperação das informações' / retrieve information), the resource ('Venda Recorrente' / recurring sale), and the identifier ('a partir do ID' / by ID). This is specific and distinct from sibling tools like list_recurring_sales.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is provided. Usage is implied for retrieving a single recurring sale by ID, but alternatives like list_recurring_sales are not mentioned. Given the tool's simplicity, the lack of explicit guidance is acceptable but not ideal.
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 read-only and non-destructive behavior. The description adds valuable context about pagination and the deprecation of the old model, going 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with front-loaded purpose. The warning is necessary but could be more integrated; overall efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, yet the description does not explain the response format or default ordering. It focuses on input and pagination, but misses return structure details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 100% schema coverage, the description clarifies that parameters expecting arrays can accept comma-separated values, and emphasizes the mandatory nature of 'limit' for new pagination, adding meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Listagem paginada de Contas' (paginated listing of Accounts), with a specific verb and resource. Among siblings, it uniquely identifies 'Accounts' as the resource, distinguishing it from other list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context about pagination and a mandatory parameter warning, but does not explicitly state when to use this tool vs. alternatives like get_account or other list tools for different entities.
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, destructiveHint. Description adds pagination behavior and comma-separated array values. No contradiction, but adds minimal extra context beyond 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose and array behavior, second provides critical pagination usage guidance. No filler, well front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple list tool with 4 optional parameters and no output schema. Covers pagination and array behavior. Could mention sorting or default ordering, but not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description mentions comma-separated multiple values for array items, but this is already detailed in each parameter's schema description. No added meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Listagem paginada de Contratos' (Paginated listing of Contracts), specifying the resource (Contracts) and operation (list/paginate). It distinguishes from siblings like `get_contract` (single) and `create_contract` (create).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
States that for new pagination the `limit` parameter is mandatory, and warns about deprecation of old pagination. Provides clear context on usage, though it does not explicitly list when to avoid this tool.
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 (safe read) and destructiveHint=false. The description adds the pagination behavior and array value format, but does not add significant behavioral content beyond what annotations provide. The warning about pagination version is useful but not extensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is three sentences, each serving a purpose: stating the operation, explaining array behavior, and warning about pagination deprecation. No fluff, front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with no output schema, the description adequately covers the pagination mechanism (crucial for correct usage) and the array value format. It does not describe the return structure but that is typical for list operations. The warning compensates for some missing context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description mentions that array parameters can have multiple comma-separated values and implies pagination parameters, but does not add meaningful detail beyond the schema's parameter descriptions. No extra semantics for parameter types or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Listagem paginada de Vendas Recorrentes' (paginated listing of recurring sales), with a specific verb (listar) and resource (vendas recorrentes). It distinguishes from siblings like get_recurring_sale (single) and create/update/delete operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description specifies that items defined as arrays can have multiple values separated by comma, and provides a critical warning about pagination: the new pagination requires the limit parameter, otherwise the old model will be used until deprecated in 2026. This guides usage of the parameter effectively.
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 the tool is not read-only and not destructive, which aligns with the description. The description adds detail on field constraints but does not disclose side effects, permissions, or limits beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear front-loaded purpose and structured parameter listing. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description thoroughly covers input parameters but lacks any information about return values or output, which is important since there is no output schema. This leaves the agent unsure of the response format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% as the description lists and explains all body parameters (name, type, showCustomerService) with required status, accepted values, and constraints, adding meaning beyond the generic schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates an extra field ('Criação de um Campo Extra'), with a specific verb and resource. It distinguishes itself from sibling tools like list_extra_fields, update_extra_field, and delete_extra_field.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating a new extra field but does not explicitly state when to use it versus alternatives. However, the context of a CRUD create tool makes it reasonably clear.
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 are minimal (readOnlyHint false, destructiveHint false). The description adds behavioral context by stating constraints (e.g., name must be unique) and listing required fields. However, it does not detail side effects or success/error outcomes beyond creation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long due to many parameters, but it is well-structured front-loaded with purpose followed by field list. Each field earns its place; no redundancy. However, could use bullet points for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Input is fully detailed, but there is no output schema or description of return values, error messages, or post-creation behavior. For a complex creation tool, this information would complete the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has only a generic body property, so the description provides all parameter details: types, required status, nested arrays, and examples. Schema coverage is 100%, and the description fully compensates with clear, structured field explanations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Criação de um plano' clearly stating the verb (creation) and resource (plan), and specifies its context 'utilizado no cadastro de contrato', distinguishing it from sibling tools like update_plan or delete_plan.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions usage in contract registration, but does not provide explicit when-to-use or when-not-to-use guidance, nor does it reference alternatives among siblings. More directive wording would improve.
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, destructiveHint=false, so the description does not need to restate safety. The description adds behavioral context about pagination modes and multi-value parameter support, but does not disclose additional behaviors such as rate limits, result ordering, or response format. It complements annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact with three sentences: the first states the purpose, the second adds a multi-value clarification, and the third provides a critical pagination warning. It is front-loaded and every sentence serves a clear purpose with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 13 parameters, no output schema, and moderate complexity, the description covers pagination and multi-value usage but lacks details on result behavior (e.g., default sort order, which fields are returned, or whether results are paginated with offset). It is adequate but not fully comprehensive for an agent to understand all nuances.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, setting baseline at 3. The description goes beyond by explaining that parameters defined as arrays (e.g., tagId, customerId) can accept multiple comma-separated values, and it emphasizes the mandatory nature of 'limit' for new pagination. This adds meaningful semantic guidance beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Listagem paginada de Cobranças' (Paginated listing of charges), clearly identifying the tool's purpose as a list operation for charge entities with pagination. It distinguishes itself from sibling tools like get_charge (single retrieval) and other list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides crucial guidance on pagination: it warns that to use the new pagination model, the 'limit' parameter must be provided; otherwise, the old model (to be deprecated in 2026) is used. This helps the agent choose the correct invocation. However, it does not explicitly compare with alternatives or provide when-to-use/not-to-use guidance.
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 readOnlyHint=true and destructiveHint=false. The description adds behavioral details about pagination modes (old vs new) and that array fields accept comma-separated values, enhancing transparency beyond 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences: purpose, array note, pagination warning. Front-loaded and concise without extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description does not describe return fields or format beyond the array note. Adequate for basic listing but missing output details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters. The description adds value by explaining the 'limit' parameter's role in new pagination and the comma-separated array behavior, which is not in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Listagem paginada de Meios de Pagamento' which specifies the action (list) and resource (payment methods). The name and title reinforce this, and it is distinct from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides implicit usage context by warning about the required 'limit' parameter for the new pagination, but does not explicitly state when to use this tool over alternatives or provide 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?
Annotations indicate it is not read-only (readOnlyHint=false) and not destructive (destructiveHint=false). The description adds that it edits sale information and specifies that sellerId requires API Token authentication. No contradictory behavior is mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a clear purpose line followed by a bullet list of parameters. It is somewhat verbose due to full parameter descriptions but remains easy to parse. Every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Input parameters are well-covered, but the absence of an output schema means the description should explain what the tool returns (e.g., the updated sale object). This gap reduces completeness for an agent expecting to use the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines id and body as a generic object. The description fully compensates by listing each body field (requesterId, sellerId, quantity, etc.) with type and constraints (e.g., integer >0, decimal, W3C date format). This provides critical meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is for editing one or more fields of an individual sale in the Conexa system. The verb 'edição' and resource 'venda avulsa' are specific, and it is easily distinguishable from sibling tools like create_sale or delete_sale.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives (e.g., create_sale for new sales, delete_sale for removal). The only contextual note is about authentication for sellerId, but no broader 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a write operation (readOnlyHint=false) and non-destructive nature. The description adds value by detailing the expected payload structure with a full example, though it does not discuss side effects, authentication, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy due to the full example, which is necessary for schema coverage. However, it could be more concise by summarizing key parameters upfront. The structure is clear but not optimally compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high complexity (many nested fields) and lack of output schema, the description provides a solid example but omits return value details (e.g., what is returned on success) and error handling. It is adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is minimal, only defining a 'body' object with no internal properties. The description fully compensates by providing an extensive example with all fields, nested objects, and comments, essentially documenting the parameters that the schema omits.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a person associated with a client in the Conexa system. The verb 'Criação' and resource 'pessoa' are specific, distinguishing it from siblings like 'create_customer' and 'create_potential_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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a warning about unnecessary fields depending on the product, providing context-sensitive guidance. However, it does not explicitly state when to use this tool versus alternatives like 'update_person' or 'create_customer'.
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 indicate destructiveHint=true and readOnlyHint=false; the description adds the critical precondition about associations, providing behavioral context beyond 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two-sentence description, front-loaded with verb and resource, no unnecessary words. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete-by-id tool with no output schema, the description provides essential context: action, precondition, and system association. Lacks mention of irreversibility, but destructiveHint covers it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with single parameter 'id' clearly described. Description does not add further parameter semantics, but baseline is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool deletes a person associated with a client, and adds a precondition. This distinguishes it from create_person, update_person, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when deletion is allowed (no links to sales/prints/correspondence), implicitly advising against use when links exist. Does not explicitly name alternative tools.
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 readOnlyHint=true and destructiveHint=false, so the tool is safe. The description adds behavioral context about the two pagination models and the deprecation timeline, which is valuable beyond 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences: purpose first, then array parameter handling, then a critical warning. No unnecessary words, front-loaded effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 optional parameters and no output schema, the description covers pagination behavior and parameter formatting. The schema already describes each parameter fully, so the description adequately complements it. Missing details about filter parameters are not needed since schema covers them.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds a note about array parameters accepting comma-separated values but does not significantly enhance meaning beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Listagem paginada de Despesas' (Paginated listing of Expenses), specifying the verb (list) and resource (bills/expenses). It distinguishes from sibling tools like 'list_bill_categories' which list categories, not bills.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on pagination: it warns that the limit parameter is mandatory for the new pagination model and that the old model will be deprecated. However, it does not mention when to use this tool over alternatives like 'list_charges' or 'list_sales'.
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 declare readOnlyHint=true, openWorldHint=true, destructiveHint=false. The description adds behavioral details beyond annotations: items defined as arrays accept multiple comma-separated values, and the tool has two pagination modes depending on whether 'limit' is provided. This gives practical behavioral transparency 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. The first sentence immediately states the core purpose (paginated listing). The rest provides essential usage details and a warning. However, it includes a vague reference to an example that might not be universally understood, slightly reducing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no output schema, and moderate complexity, the description covers pagination behavior and array filtering but lacks details about the response format (e.g., pagination metadata, structure of customer objects). The reference to an example is helpful but insufficient. A more complete description would explain what the API returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaningful context: the 'limit' parameter is mandatory for the new pagination, and array-type parameters accept multiple comma-separated values. While the schema already includes similar text for id and companyId, the emphasis on 'limit' being required for new pagination is an important addition that enhances parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as a paginated listing of customers. The verb 'Listagem' (listing) and resource 'clientes' (customers) are specific and unambiguous. The name 'list_customers' itself distinguishes it from sibling tools like get_customer or create_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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage context: it is a paginated listing tool. It gives explicit instructions about the 'limit' parameter being mandatory for the new pagination model and warns about upcoming deprecation. However, it does not explicitly state when not to use it or list alternatives, so it is slightly below top tier.
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 readOnlyHint (non-destructive) and openWorldHint. The description adds behavioral details: array fields can accept multiple comma-separated values, and the API will fall back to old pagination if 'limit' is omitted. No contradictions 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences: first states purpose, second explains array field behavior, third gives pagination warning. No redundancy, front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 4 optional parameters, the description covers critical aspects: pagination deprecation timeline and multi-value array behavior. It lacks explicit description of return structure, but for a list tool this is acceptable. The annotations already cover read-only and open-world hints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains each parameter. The description does not add new insights about parameters beyond what the schema provides. The note about array values applies to response fields, not parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Listagem paginada de Meios de Recebimento' (paginated listing of receiving methods), specifying both the verb (list) and resource (receiving methods) with pagination scope. It distinguishes from the sibling tool 'get_receiving_method' (singular) and other list_* tools by targeting a specific resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on pagination: it warns that to use the new pagination model, the 'limit' parameter is required; otherwise, the old model (to be deprecated) is used. It does not mention when not to use this tool versus alternatives, but the context of pagination transition is valuable.
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 readOnlyHint=true and destructiveHint=false, making safety clear. The description adds behavioral context: items defined as array accept comma-separated values, and the attention notice about pagination behavior. No contradictions. The description supplements annotations well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two core sentences plus a warning label. Every sentence adds necessary information. The purpose is front-loaded, making it efficient for an agent to parse. No extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high schema coverage and annotations providing safety, the description is largely complete. It covers pagination, array parameter usage, and deprecation warning. No output schema exists, but for a listing tool, the description provides sufficient operational context. Minor gap: no description of return structure, but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds minimal extra meaning beyond schema descriptions: it repeats that array parameters accept comma-separated values and stresses the limit requirement for new pagination. This is marginal value, hence score 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Listagem paginada de Reservas de Sala' (Paginated listing of Room Reservations), specifying the verb 'list', the resource 'room bookings', and indicating pagination. It distinguishes from siblings like get_room_booking (single) and cancel_room_booking. 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage guidance on pagination, explicitly stating that the 'limit' parameter is mandatory for the new pagination model and warns about the deprecation of the old model. It does not explicitly differentiate from other list tools, but the resource specificity and pagination context are clear.
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 readOnlyHint=true and destructiveHint=false. The description adds behavioral details about pagination behavior depending on the limit parameter and the ability to pass multiple values as comma-separated strings. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with the core purpose upfront and a clear warning. It could be slightly more efficient, but no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does not explain return values or structure. It covers input pagination but omits output fields. Given the complexity of a listing tool with multiple filters, this is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for each parameter, but the description adds meaningful usage context: the warning about the limit parameter for new pagination and the note that array items accept comma-separated values, which goes beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Listagem paginada de Fornecedores' (paginated listing of suppliers), with a specific verb (listagem) and resource (fornecedores). It distinguishes from siblings like get_supplier (single) and other list_* tools by specifying the resource, and adds pagination context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on using the limit parameter for the new pagination model, including a note about its future deprecation. However, it does not explicitly state when to choose this tool over sibling list tools, though resource naming makes it clear.
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 non-destructive write operation. Description adds context: only sent fields are updated, missing fields keep current value, and a constraint on showCustomerService. No contradictions 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with a clear front-loaded purpose and subsequent field details. It is efficient but could be more structured with bullet points or explicit sections.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers key behavioral aspects and constraints. Lacks information on response format (e.g., returns updated object or status) and error conditions. For a PATCH tool with no output schema, this is a moderate gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters but body schema is generic. Description fully documents body fields (name, type, showCustomerService) with constraints and allowed values, adding essential meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Atualização parcial de um Campo Extra' (partial update of an Extra Field), using a specific verb and resource. It distinguishes from siblings like create_extra_field, delete_extra_field, and get_extra_field.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives like create_extra_field or delete_extra_field. It implies usage for modifying existing fields but lacks direct guidance or 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?
Annotations already indicate readOnlyHint=true and openWorldHint=true, so the tool is known to be non-destructive and idempotent. The description adds the context of authentication checking but does not reveal additional behavioral details 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. Front-loaded with purpose, followed by usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple connectivity test with no parameters and no output schema, the description fully covers what the agent needs to know: what it does and when to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has zero parameters, so no parameter description is needed. The description does not need to compensate for schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool verifies authentication connectivity with the Conexa API. The verb 'verifies' and resource 'authentication' are specific. Distinct from siblings which are CRUD operations on entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use after installation to confirm configuration. No direct exclusions or alternatives, but the simplicity of the tool (no parameters) makes this guidance sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond annotations: it explains pagination requirements, the array data behavior (multi-values separated by comma), and the deprecation timeline. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, using a single paragraph with a clear warning. It could be slightly more structured, but wastes no words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite explaining pagination and array behavior, the description lacks details about the return structure (e.g., fields of extra field items). With no output schema, this gap reduces completeness for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is 3. The description adds extra value by explaining the limit parameter's role in pagination and the array behavior, though it does not elaborate on other parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The title and description clearly state 'Listagem paginada de Campos Extras', specifying the verb (list) and resource (extra fields). It distinguishes from sibling tools with similar names like get_extra_field, effectively communicating its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a warning about mandatory provision of the limit parameter for new pagination, providing actionable guidance. However, it does not explicitly compare with alternatives or state when not to use the tool.
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 readOnlyHint=true and destructiveHint=false. The description adds that the tool supports pagination, that array parameters accept comma-separated values, and that the API has a deprecation timeline for old pagination. This supplements the annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences and a warning, with no fluff. The first sentence states the purpose, the second explains array behavior, and the third highlights a critical constraint. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 parameters, no output schema), the description covers the main aspects: purpose, pagination behavior, parameter usage, and a deprecation warning. It does not describe the return format, but the annotations and schema compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers all parameters with descriptions (100% coverage). The description adds that the limit parameter is required for the new pagination and that array fields accept comma-separated values—information that clarifies usage beyond the schema's base descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Listagem paginada de Planos' (Paginated listing of Plans), specifying the action (list), resource (plans), and pagination. This distinguishes it from sibling tools like get_plan (single plan) and other list_ tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a critical usage guideline: the limit parameter is mandatory for the new pagination, and not providing it triggers the deprecated old model. However, it does not explicitly contrast with other list_ tools or specify when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds behavioral details: items defined as array can have multiple comma-separated values, and it warns about the pagination migration timeline. 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, front-loaded with the core purpose, followed by a critical usage warning. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description covers the essential aspects: purpose, pagination migration, and array behavior. Given the tool's simplicity and annotations, this is complete enough for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for each parameter. The description adds value by explaining the comma-separated array behavior and the pagination requirement (limit parameter). This goes beyond the schema's individual parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Listagem paginada de Serviços/Itens' which translates to paginated listing of services/items. It is a specific verb and resource, distinguishing it from sibling tools like create_product, delete_product, get_product, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes an important usage guideline: the requirement to use the 'limit' parameter for the new pagination model, with a note about deprecation. It does not explicitly state when to use alternatives, but the context of a listing tool is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, destructiveHint=false, which the description aligns with. It adds behavioral details: pagination modes, deprecation timeline, and the ability to pass multiple values in array fields, exceeding 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each with clear purpose: first states the paginated list, second clarifies parameter behavior and pagination requirement. No superfluous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even without an output schema, the description covers pagination, filtering, and the critical deprecation notice. It is complete for a list endpoint given the complexity and annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value by explaining that array-defined parameters accept multiple values (generalizing beyond the id parameter). It also stresses the importance of the limit parameter for the new pagination model, adding context not present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (listagem paginada) and resource (Centros de Custo). It distinguishes from the singular sibling 'get_cost_center', making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly warns about the new pagination: mandatory limit parameter for new pagination, and deprecation of the old model. Also explains that array parameters accept multiple comma-separated values. This gives clear guidance on when and how to use the tool.
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:

[![conexa-mcp MCP server](https://glama.ai/mcp/servers/Expert-Integrado/conexa-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Expert-Integrado/conexa-mcp)

Score Badge

Copy to your README.md:

[![conexa-mcp MCP server](https://glama.ai/mcp/servers/Expert-Integrado/conexa-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Expert-Integrado/conexa-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/Expert-Integrado/conexa-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server