mdia-feegow-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, aided by category prefixes like [Agendamentos]. However, there is ambiguity between 'feegow_available_schedule' and 'feegow_available_schedule_v2' (two versions with unclear differences), and the large number of appointment-related tools could cause confusion despite distinct descriptions.
Naming Consistency4/5
The vast majority of tools follow a consistent 'feegow_verb_noun' pattern (e.g., list_professionals, create_appointment). A few exceptions like 'feegow_dmed', 'feegow_status', and 'feegow_request' deviate from this pattern, preventing a perfect score.
Tool Count1/5
97 tools is extremely high for an MCP server, far exceeding the typical 3-15 range. While the Feegow system is complex, this number overwhelms an agent and makes tool selection difficult, warranting the lowest score.
Completeness2/5
The tool surface covers many areas (appointments, finances, patients, etc.) but has significant gaps: no tools to create, update, or delete professionals; no delete patient; no single appointment retrieval by ID. These missing CRUD operations will cause agent failures.
Average 3.3/5 across 97 of 97 tools scored. Lowest: 2.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 7 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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the HTTP method (GET) and endpoint, but does not disclose any behavioral traits such as read-only nature, pagination behavior, authentication requirements, or potential 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 short and front-loaded, but it is under-specified. While concise, it sacrifices necessary detail, making it barely adequate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of 4 parameters, no output schema, and no annotations, the description is severely incomplete. It fails to explain return format, how results are structured, or how this tool differs from its sibling listing tools.
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 each parameter described in the schema. The description adds no additional meaning to the parameters; it simply restates the generic action. Baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool obtains information from private tables, but it does not highlight that it specifically lists 'external' private tables, which distinguishes it from the sibling tool 'feegow_list_private_tables'. The purpose is clear in a generic sense but lacks 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?
The description provides no guidance on when to use this tool versus alternatives like 'feegow_list_private_tables' or other listing tools. It does not mention use cases, 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?
No annotations provided. The description mentions HTTP GET, implying read-only, but does not disclose rate limits, error behavior, pagination, or the effect of parameters like query, offset, limit. Minimal behavioral context beyond the endpoint.
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 short (one simple sentence plus a parenthetical). It front-loads domain and purpose but omits critical details, making it incomplete rather than efficiently concise.
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 7 parameters, no output schema, and no annotations, the description is insufficient. It fails to explain data scope, filtering (dates, units), pagination, or typical usage patterns for a finance query tool.
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?
Schema description coverage is 57%. The description only repeats the CPF format already in the schema (11 digits). It adds no meaning for undocumented parameters (limit, offset, unidadeId) and does not explain the nested 'query' object behavior.
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 queries DMED data (tax receipts for declaration), which is a specific financial resource. The verb 'Consulta' (query) and resource 'DMED' are clear. However, it does not distinguish from sibling tools, though no direct sibling with 'dmed' exists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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., other financial tools like feegow_list_invoices). Only a constraint on CPF format is mentioned, but not when to avoid or fallback to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description only states it is a GET request to list invoices, but does not disclose safety (read-only), authentication needs, rate limits, or pagination behavior.
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 short and includes a prefix and endpoint. It is efficient but lacks structure and important details beyond the bare minimum.
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, no annotations, and an undocumented query parameter, the description is incomplete. It does not explain the return format, filtering options, or pagination, which are critical for a list endpoint.
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 schema has one parameter (query object) with 100% coverage but the description adds no information about valid keys or values. It merely restates what the schema already shows.
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 lists financial accounts/invoices and includes the HTTP endpoint. However, it does not distinguish itself from similar siblings like feegow_find_invoice_by_nfse or feegow_create_invoice.
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. There are many financial sibling tools, but the description provides no context on selection criteria or prerequisites.
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 mentions 'HTTP GET', implying read-only behavior, but with no annotations and no further behavioral details (e.g., authentication, rate limits, data scope), it falls short. The burden is on the description since annotations are absent.
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 extremely concise, but at the expense of clarity and completeness. It is appropriately front-loaded but omits critical information, making it barely adequate.
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 absence of an output schema and annotations, and the presence of two parameters (including a generic 'query' object), the description is too sparse to fully inform an agent. It lacks details on return format, pagination, or required inputs.
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?
Only one of two parameters ('query') has a schema description; 'paciente_id' lacks any description. The tool description adds no parameter details beyond what the schema provides, and with 50% coverage, the description fails to compensate.
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 action ('retorna') and resource ('timeline do prontuário de um paciente'), and includes the HTTP method for extra clarity. However, it does not differentiate from other patient-related tools like feegow_list_patients or feegow_search_patient, though no sibling has an identical purpose.
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 prerequisites or conditions. The description merely states what it does without context on 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?
No annotations are provided, so the description must communicate behavioral traits. It only states the tool lists insurances, but does not mention if it is read-only, whether authentication is needed, or any side effects. The lack of detail leaves the agent underinformed.
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 extremely short, consisting of one sentence and an endpoint annotation. While it is concise, it omits essential information. It is not verbose but also not well-structured for quick consumption by an AI agent.
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 tool has 2 parameters (one nested), no output schema, and no annotations, the description should provide more context about return format, pagination, or authentication. It does not, leaving the agent with insufficient information to use the tool effectively.
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 schema covers 50% of parameters (only 'query' has a description). The tool description adds no parameter-level information, such as what 'profissional_id' expects or how 'query' is used. With only half the parameters described in the schema, the description should compensate but fails to do so.
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 that the tool lists the insurances accepted by a professional. It includes the HTTP method and endpoint, making the action and resource specific. However, it does not explicitly differentiate from sibling tools like feegow_list_insurances, which may have broader 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?
The description provides no guidance on when to use this tool over alternatives, such as feegow_list_insurances for all insurances. There is no mention of prerequisites, limitations, or use cases. The agent receives no context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description only mentions it's a GET and returns info/specialties. Fails to disclose behavioral traits like auth needs, rate limits, or what happens on not found.
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?
A single sentence including the endpoint; concise but lacks depth. Could be more informative without verbosity.
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 annotations, and unhelpful parameter docs make the description incomplete. It omits output format, error handling, and filtering details.
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?
Three parameters with only one generic description for 'query'. The tool description adds no meaning to 'i' or 'profissional_id', leaving their roles unclear. Low schema coverage (33%) is not compensated.
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 returns information and specialties of a professional, with the HTTP endpoint. It distinguishes from sibling tools like feegow_list_professionals by focusing on a single professional, but does not explicitly contrast.
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, no prerequisites or exclusions. Simply states what it does without 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?
With no annotations, the description carries full transparency burden. It indicates an HTTP GET (implying read-only) and date format, but fails to disclose authentication requirements, pagination, error handling, or what happens when no slots are available. The behavior is minimally described.
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 (two sentences) and front-loaded with the purpose and version. However, the inclusion of the HTTP method and path in parentheses adds minor clutter; a slightly more structured format could improve readability without sacrificing conciseness.
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 explain the return format (e.g., list of time slots with IDs, times, professionals). It does not, nor does it address the optional nature of all 7 parameters. The tool is a list operation, but completeness is lacking for an agent to use effectively without trial and error.
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?
Schema coverage is 57%, and the description only adds meaning for 'data_start' and 'data_end' by specifying format (dd-mm-yyyy). Parameters like 'procedimento_id', 'profissional_id', 'especialidade_id', and 'query' are left without additional context beyond their names and type 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?
The description clearly states the tool lists available schedules (horários disponíveis) and identifies it as endpoint V2, distinguishing it from the probable V1 sibling 'feegow_available_schedule'. However, it does not elaborate on the scope or filtering capabilities beyond date range.
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 'feegow_professional_agenda' or 'feegow_create_appointment'. The description does not mention contexts or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavioral traits. It only indicates an HTTP GET (suggesting idempotency) but lacks details on side effects, error handling, or return format.
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, one line, including a category label and HTTP method. It is front-loaded with the key action, though it could be slightly more 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?
The description lacks completeness for a simple lookup tool. No output format, behavior on missing data, or pagination is mentioned, relying solely on the schema for parameters.
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?
Schema coverage is 100%, but the description adds no meaning beyond the schema. It mentions 'número da NFS-e' implicitly, but does not elaborate on the parameters or their usage.
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 invoices by NFS-e number, using a specific verb and resource. However, it does not explicitly differentiate from sibling tools like feegow_list_invoices or feegow_update_invoice_nfse_number.
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 usage guidance is provided. The description does not indicate when to use this tool versus alternatives, nor does it mention 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?
No annotations are provided, so the description must disclose behavioral traits. It only states 'Visualiza um laudo' (views a report) and the HTTP method, but does not mention whether it is read-only, any required authentication, side effects (none expected for GET), or rate limits. The description lacks sufficient detail for safe invocation.
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 free of fluff. It front-loads the category ('[Laudos]') and provides the HTTP endpoint. However, it could be slightly longer to include key usage details without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and three parameters with minimal description, the tool definition is highly incomplete. The description does not explain what the tool returns, how to properly set parameters, or any constraints (e.g., required parameters). An agent cannot reliably use this tool without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 33% schema description coverage (only 'query' described generically), the description adds no meaning to the parameters. It does not explain the role of 'agendamento_id' or 'procedimento_id', nor how they relate to viewing a medical report. The description fails to compensate for the low 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?
The description clearly states the verb 'Visualiza' (views) and the resource 'laudo registrado' (registered medical report), and the HTTP GET method is provided. This distinguishes from siblings like list_medical_reports (list) and create_medical_report (create), indicating a specific retrieval operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like feegow_list_medical_reports or feegow_create_medical_report. There is no mention of prerequisites, exclusions, or when to prefer this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral traits beyond implying a read operation via the HTTP GET. No mention of side effects, authorization needs, 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 extremely concise with no redundant information. However, it may be too brief to fully inform the agent, but it is structurally efficient.
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 simple schema and lack of annotations, the description should provide more context about what channels represent, possible response formats, or usage notes. It falls short of being complete.
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 input schema parameter 'query' has a generic description that provides no meaningful guidance. The tool description adds no further explanation, leaving the parameter's purpose unclear.
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 lists appointment channels, with the HTTP endpoint for reference. It is specific and distinguishes it from sibling tools, which cover different resources.
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, nor any prerequisites or exclusions. The agent is left to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action and resource, without mentioning pagination, authentication requirements, rate limits, or any side effects. This is insufficient for safe invocation.
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 line containing a category tag and the HTTP endpoint. It is concise and front-loaded with the verb. However, it sacrifices useful information for brevity.
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 tool has no output schema, no annotations, and two parameters (including a loosely defined 'query' object), the description is incomplete. It fails to cover expected response format, filtering capabilities, or usage constraints, leaving the agent without enough context to interpret results.
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?
Schema description coverage is 50% (one param described, one not). The description adds no meaning beyond the schema—it does not explain the 'query' object's expected keys or the role of 'paciente_id'. The URL path hints at patient_id but not in the 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 lists medical records/diagnoses of a patient, specifying the verb 'Lista' and resource 'prontuários/diagnósticos'. However, it does not differentiate from other list tools like feegow_list_procedures or feegow_list_prescriptions among the many siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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, no when-not-to-use instructions, and no mention of prerequisites or context. The agent is left to infer usage from the name and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description must carry full burden. It does not disclose that this is a read-only operation, any authentication requirements, rate limits, or side effects. Basic purpose is stated but lacks behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise, one sentence with category and endpoint. Front-loaded with purpose. However, it sacrifices substance for brevity.
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 annotations, single vague parameter. Missing details on return format, pagination, sorting, or required filters. Incomplete for effective use without additional context.
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 single parameter 'query' is described as a catch-all for additional parameters, but the description adds no semantic meaning beyond the schema. It doesn't list acceptable keys or expected values, leaving the agent guessing.
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 lists medical transfers ('Lista os repasses de médicos') and includes the HTTP endpoint. It distinguishes from sibling tools like feegow_list_invoices by specifying 'medical transfers', but could be more explicit about what 'repasses' entails.
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 alternative listing tools (e.g., feegow_list_invoices, feegow_list_vouchers). No when-not 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavior. It merely states it lists dependents, but omits details like required input (paciente_id likely needed), result format, or side effects. The read nature is implied but not explicit.
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 extremely concise—one short sentence—and front-loaded with the purpose. It is not verbose, but the brevity sacrifices completeness. Still, every word earns its place.
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 annotations and output schema, the description fails to provide sufficient context. It does not explain return values, error handling, or parameter requirements, leaving the agent with significant gaps for correct invocation.
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?
Schema coverage is 50% with two parameters. The description adds no meaning to 'paciente_id' or the 'query' object. The tool name implies paciente_id is key, but no explanation of how to use it or what query parameters are allowed.
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 action ('Lista' / list) and resource ('dependentes de um paciente' / dependents of a patient). It distinguishes from sibling tools like feegow_list_patients by specifying dependents. However, it does not elaborate on scope or output format.
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., feegow_search_patient or feegow_list_patients). The description lacks context about prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully disclose behavior. It only states the tool returns a schedule; it does not mention authentication, side effects, or any limitations (e.g., date ranges, availability constraints).
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, including the HTTP method and endpoint. It is front-loaded with the purpose, but could omit the endpoint reference if it adds no semantic value.
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 tool's complexity (2 parameters, no output schema, no annotations), the description is insufficient. It lacks details on expected return format, required inputs, and usage constraints, making it incomplete for an agent to use reliably.
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?
With 50% schema coverage and no parameter annotations in the description, the tool fails to explain the 'profissional_id' parameter. The 'query' parameter is vaguely described. The description adds no value 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 the tool returns the agenda (schedule) of a professional, using a clear verb-resource pair. However, it does not differentiate from similar tools like feegow_available_schedule, which also deals with schedules.
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., feegow_available_schedule) or any 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?
No annotations are present, so the description carries full responsibility. It only indicates the HTTP endpoint and basic action, but does not disclose pagination, required authentication, or other behavioral traits (e.g., date range filtering).
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, efficiently conveying the primary purpose. It could include more detail 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 complexity of the tool (2 params, no output schema, many siblings), the description is insufficient. It does not explain what the response contains, how to use the query parameter, or handle potential errors.
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 schema covers 50% of parameters descriptively, but the description adds no meaning to the two parameters. The profissional_id parameter is hinted by 'de um profissional' but not explicitly explained. The query object is ignored.
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 lists appointments for a professional ('Lista os agendamentos de um profissional'), distinguishing it from the more general feegow_list_appointments sibling. It does not explicitly name the alternative, but the purpose is evident.
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 feegow_list_appointments or feegow_agenda. The description only 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?
With no annotations, the description should disclose behavioral traits but only states the action. It does not mention that the tool is read-only (though HTTP GET suggests it), required authentication, error behavior (e.g., invalid ID), or any side effects. The minimal description lacks transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at one sentence, with no fluff. However, it could be structured to separate the category from the action, and it omits useful details that would make it more valuable. It earns its conciseness but at the cost of completeness.
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 tool is simple with two parameters. But the description does not describe the return value, error handling, or authentication. For a price retrieval tool, an agent would need to know the expected output format or potential errors. The description is incomplete for making informed decisions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not add meaning to the parameters beyond the input schema. The schema coverage is 50% (only 'query' has a description), and 'agendamento_id' is not explained in either schema or description. The description fails to clarify what 'agendamento_id' represents or how to use the optional 'query' object.
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 that the tool returns the price associated with an appointment, using a specific verb and resource. It includes a category '[Agendamentos]' and the HTTP endpoint, which distinguishes it from sibling tools like feegow_list_appointments or feegow_create_appointment that focus on other appointment operations.
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 does it mention prerequisites or context such as requiring an appointment ID. It simply states the function without any contextual 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?
No annotations provided, so the description must carry full behavioral disclosure. It only states the HTTP method and endpoint, omitting side effects, permissions, limits, or return 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?
Extremely concise: two sentences front-loading purpose and endpoint. No redundant information.
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 and minimal description, the agent lacks understanding of return data (e.g., table format) and how this differs from feegow_list_external_private_tables. Incomplete for effective use.
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?
Schema coverage is 100%, so baseline is 3, but the description adds no extra meaning for the 'query' parameter. It merely reiterates that additional parameters are allowed without hinting at valid keys or values.
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 lists private price tables, using specific verb and resource. However, it does not distinguish from sibling 'feegow_list_external_private_tables'.
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 feegow_list_external_private_tables or other list tools. 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?
No annotations provided, and the description does not disclose behavioral traits such as pagination, sorting, permissions, or side effects. It only states the HTTP method, leaving much unknown.
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 concise (single line) but lacks structure. It contains essential info but could be more organized with bullet points or sections.
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 5 parameters (including a nested object) and no output schema, the description is insufficient. It does not explain return format, pagination, or how the query parameter is used.
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 80%, with most parameters described. The description adds minimal extra meaning beyond mentioning period/patient filtering; it does not explain tipo_data or the query parameter 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?
The description clearly states the tool lists proposals by period or patient, with the HTTP endpoint. It provides a specific verb and resource, but does not explicitly differentiate from sibling list tools like feegow_list_proposals_by_date.
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., feegow_list_proposals_by_date). The description only mentions filtering by period/paciente, but lacks context on appropriate scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description only implies a read operation via HTTP GET but lacks details on authentication, rate limits, 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise but lacks structure; it includes a category tag and HTTP method but no additional context.
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 and minimal description, the tool lacks completeness for an agent to understand return values or filtering capabilities.
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 'query' is fully described in the schema as additional query parameters, so the description adds no extra meaning.
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 lists available reports, but does not differentiate from sibling tool 'feegow_list_medical_reports'.
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 'feegow_list_medical_reports' or other list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the action and endpoint. It does not disclose any behavioral traits such as side effects, authorization requirements, or data 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 concise with one sentence and endpoint, but it is too brief to be fully informative. It follows no structure beyond a simple statement.
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 it is a list tool with no output schema and no annotations, the description is insufficient. It omits details about pagination, filtering, sorting, and response format, making it incomplete for an agent to invoke correctly.
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 schema has 100% coverage for the single parameter 'query', which is described as additional query parameters. The description adds no extra meaning beyond the schema, so baseline score of 3 applies.
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 lists suppliers and includes the HTTP endpoint. It differentiates from the sibling 'feegow_get_supplier' by the verb 'list' vs 'get', but does not explicitly distinguish 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 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 'feegow_get_supplier' or other list tools. The description does not provide any context for choosing 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?
The description mentions HTTP GET, implying read-only behavior. However, it does not explicitly state safety or disclose any potential side effects, rate limits, or return format. Without annotations, the description partially fulfills transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, consisting of a single sentence. It efficiently conveys key information, though it could be slightly more 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?
With no output schema and eight parameters, the description is insufficient. It does not explain the output structure or how parameters interact, leaving significant gaps for an AI agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, but the description only adds meaning for one parameter (tipo) and the date format. The other parameters (unidade_id, procedimento_id, etc.) are not explained, failing to compensate for the lack of schema descriptions.
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 lists available appointment schedule times, specifying the date format and tipo parameter. It is specific about the resource and verb, but does not differentiate from the sibling feegow_available_schedule_v2.
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 feegow_available_schedule_v2. There are no prerequisites or context 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?
With no annotations, the description must disclose behavioral traits. It only states the HTTP method (GET) and basic action, omitting details on idempotence, required permissions, or side effects. More context is needed for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with the category prefix and HTTP endpoint, providing essential information without redundancy. It is well-structured 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 is provided, and the description fails to clarify the return value or how the retrieved guide is represented. Given four parameters and the retrieval nature, the description is incomplete for effective use.
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 parameters are already well-documented in the schema (e.g., billing_type_id enum values). The description adds no additional meaning, meeting 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 clearly states it searches for a billing guide based on the agreement, and the HTTP GET method indicates a read operation. However, it does not explicitly state that it retrieves by specific IDs like billing number, insurance, and type, leaving some ambiguity.
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 feegow_insert_billing_guide or feegow_edit_billing_guide. The description lacks context for appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not disclose safety, auth, rate limits, or pagination. It mentions HTTP GET indicating read-only, but lacks behavioral depth.
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?
Single sentence with endpoint, efficient and to the point. No wasted words, but could benefit from additional details 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?
Has no output schema and does not describe return format or pagination. Given 6 optional parameters and a nested query object, the description is too minimal for complete understanding.
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 each parameter is described in the schema. The description adds context about filter formats (DD-MM-YYYY) and endpoint, but does not significantly extend meaning beyond 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 lists agenda blocks with filters (identification, period, professional, unit). The verb and resource are specific, but no explicit differentiation from sibling tools like feegow_professional_agenda, though the name helps.
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 what it does, with no when-to-use or when-not-to-use 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?
With no annotations provided, the description is the sole source of behavioral info. It adds that values are in cents and the HTTP method, but fails to disclose read-only nature, authorization needs, or any side effects. Minimal disclosure.
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—two sentences plus endpoint—and front-loads the purpose. It could be more structured by separating the endpoint, but overall efficient with no filler.
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 complexity of listing 'imported franchise records' among many similar tools, the description lacks context about what makes these records unique. There is no output schema, and the return value is only vaguely described as 'procedimentos e seus valores.' Incomplete for agent usage.
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 descriptions for all parameters. The description adds no additional meaning to the parameters beyond what the schema already provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Lista todos os procedimentos e seus valores' clearly states the action (list) and resource (procedures with values). However, it does not differentiate from sibling tools like 'feegow_list_procedures' which may have a similar purpose, lacking specificity about 'imported franchise records'.
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 'feegow_list_procedures' or 'feegow_get_price'. The description does not mention context, 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?
No annotations are provided, so the description must carry the full burden. It mentions GET (implying read-only) but does not disclose pagination, filtering capabilities, or response structure. Minimal behavioral insight.
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 no wasted words and front-loaded. However, it is extremely brief and could provide more value 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 minimal description, the tool provides insufficient context for an agent to understand the response format or usage constraints. Important details are missing for a complete understanding.
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 parameter, so baseline is 3. The description does not add any additional meaning to the 'query' parameter beyond what is 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?
The description clearly states 'Lista os locais de atendimento' (list service locations) and includes the HTTP endpoint, making the purpose specific. However, it does not differentiate from sibling tools like feegow_list_units or feegow_list_professionals.
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. The description only states what it does, with no context on prerequisites or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description adds no behavioral disclosure. It does not mention pagination, sorting, rate limits, required permissions, or what happens with missing filters. The HTTP method is indicated, but this is minimal. The agent lacks insight into the tool's runtime behavior.
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—only one sentence with the endpoint. It is concise and front-loads the action and resource. However, it could include a brief list of filter types without losing conciseness. The current length is acceptable for a list endpoint.
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 tool has 8 parameters, no output schema, and no annotations, the description is insufficient. It omits what the response contains (e.g., procedure IDs, names, types), pagination details, and how filters interact. An agent cannot reliably use this tool based solely on the description.
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 50% (4 of 8 parameters have descriptions). The description does not add any parameter information beyond the schema; it only says 'com filtros opcionais' (with optional filters). For the 4 undocumented parameters (i, unidade_id, procedimento_id, profissional_id), the description offers no help. Baseline 3 is appropriate as the schema does some work but the description fails to compensate for gaps.
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 lists procedures with optional filters. It uses a specific verb ('Lista') and resource ('procedimentos'), making the purpose evident. However, it does not distinguish from sibling tools like feegow_list_procedure_bundles or feegow_list_procedure_insurances, which could confuse an agent selecting among similar 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 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., feegow_list_procedure_bundles, feegow_procedures_by_professional). There is no mention of prerequisites, context, or situations where this tool is not appropriate. The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It does not disclose behavioral traits such as read-only nature, idempotency, authentication requirements, or rate limits. The word 'obtém' implies a read operation, but that is not explicit.
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 (one line plus endpoint) and front-loaded with the essential information. It is concise but could be more informative 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?
No output schema exists, and the description does not explain the return format or structure of product locations. For a list tool, this is a notable gap. The input schema covers only the request body.
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 high (100%). The description adds no extra meaning beyond what the schema already provides for 'body' and 'query'. 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 action ('Obtém a lista de localizações do produto') and the resource ('produto'). It includes the HTTP method and endpoint for reference. No sibling tool has the same function, so differentiation is implicit.
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, prerequisites, or context. The description merely states what it does without any usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states it lists professionals. It does not disclose behavior such as pagination, ordering, or whether it returns all professionals. The HTTP method is noted, but that is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and to the point, with no wasted words. However, it lacks structure such as mention of output format or examples.
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?
For a list tool with no output schema and no annotations, the description is underspecified. It does not clarify result format, pagination, or how to use the query parameter effectively, especially given the many sibling tools.
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 a single parameter 'query' with coverage 100%. The description adds no further meaning beyond the schema. Baseline 3 is appropriate since schema already covers the 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 lists registered professionals (verb+resource). However, it does not explicitly differentiate from the sibling feegow_search_professional, which likely handles filtering.
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 like feegow_search_professional. No context, prerequisites, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. Although it implies a read-only operation via GET, it does not explicitly state read-only behavior, auth requirements, rate limits, or pagination. Minimal 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 extremely concise with two short sentences, no unnecessary words, and front-loads the core purpose. Every element serves a clear function.
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 tool has 2 parameters, no required ones, a nested object, and no output schema, the description is too sparse. It lacks details on returned data, filtering options, or any behavioral traits, making it incomplete for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning to the parameters. The schema has 50% coverage (only 'query' has a description) but the description fails to clarify the 'i' parameter or the structure of the 'query' object, leaving the agent with incomplete information.
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 'Lista as especialidades cadastradas' clearly specifies the verb (list) and resource (specialties), distinguishing it from sibling list tools like feegow_list_professionals. The inclusion of the HTTP endpoint reinforces the action.
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. There is no mention of prerequisites, use cases, or exclusions, leaving the agent to infer appropriateness.
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 mentions it is a write operation ('altera dados') and requires a specific environment variable, which partially addresses behavioral transparency. However, it does not disclose any side effects, response behavior, or idempotency. Since no annotations are present, the description carries full burden and falls short.
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 concise, using a single sentence with appended notes. It is efficient and uses bracketed labels for quick scanning. However, the structure could be improved by placing the most critical information (purpose) first.
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 complexity of the nested input schema and the lack of an output schema, the description is insufficient. It does not explain the movement logic, field relationships, error handling, or result format. This is inadequate for a write tool with many sibling tools.
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 schema already provides descriptions for all parameters (100% coverage), so the tool description adds limited value. It reinforces the date format requirement, but does not explain the semantics of the nested fields or the 'query' parameter beyond what the schema 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 it registers product movement in stock, which is specific enough to distinguish from entry/exit tools. The HTTP endpoint and tags further clarify the resource. However, it could explicitly differentiate from feegow_entry_product and feegow_exit_product.
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 vs alternatives like entry/exit. It does mention the date format and write permission requirement, but no exclusionary context or use-case description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description does not disclose any behavioral traits (e.g., pagination, permissions, side effects), relying solely on the HTTP method implied by the endpoint.
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, with no wasted words, and front-loads the core action and resource.
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 simple schema but no output schema or annotations, the description is minimal and does not clarify what a 'grupo de procedimento' is or what the response contains.
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 only parameter 'query'. The description adds no additional meaning beyond what the schema already 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 states the resource ('grupos de procedimento') and the action ('Lista'), but does not differentiate from sibling tools like feegow_procedure_types or feegow_list_procedures.
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; no context provided beyond the basic action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the HTTP method and endpoint, implying a read-only operation, but does not disclose behavior for invalid IDs, pagination, or response format. This is minimal disclosure.
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 followed by the endpoint. It is concise and front-loaded with the purpose. No unnecessary words, though the endpoint may be redundant with the tool name.
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 and no annotations, the description is too brief. It does not explain what data is returned, any default behavior, or error scenarios. For a simple list tool with many siblings, more context would be helpful.
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 adds no information beyond what the schema already provides. The description does not elaborate on parameter usage or constraints, so it meets the baseline but provides no additional value.
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 lists procedures enabled for a professional. The verb 'Lista' and resource 'procedimentos habilitados para um profissional' are specific. Although it does not explicitly differentiate from siblings like feegow_list_procedures, the tool name itself implies the distinction by professional.
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 such as feegow_list_procedures or feegow_procedures_by_specialty. The agent must infer usage from the name alone, which is insufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description bears full responsibility for behavioral disclosure. It only states the endpoint and action, omitting details like authentication, rate limits, pagination, 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 concise and front-loaded, including the category and HTTP method in a single sentence. However, it lacks structure that could 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?
Given the tool's simplicity (one flexible parameter, no output schema, no annotations), the description is minimal and does not explain response format, filtering, or relationship to sibling tools. More context is needed for adequate 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 input schema has one parameter (query) with a description covering 100% of schema properties. The tool description adds no additional semantics beyond the schema's description of additional query parameters.
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 uses specific verb 'Lista' and resource 'tipos de procedimento', clearly indicating it retrieves procedure types. It implicitly distinguishes from siblings like feegow_list_procedures by naming different resources.
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 usage guidelines are provided. The description does not indicate when to use this tool versus alternatives such as feegow_list_procedures or feegow_procedure_groups.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It mentions the HTTP GET method, implying read-only, but fails to disclose behavior like error handling, authentication needs, or what happens if no patient found.
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?
Extremely concise: one sentence with key purpose, followed by endpoint. No wasted words; front-loaded with essential information.
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 and 4 parameters (including a poorly defined nested object), the description is too minimal. It does not explain return format, pagination, or how to use the 'query' parameter for additional filters.
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 50%. The description adds value by explaining the 'photo' parameter and clarifying that 'paciente_id' and 'paciente_cpf' are search keys. However, the 'query' parameter remains under-documented.
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 searches a patient by ID or CPF, and mentions the optional photo parameter. It distinguishes from sibling tools like feegow_list_patients by specifying search criteria.
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 feegow_list_patients or feegow_create_patient. The description implies usage when ID or CPF is known, but does not state exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only nature (only implied by GET method), authentication requirements, rate limits, or potential side effects. The lack of transparency is significant for a function that searches data.
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 short, including the endpoint in parentheses. It is front-loaded with the core purpose. However, the bracketed '[Financeiro]' could be omitted or integrated, but overall it is concise.
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 simplicity (1 parameter, no output schema, no annotations), the description does not fully equip an AI agent. It lacks details on the structure of the 'query' object (allowed keys, value types), the response format, and whether multiple suppliers can be returned. This is insufficient for a search 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?
The schema describes 'query' as an object with additional properties. The description adds context by stating 'Passe os filtros conhecidos em query' (pass known filters in query), clarifying its purpose as a filter object, which is valuable beyond the schema's generic 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?
Description clearly states it searches for supplier information (Busca informações de um fornecedor). The verb 'busca' and resource 'fornecedor' are specific. However, it does not explicitly differentiate from the sibling tool feegow_list_suppliers, which likely lists all suppliers.
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?
There is no guidance on when to use this tool versus alternatives like feegow_list_suppliers. The description only instructs to pass filters in 'query' without explaining conditions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must fully disclose behavior. It states it lists status types, but fails to mention idempotency, authentication needs, or that it is a read-only operation. The query parameter behavior is also 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus HTTP method, front-loaded with purpose. It is concise but could be slightly more informative 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?
No output schema exists, so the description should clarify return format (e.g., list of objects with IDs and names). It does not, leaving the agent without necessary context for using the result.
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, which is already described as a catch-all for additional query parameters. The description adds no further 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 lists appointment status types, which is specific and distinguishes it from sibling tools like 'feegow_status' and 'feegow_update_appointment_status'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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., feegow_status, feegow_list_appointment_motives). It only describes what it does without context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only states the tool lists health programs, without mentioning if it's read-only, idempotent, or any side effects. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. Efficiently communicates the core action and pagination. Could benefit from structuring but remains clear.
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 fails to explain the response structure. With 10 parameters and no behavioral details, the description is insufficient for an agent to fully understand the tool's behavior and output.
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 only adds brief mention of offset and limit for pagination, but does not add significant meaning 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 clearly states 'Lista todos os programas de saúde cadastrados' which is a specific verb+resource combination. It also mentions pagination with offset and limit. Among many sibling tools, this is the only one for health programs, so distinction is clear.
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 gives a hint about pagination parameters but provides no explicit guidance on when to use this tool versus alternatives, nor any when-not-to-use conditions. 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?
No annotations exist, so description carries burden. It mentions HTTP GET (read-only) and that values are in cents, but omits pagination, filtering limits, permission requirements, or response structure. Inadequate for a data retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is short and front-loaded with key info (HTTP method, purpose, value unit). No redundant text, but could benefit from more structure or additional details without sacrificing brevity.
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 provided. Description lacks return format, pagination, error handling, and full behavioral scope. Values in cents is helpful but insufficient for complete understanding.
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 descriptions in schema are adequate. Description adds no extra parameter meaning beyond schema. Baseline score of 3 applies as description does not enhance 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 it lists procedure bundles, and distinguishes from sibling tool 'feegow_list_procedures' which lists procedures. The verb 'lista' and resource 'pacotes de procedimentos' are specific.
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. No mention of prerequisites, filters, or scenarios. With many sibling list tools, this lack of context reduces clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions HTTP GET, implying read-only, but does not disclose behavioral traits such as authorization requirements, rate limits, page size, or what happens if no results. Minimal transparency beyond the basic request type.
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?
Single sentence with the department label front-loaded, concise and efficient. However, it could include more useful detail 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?
No output schema exists, but description does not hint at return value structure. For a list tool with 5 parameters and no output schema, the description should indicate what the response contains (e.g., list of sales with fields). Also, it has a nested 'query' parameter that could be clarified. Incomplete for practical use.
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 has 100% description coverage for all five parameters (date_start, date_end, amount, unidade_id, query), so schema already explains each parameter. Description adds no additional meaning beyond what the schema provides. 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?
Description clearly states it retrieves sales information based on period and filters. The verb 'Obtém' (Gets) and resource 'informações de vendas' (sales information) are specific. The sibling list includes many tools, but this one is distinct for sales data, not confused with invoices or other lists.
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 feegow_list_invoices. The description implies date-range filtering but does not state prerequisites, exclusions, or situations where another tool would be preferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behaviors. It only mentions HTTP GET (implying read-only) but does not specify authentication, pagination, or response structure, leaving significant gaps.
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?
Extremely concise at 1 sentence plus endpoint, no superfluous words. Could be slightly more informative without losing conciseness.
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?
For a listing tool with no output schema and 1 parameter, the description is incomplete. It omits page size or format of results, and lacks context on how units relate to other tools.
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% as the sole parameter 'query' is described in the schema. The description adds no value beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Lista' and resource 'unidades (filiais) da clínica', and includes the HTTP endpoint, making the purpose specific and distinct from sibling tools like feegow_list_professionals.
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, no conditions or exclusions provided. The description is purely declarative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It does not disclose read-only nature, pagination behavior, rate limits, or any side effects. The only behavioral hint is the HTTP GET method in the description.
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?
Single sentence with category and endpoint, no fluff. However, it includes redundant HTTP path that could be omitted, slightly reducing conciseness.
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 9 parameters and no output schema, the description is too brief. Missing details on pagination behavior (page/limit), response structure, and expected effect of each filter. Agent likely needs additional 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%, so baseline is 3. The description adds no additional meaning beyond the schema, simply referring to 'filters informados' generically.
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 'Lista' (list) and resource 'vouchers', and specifies it filters based on provided criteria. It distinguishes from sibling tools like 'create_voucher' and 'cancel_voucher'.
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 cancel_voucher or create_voucher. The description merely states functionality without exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It does not disclose any behavioral traits such as authentication needs, rate limits, pagination, or side effects. The HTTP method (GET) is mentioned in parentheses, which implies read-only, but this is not explicitly stated 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single line with the category, action, and resource, plus the HTTP path. Every word is informative. However, it could be slightly more descriptive about the required patient ID without losing conciseness.
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 tool has 4 parameters, no output schema, and no annotations, the description is insufficient for effective use. It does not clarify what the response contains, how to use the optional date range filters, or the meaning of the 'query' parameter. The date format discrepancy is also confusing.
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 75% (3 of 4 params described). The tool description adds no parameter semantics beyond what is in the schema; it does not explain the 'query' object parameter or the inconsistent date formats between data_inicio (dd-mm-yyyy) and data_fim (yyyy-mm-dd).
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 verb 'Lista' (lists), the resource 'pedidos de exames' (exam requests), and the entity 'paciente' (patient). It also includes the HTTP GET method and endpoint path, making the purpose unmistakable. Among many siblings, this tool is clearly distinguished as the one for listing a patient's exam requests.
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, no exclusion criteria, and no context about prerequisites (e.g., needing a patient ID). It merely states what it does, leaving the agent to infer use cases from the tool name and endpoint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It only indicates a write operation and permission need, but omits side effects, idempotency, error conditions, or post-payment actions.
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 with a permission note in brackets. It is concise and front-loaded with the purpose, though the structure could be improved to separate purpose from permissions.
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 7 parameters and no output schema, the description lacks completeness. It does not explain return values, error handling, or how payment processing works, which is crucial for a write 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 coverage is 100%, so the description does not add meaning beyond the schema. A baseline of 3 is appropriate as the schema already documents each parameter.
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 'Realiza o pagamento de um agendamento' (performs payment of a booking) with a specific verb and resource. Among siblings like feegow_pay_movement and feegow_create_invoice, this tool is uniquely identified for booking payments.
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 only additional note is the write permission requirement (ESCRITA), but no context about scenarios 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?
No annotations provided; description only states the action and HTTP method. No disclosure of side effects, safety, or limitations beyond the HTTP GET implication.
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?
Extremely concise: a single sentence plus HTTP endpoint. No wasted words, purpose is 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, and description does not mention return type or fields. With a nested parameter object, typical usage is unclear.
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 merely restates the schema's description for the 'query' parameter. No additional meaning is added.
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 lists registered appointment motives. The HTTP endpoint is provided, and the resource is distinct from sibling 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 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. Among many list tools, no context is provided 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?
No annotations provided; description only mentions it is a GET request, implying read-only, but does not explicitly state non-destructive nature or any other behavioral traits like authentication needs or pagination.
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?
Single sentence with clear verb and resource, plus endpoint info. No unnecessary words; well front-loaded with category label.
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; description does not explain return format, data fields, or pagination. For a list tool, more context on output structure would be beneficial.
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 describes the single parameter 'query' as additional key-value pairs. The tool description adds no further meaning beyond the schema, meeting 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?
Description clearly states verb 'Lista' (list) and resource 'convênios' (insurances), with HTTP endpoint. Distinguishes from sibling list 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 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 feegow_search_professional or other list tools. No context about filtering or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It only states the basic operation (list sources) without disclosing behavioral traits such as read-only nature, authentication requirements, or response format. The description adds minimal value beyond the name.
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 one sentence plus the endpoint, with zero wasted words. It is efficiently 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?
For a simple list tool, the description is minimal. It lacks details such as response structure, pagination, or any usage context. No output schema is present, but the description does not compensate by explaining return values.
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 does not add any parameter semantics beyond what the input schema already provides; the sole parameter 'query' is described in 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 the tool lists patient sources (how the patient found the clinic), uses a specific verb and resource, and includes the HTTP endpoint. It is distinct from many patient-related sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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. Among many sibling tools, there is no mention of when to choose this over others, nor any 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?
No annotations provided, so description must disclose behavior. It indicates a GET request (read-only) but omits response format, pagination, error handling, or authentication requirements.
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?
Single sentence plus endpoint, no redundant information. 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?
Despite low complexity, the description lacks details on output, error handling, or any behavioral context. Annotations are absent, leaving the agent underinformed.
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 descriptions for both parameters. The description adds no extra meaning beyond what the schema provides, so 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 tool lists proposals by alteration date, includes the HTTP endpoint, and distinguishes from feegow_list_proposals which lists proposals without date filter.
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 feegow_list_proposals or feegow_create_proposal. No when-not-to-use or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It indicates that the tool alters data and requires a specific environment variable, and notes amount is in centavos. However, it does not disclose side effects (e.g., does it update invoice status?), error conditions, idempotency, or response behavior. This is insufficient for a write tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of one informative sentence plus metadata in brackets. It front-loads the core purpose. However, the metadata (write indication, endpoint) could be integrated more naturally. Still, it achieves brevity without sacrificing critical 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 the tool's complexity (write operation with nested parameters) and lack of output schema, the description should explain what the response looks like or any success indicators. It does not cover return values or post-payment effects. It is adequate for basic understanding but incomplete for informed invocation.
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 minimal new information beyond the schema: it reiterates that amount is in centavos and frames the operation as payment. The schema already documents each parameter's purpose, so the description does not significantly enhance 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?
The description clearly states the action: 'Realiza o pagamento de uma conta (parcela/movement) vinculada a uma invoice.' The verb 'Realiza o pagamento' indicates the tool's purpose. However, it does not explicitly differentiate it from other payment-related sibling tools like feegow_pay_booking or feegow_remove_payment, which slightly 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions that this is a write operation requiring FEEGOW_ALLOW_WRITES=true, which gives some context. However, it lacks explicit guidance on when to use this tool versus alternatives, what prerequisites exist (e.g., invoice must have an unpaid movement), or when not to use it. This leaves the agent with incomplete 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?
No annotations provided, so the description carries full burden. It only states it lists via GET, but no disclosure of pagination, authentication, rate limits, or other behavioral traits.
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?
Single sentence front-loaded with category and action, efficient. Minimal but not wasteful.
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?
Adequate for a simple list tool with no output schema. It states purpose and endpoint, but lacks details on return format or additional 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% with clear parameter descriptions. The description does not add meaning beyond the schema; it only mentions the endpoint path. 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 explicitly states it lists procedures for a specialty, using the verb 'list' and specific resource 'procedures of a specialty'. It differentiates from siblings like feegow_procedures_by_professional and feegow_list_procedures by specifying 'by specialty'.
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 only describes the action, lacking explicit usage context, when-not-to-use, or references to similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description carries the burden. It discloses it does not alter data and gives the HTTP method POST. However, it does not describe the return format (e.g., file content, JSON response), error behavior, or whether generation is synchronous. Basic but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise single sentence with example and HTTP method. Front-loads purpose. Could be more structured, but 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?
Lacks information about output (no output schema), error handling, authentication, or list of valid report identifiers. Does not mention that users might need to consult 'feegow_list_reports' for available reports. Under-specified for a report generation 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 coverage is 100%, so baseline is 3. The description adds an example for 'report' and clarifies date format 'yyyy-mm-dd'. The 'query' parameter is mentioned but schema already describes it. Minimal 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?
Clearly states it generates a report (verb+resource) and explicitly says it does not alter data. Provides an example identifier 'bills-to-pay' and mentions date parameters. Distinguishes it from siblings like 'feegow_list_reports' which lists reports.
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 mention prerequisites or when not to use. The only context is that it's read-only, but no comparison with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior fully. It indicates a read operation (HTTP GET) and specifies the endpoint, but does not mention authorization, error handling, rate limits, or what the URL response looks like. Lacks depth beyond the basic 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 is a single, short sentence with no redundant information. It is front-loaded with the purpose. Could be slightly more structured but achieves conciseness.
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 and no annotations, the description is insufficient for a tool that returns a URL. It does not describe the response format, error cases, or any constraints on the ID. Minimal completeness for a simple fetch operation.
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 documents both parameters. The description adds context by mentioning 'proposta_id' as the identifier, but no extra semantics beyond the schema. The 'query' parameter is for additional parameters, not elaborated.
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 a proposal URL given an ID, with specific verb 'Lista a URL' and resource 'proposta'. It differentiates from sibling tools like feegow_list_proposals (lists all proposals) and feegow_create_proposal (creates a proposal), as it fetches a specific URL.
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 getting a proposal's URL when the ID is known, but does not explicitly state when to use this vs alternatives like feegow_list_proposals (for multiple proposals) or feegow_change_proposal_status. No exclusions or conditions 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?
The description discloses that the operation is a query ('não altera dados') and notes the POST method, which provides baseline transparency. However, no annotations are present, and the description lacks details on authentication, rate limits, or potential side effects (though it claims none). The mention of pagination in the body is helpful but incomplete for full behavioral understanding.
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, using a single sentence plus a parenthetical to convey the tool's nature, method, and key parameter constraints. Every word adds information, and the structure front-loads the category ('Financeiro') and 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?
Given the absence of an output schema and no annotations, the description could be more complete by outlining the response structure or common return fields. It is sufficient for a basic list tool but lacks details that would help an agent handle pagination or interpret results correctly.
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 already documents all parameters. The description adds value by specifying that accountType accepts values 1, 2, or 3 and that pagination parameters are in the body, but it does not elaborate on the meaning of unity or the exact range of perpage. This is adequate but not exceptional.
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 list of current accounts and explicitly marks it as a query (consulta), distinguishing it as a read operation despite using POST. It provides a specific resource (current accounts) and action (list), which helps differentiate it from siblings like feegow_list_invoices or feegow_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?
No guidance on when to use this tool versus alternatives (e.g., other list tools). There is no mention of prerequisites, filters beyond the listed parameters, or scenarios where a different tool is more appropriate. The description assumes the agent knows when to list current accounts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It states a GET operation (read-only) but does not mention side effects, authentication requirements, rate limits, pagination, or the structure of the response. The description is too minimal for safe use.
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 (plus code comment) with no extraneous text. It is front-loaded with the core purpose and efficiently conveys the essential information.
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?
For a list tool with two parameters, no output schema, and no annotations, the description is too brief. It does not explain what data is returned, if pagination exists, if paciente_id is required despite not being in required parameters, or how the 'query' parameter is used. Missing crucial context for effective use.
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?
Schema description coverage is 50% (only 'query' has a description, 'paciente_id' has none). The tool description does not add any parameter info or context beyond the schema. For a 2-parameter tool, this leaves the agent underinformed, especially about the crucial paciente_id.
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 lists prescriptions of a patient's medical record, specifying the resource (prescriptions) and context (patient's medical record). It includes the HTTP method and path, adding clarity. Among sibling tools, no other prescription-listing alternative exists, so no differentiation needed.
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 prescriptions but lacks explicit guidance on when to use this tool versus alternatives, prerequisites (e.g., need paciente_id), or when not to use it. The choice is straightforward given no other prescription tools, but contextual cues are missing.
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 discloses that it is a mutation operation requiring FEEGOW_ALLOW_WRITES=true, and mentions the response returns the patient with the account linked. However, it does not cover idempotency, error conditions, or side effects beyond the mutation flag. Given no annotations, the description provides moderate behavioral insight.
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 and well-structured: it provides the domain tag, core action, mutation flag, configuration requirement, and response hint in a few sentences. Every sentence contributes meaningful information without 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 tool with two parameters, no output schema, and no annotations, the description covers the core purpose, mutation nature, auth config, and a hint about the response. It lacks error handling or detailed response structure but is largely complete for such a simple operation.
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 already describes both parameters (account and association IDs) with 100% coverage. The description adds no further meaning or context about these parameters, so it meets the baseline without adding extra value.
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 associates a financial account to a patient/type (operação de mutação) and indicates it is a write operation. However, it does not explicitly differentiate from related tools like feegow_create_account that might create accounts rather than associate 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 guidance is provided on when to use this tool versus alternative financial tools. The description lacks context about prerequisites, such as requiring an existing patient and account, 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?
With no annotations, the description carries the burden. It discloses the write nature (ESCRITA, alters data) and the required environment variable, plus HTTP method and path. But it lacks details on idempotency, rate limits, or what happens on failure. Minimal transparency for a creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences plus a note) and front-loaded with the main action. The note about the path issue is useful but slightly distracts; still efficient overall.
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 the description should hint at return values, but it does not. It covers the creation action well but omits what the agent can expect in response (e.g., created ID). Adequate for a simple tool but incomplete.
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 good parameter descriptions. The description adds context that the file is base64 and the appointment ID, but does not significantly extend beyond the schema. Baseline score applies.
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 medical report with base64 content, using specific verbs (Registra) and resource (laudo médico). It distinguishes from retrieval tool (feegow_get_medical_report) implicitly but does not explicitly differentiate among 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?
The description includes contextual notes about a path issue and write permission requirement (ESCRITA, FEEGOW_ALLOW_WRITES=true). However, it does not specify when to use this tool versus alternatives like feegow_upload_patient_file, nor does it provide explicit when-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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions it is a write operation that alters data and requires a flag, and provides the HTTP method DELETE. For a mutation tool with no annotations, the description carries the burden of behavioral disclosure. It does not specify consequences (e.g., cascading effects), authorization details, or error handling.
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 plus metadata tags, efficiently conveying the core purpose. The tags add useful context, though they could be considered slightly redundant. It 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?
For a simple delete operation, the description covers the core function and required input. However, it lacks information about the response format or success/failure indicators. No output schema is provided, leaving the agent to infer 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% description coverage with 'invoiceId' described as the identifier. The description essentially restates this ('código identificador'), adding no new semantic meaning. The generic 'query' parameter is noted but not elaborated.
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 removes an invoice by its identifier. It uses a specific verb ('Remove') and resource ('fatura'), which distinguishes it from other invoice-related sibling tools like feegow_list_invoices or feegow_create_invoice.
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 includes tags '[Financeiro]' and '[ESCRITA — altera dados; requer FEEGOW_ALLOW_WRITES=true]' indicating it's a financial write operation requiring a specific environment variable. However, it does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or prerequisites beyond the flag.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It discloses the write operation ('ESCRITA — altera dados') and the required environment flag, which is useful. However, it lacks details on side effects, error states, or whether the operation is idempotent.
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 that efficiently packs the core purpose, category, data format note, write warning, and endpoint. No wasted words, though slightly more structure could improve readability.
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, the description adequately covers operation type, requirement, date format, and endpoint. It lacks response or error information, but for a write tool this is acceptable. Overall complete for the complexity level.
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 already documents all parameters with descriptions. The description only adds a date format hint, which is already present in some parameter descriptions. Thus, it adds marginal 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 states it registers product entry in stock ('Registra a entrada de produtos no estoque'), uses a clear category [Estoque], and contrasts with sibling tools like feegow_exit_product, which handle exits.
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 a prerequisite (FEEGOW_ALLOW_WRITES=true) and date format, but does not provide guidance on when to use this tool versus other stock-related siblings (e.g., feegow_exit_product, feegow_movement_product).
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 are missing, so the description must disclose behavioral traits. It states that the tool alters data (ESCRITA) and requires a write flag, but it does not discuss side effects, idempotency, validation behavior, or rate limits. This is insufficient for a write 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 concise, fitting in a single sentence with bracketed annotations. It front-loads the purpose and usage boundaries. However, the structure is slightly cluttered with multiple brackets, but overall it is efficient.
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 tool's complexity (many required parameters, nested object, no output schema), the description is too brief. It does not explain the billing guide workflow, how to obtain required IDs, or what the response contains. The note on SADT-only helps but is insufficient for complete 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%, so the baseline is 3. The tool description adds no additional meaning to parameters beyond what the schema already provides. It does not explain the purpose of the 'body' object or 'query' parameters further.
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 inserts a billing guide (guia de convênio) and specifies it's valid only for SADT guides. It distinguishes from sibling tools like edit and get by indicating the action and resource clearly.
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 notes that the tool is only for SADT guides and that procedures, attachments, and executors are not included, providing clear usage boundaries. It also mentions the required environment variable FEEGOW_ALLOW_WRITES=true, acting as a prerequisite. However, it does not explicitly mention when to use alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description reveals that the tool is a read-only GET operation with no required parameters. It does not discuss authentication, rate limits, or side effects, but for a simple list retrieval, this is minimally adequate. However, more details on response behavior 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences, no redundancy, and front-loads the category and action. Every word 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?
The tool is simple with no required parameters and no output schema. The description is complete enough for basic use, but could benefit from mentioning the expected output structure (e.g., list of flag names/IDs). For its complexity, it's 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?
The schema covers the single optional parameter 'query' at 100% coverage, so the description's note 'Não requer parâmetros' is consistent but adds no additional meaning. Baseline 3 applies since the schema already documents the parameter structure.
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 'Obtém a lista' (gets the list), the resource 'bandeiras de cartão de crédito' (credit card flags), and provides the HTTP endpoint for clarity. Among siblings, this tool is unique for credit card flags, so distinction is clear.
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 is provided. The description only notes that no parameters are required, but there is no mention of use cases, prerequisites, or comparisons with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions filtering and the HTTP POST method, but does not disclose pagination behavior, response shape, or side effects. Adequate but minimal extra information beyond 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?
Single sentence plus endpoint. Very concise and front-loaded with category label. Could be improved by structuring bullet points or adding brief explanation of output, but 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?
No output schema, so description should explain return values or pagination. It only says 'searches categories'. Lacks details on what information is returned, pagination behavior, or error handling. Incomplete for a list 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 coverage is 100% with each parameter described. The description only adds 'filtros informados' but does not elaborate on parameter meaning or usage. Baseline score of 3 is appropriate as description does not meaningfully augment 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 searches financial categories (chart of accounts) based on filters, with a specific verb 'Busca' and resource. It includes the HTTP method and endpoint, making it unambiguous. No sibling tool overlaps, so it's well-differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/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 implies use for retrieving financial categories when needed, but lacks context like preconditions or exclusion scenarios. Given no competing tool, a score of 3 is acceptable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses HTTP GET method and pagination behavior. However, does not mention authentication, rate limits, or how full vs non-full differ in terms of response size or performance. 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?
Extremely concise: one sentence covering purpose, pagination, and a key parameter option. No unnecessary words. Front-loaded with the tool's 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 list tool with 4 parameters and no output schema, the description explains pagination and view_mode but lacks details on query filtering, response format, default behavior, and error handling. Adequate but incomplete.
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?
Description adds meaning for limit, offset, and view_mode beyond the schema (e.g., 'Use limit/offset para paginar' and 'view_mode=full traz o cadastro completo'). However, the 'query' parameter is only described in the schema as additional key-value pairs, and the description does not clarify its usage or provided examples. Since schema coverage is 50%, description partially compensates.
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?
Clearly states it lists patients and mentions pagination and optional full mode. However, it does not differentiate from the sibling tool feegow_search_patient, which likely searches patients, but the distinction is not explicit.
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 guidance on using limit/offset and view_mode, but does not specify when to use this tool versus feegow_search_patient or other patient-related tools. No exclusions or alternatives 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?
Since no annotations are provided, the description carries the full burden. It discloses that the tool 'altera dados' (alters data) and requires a write flag, indicating a mutation. It also shows the HTTP DELETE method. However, it does not describe potential side effects (e.g., irreversibility, cascading deletions) or error behavior, which would be beneficial for a write 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 sentence with clear categorical brackets ([Financeiro], [ESCRITA — altera dados]) and the HTTP endpoint. It is concise and front-loaded with the primary action. However, it could be slightly more structured (e.g., bullet points) for easier scanning.
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 removal tool with one required parameter and no output schema, the description provides essential context: the action, HTTP method, and permission requirement. It is sufficient for an AI agent to understand what the tool does and invoke it correctly, though additional details on error handling or idempotency 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 input schema has 100% description coverage: paymentId is described as 'ID do pagamento que será removido.' The tool description does not add any additional meaning beyond what the schema already provides. The body and query parameters are generic, and the description offers no extra clarifications on 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?
The description explicitly states 'Remove um pagamento a partir do seu ID' (removes a payment by its ID), clearly specifying the verb and resource. It distinguishes from sibling removal tools (e.g., feegow_remove_invoice) by naming 'pagamento' (payment).
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. It does not mention prerequisites (e.g., payment must exist) or exclude scenarios. The only usage hint is the FEEGOW_ALLOW_WRITES=true requirement, but no context on 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?
No annotations are present, so the description must fully convey behavior. It only states the tool performs a health check without detailing authentication requirements, rate limits, or what happens on success/failure. This lack of disclosure is a significant gap for a non-trivial tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus endpoint reference, which is compact and front-loaded with the purpose. However, it is slightly underspecified, preventing a perfect score.
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 and lack of output schema, the description is minimally complete. It does not explain the return value (e.g., HTTP status, response payload), which is needed for an agent to interpret results. An average score reflects this gap.
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?
Schema coverage is 100% for the single `query` parameter, which is an optional object for additional query parameters. The description adds no context about this parameter; it merely restates the endpoint. Thus, no value is added 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 checks the Feegow API status (health check) via HTTP GET /status. This is a specific verb-resource combination that distinguishes it from all other feegow_ tools which deal with entities like professionals, patients, 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 implies usage for verifying API availability. There are no sibling health check tools, so no need for exclusions. The endpoint is provided, offering clear context. Could be improved by stating when to use it (e.g., before other operations), but it's adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It correctly identifies the tool as altering data (write) and requiring a config flag, but does not disclose size limits, error conditions, or success responses.
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 with relevant context (tag, write indication, HTTP method). It is concise without fluff, though it could be structured with clearer sections.
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 tool has nested objects (body with three required properties) and no output schema, the description is insufficient. It does not explain return values, common errors, or file size limits, leaving 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% for all parameters. The description adds no additional meaning beyond what the schema already provides, meeting the baseline but not exceeding it.
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 uploads a base64 file to the patient's medical record, using a specific verb ('upload') and resource ('patient file'). Among siblings, no other upload tool exists, making it distinct.
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 notes it's a write operation that requires the FEEGOW_ALLOW_WRITES=true flag, implying when to use it. However, it lacks explicit when-not-to-use instructions or alternatives, though no sibling upload tool exists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates it is a write operation ('ESCRITA — altera dados') and provides the HTTP endpoint and requirement. However, it does not disclose side effects, idempotency, or error behavior. Without annotations, the description carries the full burden but is only partially transparent.
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, including purpose and a technical note in brackets. It is front-loaded with the main action. The length is appropriate, though the structure could be slightly improved by separating the note.
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 parameters and no output schema, the description is missing return value information and typical usage contexts. It is adequate but not comprehensive for a creation tool with complex input.
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 detailed descriptions for nested objects. The tool description adds no extra meaning beyond noting the endpoint and write nature. Baseline 3 is appropriate since the schema already provides sufficient semantics.
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 a benefit card contract ('Cria um contrato do cartão de benefícios') and distinguishes it from siblings like list and update variants. The verb 'cria' and resource 'contrato do cartão de benefícios' are specific.
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 a prerequisite (FEEGOW_ALLOW_WRITES=true) but does not provide guidance on when to use this tool versus update_benefit_contract or list_benefit_contracts. No explicit 'when not to use' or alternatives 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?
Without annotations, description partially covers behavioral traits: identifies as write operation, requires FEEGOW_ALLOW_WRITES=true. Lacks details on side effects, idempotency, error responses, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences plus tags, front-loaded with purpose, no extraneous information. Efficient and 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?
Given 19 parameters, no output schema, and no annotations, description fails to explain return values, error handling, or how this tool fits with sibling inventory tools. Completeness is insufficient for complex mutation.
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 3 applies. Description reinforces date format but adds little beyond schema property descriptions; does not clarify parameter usage beyond what 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?
Description clearly states it records product exits from inventory ('Registra a saída de produtos do estoque'), using specific verb and resource. It distinguishes from sibling 'feegow_entry_product' which records entries.
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 context for usage by stating it's a write operation requiring FEEGOW_ALLOW_WRITES=true, but does not explicitly list when or when not to use it, nor compare with alternatives like feegow_entry_product or feegow_movement_product.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It only mentions the HTTP method (GET) implying it's read-only, but lacks details on authentication, rate limits, error handling, or result format. The minimal disclosure is insufficient for a tool with 15 parameters.
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, well-structured sentence that front-loads the purpose, lists filters, and includes the HTTP method. It is concise with no unnecessary words, earning high marks for efficiency.
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 tool's complexity (15 optional parameters, no output schema), the description is too brief. It does not explain return values, usage of the 'query' object parameter, or provide examples. This leaves significant gaps for the agent to use correctly.
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 mentions filterable fields and pagination, which align with schema properties, but does not add significant meaning beyond the schema descriptions. Extra context like the HTTP endpoint is provided but not critical.
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: 'Lista/consulta os contratos do cartão de benefícios' (list/query benefit card contracts). It uses specific verbs and resource, and distinguishes itself from sibling tools like feegow_create_benefit_contract and feegow_update_benefit_contract by focusing on reading.
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 by listing filterable fields and mentioning pagination: 'Filtre por documento, plano, nome, pessoa, status, unidade ou período; use page/perPage para paginação.' However, it does not explicitly state when not to use this tool or name alternatives, leaving some ambiguity among many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It mentions HTTP GET but omits pagination, ordering, response format, authentication needs, or rate limits. Insufficient for safe invocation.
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 HTTP path, front-loaded with category label, no fluff. Every sentence contributes to understanding purpose and parameters.
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 and lack of details on pagination, record structure, or error handling make the description incomplete for a list tool. Input is covered but output behavior is missing.
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 minimal value beyond schema, reiterating date format and optional patient filter. Baseline 3 is appropriate as no contradictions or significant gaps.
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 lists medical reports with a date range and optional patient filter, distinguishing it from sibling tools like get or create. The HTTP method and path add precision.
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 indicates when to use (listing by date range and optionally patient) but lacks explicit when-not-to-use or alternatives. However, sibling tools are distinct, making usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions it's a write operation and gives the HTTP endpoint, but fails to disclose side effects, prerequisites (e.g., existing appointment), or what happens to the original appointment.
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?
Extremely concise: one line with useful tags (write indicator, environment variable, endpoint). 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?
Lacks completeness for a mutation tool: no output schema, no error conditions, no return value description. The agent lacks context on success/failure signals and side effects.
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 all parameters described. The description adds no additional meaning beyond the schema, meeting the baseline for high 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?
The description clearly states the verb 'remarca' (reschedule) and resource 'agendamento' (appointment), specifying it changes date/time. This distinguishes it from siblings like create, cancel, or update status.
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?
Includes the requirement FEEGOW_ALLOW_WRITES=true and explicitly marks it as a write operation. However, it does not explicitly contrast with alternative tools for modifying appointments, though the purpose implies rescheduling.
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 discloses that this is a write operation that alters data and requires the FEEGOW_ALLOW_WRITES environment variable. It also reveals the HTTP method and endpoint. Since no annotations are provided, the description carries the full burden, but it does not cover side effects, idempotency, or partial update behavior. This is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the essential purpose. It includes technical notes in brackets. It is efficient with no wasted words, though it could be slightly 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?
The tool has multiple optional parameters and no output schema. The description is minimal and does not explain return values or nuances like which parameters are required vs. optional beyond the schema. Given the schema coverage is good, the description is acceptable but leaves some context unanswered.
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 documents all parameters. The description adds no additional meaning beyond what the schema provides. Thus, 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 updates a benefit card plan, using the verb 'Altera' (changes) and specifying the resource 'plano do cartão de benefícios'. It distinguishes itself from sibling tools like feegow_create_benefit_plan and feegow_list_benefit_plans by indicating it is a write operation that modifies existing data.
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 updating plans and indicates a prerequisite (FEEGOW_ALLOW_WRITES=true). However, it does not provide explicit guidance on when to use this tool vs. alternatives like creating a new plan or when not to use it. No alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states it is a write operation and requires a flag, but does not mention side effects (e.g., what happens to the appointment slot, reversibility, or confirmation behavior). This is insufficient for a mutation tool.
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 with a category tag, write indication, required flag, and HTTP endpoint. No wasted words; every element 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?
Given the simplicity (no output schema, few parameters), the description covers the basic purpose and write nature, but lacks details on prerequisites or implications of cancellation. It is minimally adequate but not 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 description coverage is 100%, so the baseline is 3. The description does not add any parameter-specific information beyond the schema; it only describes the tool overall. The schema already documents parameters adequately.
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 'Cancela um agendamento existente' (cancels an existing appointment), using a specific verb and resource. It distinguishes from sibling tools like feegow_create_appointment and feegow_reschedule_appointment by explicitly indicating cancellation.
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 it is a write operation ('ESCRITA — altera dados') and requires the environment flag FEEGOW_ALLOW_WRITES=true, providing clear context for when the tool can be used. However, it does not explicitly compare with alternatives or discuss 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?
With no annotations, the description bears full burden. It discloses that the tool writes data ('ESCRITA — altera dados') and requires a write permission flag. But it omits details on side effects, response structure, or error behavior, which are valuable for safe usage.
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 (one line) and front-loaded with purpose. However, the bracket-format metadata and HTTP endpoint inclusion, while informative, add slight noise. Still efficient overall.
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 tool's complexity (nested body with multiple fields) and no output schema, the description should explain return values or confirmations. It does not, leaving the agent uncertain about what the tool returns after creation. This is a notable 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 coverage is 100%, so the description adds no parameter info beyond what each property's description already provides. The description does not clarify semantics or relationships among 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 'Cria um novo agendamento' (Creates a new appointment), providing a specific verb and resource. It distinguishes this tool from siblings like feegow_list_appointments, feegow_cancel_appointment, etc., making its 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (to create appointments) and includes a prerequisite (FEEGOW_ALLOW_WRITES=true). However, it lacks explicit guidance on when NOT to use or direct mentions of alternatives, though sibling tools provide context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that the tool writes data and returns a patient_id, but does not mention idempotency, error handling, or side effects. It is adequate but not detailed.
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 two clear parts: the action and the write indicator. It is front-loaded with the purpose and includes helpful brackets for categorization. No superfluous 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?
The description mentions the return value (patient_id) but lacks details on error conditions, such as duplicate CPF, and does not specify if the operation is idempotent. Given the tool's complexity and lack of output schema, more completeness would be beneficial.
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% description coverage, so the schema already explains each parameter. The description adds no further meaning beyond stating the tool creates a patient, not enhancing parameter semantics beyond 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 it creates a new patient and returns the patient_id, specifying the verb 'cria' (creates) and resource 'paciente'. It explicitly marks as write operation (ESCRITA) and distinguishes from sibling list/search/edit patient 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 indicates this tool alters data and requires FEEGOW_ALLOW_WRITES=true, providing a prerequisite. However, it does not explicitly state when to use this tool over alternatives like feegow_edit_patient 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?
No annotations are provided, so the description must fully disclose behavioral traits. It only states that it is a write operation ('altera dados') and requires a specific environment variable. Missing details: response format, idempotency, error handling (e.g., what happens if paciente_id not found), and whether updates are partial or full.
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 plus a bracketed note, immediately stating the purpose and usage. Every word is functional, with no redundancy. It 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 description covers the basic purpose and usage but omits important context: there is no output schema, so the agent doesn't know what the tool returns (e.g., updated patient object or success message). It also doesn't mention whether all fields are optional beyond paciente_id, or validation rules. Given the tool's complexity (nested body, many fields), more context would be beneficial.
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 does not add extra meaning beyond the schema; it merely restates that one should send paciente_id and fields to change. The schema already describes each parameter adequately, so the description adds no unique value.
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 'Edita os dados de um paciente existente' (edits data of an existing patient), clearly identifying the verb and resource. It distinguishes from siblings like feegow_create_patient (create) and feegow_search_patient (search) by specifying it's for editing existing records.
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 says 'Envie paciente_id e os campos a alterar' (send patient ID and fields to change), providing clear usage instructions. It also includes a note about requiring FEEGOW_ALLOW_WRITES=true, which helps the agent know when to use this tool. However, it lacks explicit comparisons to sibling tools (e.g., 'use this instead of feegow_create_patient for updates').
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?
Despite no annotations, the description explicitly states it is a write operation that alters data and requires a write flag, disclosing behavioral traits beyond what the schema provides.
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, front-loads key information (category, purpose, HTTP method, write requirement), and contains no 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 3 parameters, no output schema, and write semantics, the description is adequate but lacks parameter explanation and output format details.
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?
Schema coverage is low (33%), and the description adds no meaning to parameters. It does not explain the semantics or required fields like unidade_id.
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 generates/returns a queue position and issues a ticket, specifying it is for appointments (Agendamentos). It is distinct from siblings, none of which explicitly handle queue positions.
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 it is a write operation requiring FEEGOW_ALLOW_WRITES=true, but does not provide explicit guidance on when to use versus alternatives 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?
With no annotations, the description carries full burden. It discloses write operation and required configuration flag, but lacks details on side effects, authentication beyond the flag, or error 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?
The description is a single, efficient sentence with category, action, condition, and endpoint. No redundant words, 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?
Given no output schema and moderate complexity (nested body, query), the description lacks details on response format, error handling, or prerequisite state. Incomplete for confident tool use.
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 already documents parameters. The description adds no extra parameter meaning beyond hinting at 'agendamento_id' role. Baseline score 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 tool creates a financial account from an existing appointment, using specific verb and resource. It distinguishes from siblings by specifying the source (appointment) and domain (financial).
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 when to use: when there is an existing appointment to create a financial account. It mentions the write flag requirement but does not explicitly exclude alternatives like create_invoice or associate_account.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses the write operation, environment requirement, value format (cents), and date format. It adds context beyond schema, though it could detail side effects 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with key information (purpose, format, requirement) front-loaded. Efficiently uses brackets for additional context, though could be structured more clearly.
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 complex nested schema, the description provides an overview (items, installments, type) and format details, but lacks explanation of return values or validation behavior. Adequate but not fully comprehensive for a mutation tool with rich schema.
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 restates format details (cents, date) already in schema, adding no extra meaning. Does not compensate for the lack of enum values or nested structures beyond what 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 the tool creates financial invoices/accounts with type, items, and installments, specifying type meanings (C=receber, D=pagar). It distinguishes from sibling tools like feegow_list_invoices (read) and feegow_create_account (likely different) by focusing on 'invoice' creation.
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 via 'Cria uma conta/invoice financeira' and notes the write requirement (FEEGOW_ALLOW_WRITES=true), but does not explicitly state when not to use or suggest alternatives among similar siblings (e.g., feegow_create_account).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry the burden. It mentions HTTP POST and changes data ('altera dados'), but lacks details on idempotency, error states, 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 a single sentence with self-contained information, front-loading the purpose. However, the mix of Portuguese and English and inline HTTP endpoint adds slight clutter.
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, the tool is well-described for its complexity. It includes the HTTP endpoint and required environment variable. Return value is not explained, but that's acceptable for a create 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 descriptions cover 100% of parameters. The description adds minimal extra context (e.g., date format, tipoValor meaning), but most semantics are already 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 tool creates a discount voucher (cupom) and specifies the value type (V or P) and date format. This distinguishes it from siblings like feegow_cancel_voucher, feegow_edit_voucher, and feegow_list_vouchers.
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?
It notes the write operation and requirement for FEEGOW_ALLOW_WRITES=true, providing context. While it doesn't explicitly list when to use alternatives, it implies this is for creation only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It correctly identifies the tool as a read-only operation via HTTP GET, which implies no destructive side effects. However, it does not disclose pagination behavior, rate limits, or what happens on errors. For a list endpoint, basic transparency is met but could be richer.
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 at two sentences: the first states purpose and filters; the second provides the HTTP method and endpoint. It is front-loaded with the core action and avoids redundancy. Every sentence 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?
For a list tool with 9 parameters and no output schema, the description is adequate but lacks details on response format, pagination, sorting, or whether all filters are optional. It does not mention the return structure (e.g., list of appointment objects). Given no annotations, additional context would be beneficial.
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 adds meaning beyond the schema by listing the filter categories (e.g., 'data_start/data_end no formato yyyy-mm-dd', 'profissional', 'unidade', 'paciente', 'status', 'grupo_procedimento'). This maps directly to parameters and clarifies date formatting. The schema coverage is only 33%, but the description compensates well for many of the 9 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 the tool's purpose as listing/searching appointments ('Lista/busca agendamentos') and lists specific filter criteria (period, professional, unit, patient, status, procedure group). It also provides the HTTP GET endpoint, which distinguishes it from mutation tools like create_appointment or cancel_appointment.
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 through the listed filters, but does not explicitly state when to prefer this tool over siblings (e.g., create_appointment, available_schedule). No guidance on when not to use it is given. The endpoint suffix 'search' hints at its query nature, but more explicit direction would improve clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must convey behavioral traits. It correctly indicates the tool is non-destructive and describes pagination via body parameters. However, it lacks details on response format, required permissions, or potential limitations (e.g., rate limits, default pagination size). This is adequate but not fully comprehensive.
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 with a clarifying parenthetical. It is concise and front-loads the main purpose. It could be slightly improved by separating the safety note more clearly, but overall it is 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?
Given the tool's simplicity (2 parameters, no enums, no output schema), the description covers the essential aspects: purpose, safety, and pagination. It omits details like response structure or error cases, but for a straightforward list endpoint this is reasonable. The context signals (high schema coverage, few parameters) support that the description is sufficiently 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% (both 'page' and 'perpage' have descriptions). The description reinforces that pagination is in the body, but does not add new meaning beyond the schema. According to the guidelines, baseline is 3 for high coverage, and the description does not provide significant additional insight.
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 primary function: 'Obtém a lista de centros de custos' (Gets the list of cost centers). It specifies that it is a query (consulta) despite using POST, and provides the HTTP endpoint. This is sufficient to distinguish it from sibling tools, none of which are cost-center-related.
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 explicitly notes that it is a read-only operation ('não altera dados') and clarifies that pagination parameters are sent in the body. However, it does not mention when to avoid using this tool or compare it to similar list tools among siblings, which would be nice but not critical for a simple list tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose all behavioral traits. It only states the HTTP method (GET) and that it lists insurances. No mention of authentication requirements, rate limits, side effects, pagination, or error handling for missing procedures.
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 a parenthetical HTTP endpoint, no wasted words. Every part is necessary 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?
The tool is a simple list operation with no output schema. The description adequately explains the input options but lacks details on output format, pagination, or typical use cases. It is minimally complete but not rich.
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%, baseline 3. The description adds value by clarifying the mutual exclusivity of procedimentoID and nomeProcedimento, stating that if one is missing the other must be provided. It also explains the query parameter as additional key/value pairs.
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 lists all insurance plans accepted for a procedure, using specific verb ('lista') and resource ('convênios aceitos para um procedimento'). It distinguishes from siblings like feegow_list_insurances (all insurances) and feegow_professional_insurances (by professional) by being procedure-specific.
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 gives explicit guidance on parameter usage: provide procedimentoID or, if absent, the exact nomeProcedimento. It does not compare to alternative tools or state when not to use it, missing exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that the tool performs a write operation ('ESCRITA — altera dados') and requires FEEGOW_ALLOW_WRITES=true. However, it lacks details about side effects (e.g., whether cancellation is permanent, what happens to the voucher status) and does not describe the response format. The HTTP endpoint is provided, which adds context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct: one sentence for purpose and parameter usage, plus a brief note on write behavior and the endpoint. It is front-loaded with the key action and efficiently uses parentheses for additional context. No redundant 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 cancellation tool with required and optional parameters, the description provides essential information: domain, action, parameter constraints, write nature, and endpoint. It does not explain return values (no output schema), but that is acceptable. The description is sufficiently complete for the agent to understand when and how to invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value by giving examples of codigo_motivo values (ERRO_EMISSAO, OUTRO) and clarifying that observacao is conditional on codigo_motivo being 'OUTRO'. This slightly exceeds the schema's parameter descriptions, but the overall parameter guidance remains minimal.
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 'Cancela um voucher' (cancels a voucher), clearly identifying the action and resource. It includes domain '[Financeiro]' and HTTP endpoint, distinguishing it from sibling tools like create_voucher, edit_voucher, and list_vouchers.
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 that codigo_motivo must be one of the provided codes (e.g., ERRO_EMISSAO, OUTRO) and that observacao only applies when codigo_motivo is 'OUTRO'. It also notes that this is a write operation requiring FEEGOW_ALLOW_WRITES=true. However, it does not explicitly state when not to use this tool (e.g., voucher must exist and not be already canceled) or compare it to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool alters data (ESCRITA) and requires a specific environment variable, but lacks details on side effects, idempotency, or error conditions. This is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—one sentence plus a parenthetical note. It front-loads the resource and action, and every word is necessary. No wasted 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?
Given the tool has a nested required parameter and no output schema, the description provides essential context (write operation, requirement) and the schema covers parameter details. It could include what happens on success, but for a creation tool with simple parameters, this is largely 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 description coverage is 100%, so the schema documents all parameters. The description does not add any additional parameter-level meaning beyond what is already in the schema, resulting in a baseline score of 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 the verb (cria) and resource (plano do cartão de benefícios), and the sibling tools include list and update variants, distinguishing it as the creation endpoint.
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 explicitly notes it is a write operation requiring FEEGOW_ALLOW_WRITES=true, providing a prerequisite. While it doesn't explicitly state when not to use it, the context of creation vs. listing or updating is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a key behavioral trait: the returned URL is authenticated and valid for 20 minutes. With no annotations, this adds crucial context. It doesn't cover other aspects like permissions or side effects, but the provided detail is valuable.
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 concise sentences plus endpoint. Front-loaded with the action, minimal waste. Every part earns its place.
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 explains the output (authenticated URL) and its validity, which is adequate for a file retrieval tool with no output schema. It covers essential context but could benefit from specifying the response format (e.g., JSON 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 baseline is 3. The description does not add parameter-specific meaning beyond the schema; it only reiterates the existence of lab_report_id implicitly. No additional semantic value.
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: retrieving a lab report file. It specifies the resource ('laudo') and distinguishes from siblings like feegow_get_medical_report by explicitly mentioning 'lab report' and the HTTP endpoint.
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 when needing the file of a lab report, but gives no explicit guidance on when to use this over alternatives or when not to use it. No sibling differentiation beyond the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It clearly states it's a write operation, required environment variable, and the HTTP endpoint. This provides good transparency beyond what is obvious from the name.
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 concise, front-loaded, and without unnecessary words. It efficiently conveys the purpose and key behavioral notes.
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 covers the essential purpose, side effects, and authentication requirement. Though it lacks details on response format or error handling, it is adequate for a write tool with well-defined parameters.
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 adds no additional parameter-level meaning 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?
Description clearly states 'Insere (cadastra) um produto no estoque' (Insert a product in stock). It uses a specific verb and resource, distinguishing it from siblings like feegow_list_products and feegow_entry_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 notes it's a write operation requiring FEEGOW_ALLOW_WRITES=true, but does not provide explicit guidance on when to use this tool over siblings like feegow_entry_product for adding stock to existing products.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It discloses the HTTP method and basic parameters, but lacks details on pagination, data limits, or default behavior if no parameters are given (though ativo is required).
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, front-loaded with the core purpose, and includes the HTTP endpoint. 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?
For a simple list tool with one required parameter, the description provides the essential info: what it lists, the filter, and optional unit. It omits potential details like pagination, but is adequate for basic usage.
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 echoes the parameter meanings (ativo required, unidade optional). It adds no new insights beyond the schema, achieving the baseline for high 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?
The description clearly states it lists employee names and IDs, with required filtering by active/inactive status. It also specifies the HTTP endpoint, distinguishing it from sibling tools that list other entities like professionals.
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 explicitly states the required parameter (ativo) and optional parameter (unidade), guiding usage. It implies this is for listing employees, but does not explicitly exclude alternatives like feegow_list_professionals.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that this is a write operation (ESCRITA — altera dados), requires an environment variable, and uses PascalCase keys. This provides good behavioral transparency, though side effects or irreversible changes are not mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with important supplementary info in brackets. It is front-loaded and every sentence earns its place with 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?
For a mutation tool with no output schema, the description covers the operation itself, the required environment variable, and key naming convention. It is reasonably complete, though error handling or response details are absent.
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 description adds minimal value over the schema. It mentions PascalCase keys, which is useful context but does not elaborate on parameter meanings beyond what the schema already provides. 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 action: 'Atualiza o status de um agendamento e insere uma nota' (updates appointment status and inserts a note). It is a specific verb-resource combination that distinguishes it from sibling tools like cancel or reschedule.
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 some guidance (PascalCase keys, requirement for FEEGOW_ALLOW_WRITES=true) but does not explicitly state when to use this tool versus alternatives like feegow_cancel_appointment or feegow_create_appointment. No exclusion or alternative 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?
With no annotations provided, the description carries the full burden. It discloses that the tool modifies data ('altera dados') and requires a write flag. This adds basic behavioral context, but it does not describe side effects, idempotency, or error behavior. It is minimal but not misleading.
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 plus a tag and endpoint in parentheses. It front-loads the category and action, with no wasted words. Every element earns its place.
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 complexity (nested required objects) but supported by a thorough input schema and no output schema, the description adequately conveys that this is a contract update operation. It lacks an example or return value description, but the schema covers the input fully, and the tool's nature is clear.
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 does not add any parameter-specific meaning beyond what the schema already provides (e.g., nested fields, required fields). The description only mentions the overall purpose, not individual 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 the verb 'Altera' (updates) and the resource 'contrato do cartão de benefícios' (benefit card contract). This is specific and distinguishes from sibling tools like feegow_create_benefit_contract or feegow_list_benefit_contracts.
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 explicitly mentions the requirement 'FEEGOW_ALLOW_WRITES=true', which is a key usage guideline. It also labels itself as 'ESCRITA' (write), implying it should be used for modifications. However, it does not mention when not to use it or cite alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses it's a write operation and requires an environment variable, but does not mention side effects (e.g., whether the invoice must be in a certain status) or error conditions. Adequate but basic.
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 plus the write flag and endpoint, front-loaded with category. Every element earns its place, 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?
For a simple one-field update operation with no output schema, the description is sufficient. It covers purpose, write requirement, and endpoint. Could improve by mentioning typical response (e.g., success status), 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% (both parameters have descriptions). The description adds no further meaning beyond the schema: 'identifier da invoice' and 'novo numero da NFS-e' are already stated. Baseline 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 the verb 'Atualiza' (updates) and the specific resource 'número da nota fiscal (NFS-e) de uma invoice', distinguishing it from siblings like feegow_find_invoice_by_nfse (read) and other invoice mutation 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 indicates it is a write operation requiring FEEGOW_ALLOW_WRITES=true, giving clear context. However, it does not explicitly mention when to use vs. alternatives (e.g., if you need to find by NFSE number, use feegow_find_invoice_by_nfse).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the write nature and HTTP method, but lacks details on side effects, reversibility, or constraints like whether transitions between specific statuses are allowed.
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 with the main action, but the status mapping could be better formatted (e.g., bullet points) for readability.
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 status-update tool with two required parameters and no output schema, the description covers purpose, status mappings, write requirement, and HTTP method, but omits error scenarios or 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% with basic descriptions. The description adds value by mapping status_id values to labels (e.g., 1=Aguardando aprovação), which aids correct parameter selection.
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 changes the status of a proposal, lists all possible status values with their mappings, and distinguishes itself from sibling tools (e.g., feegow_list_proposals) by specifying it is a write operation.
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 when to use (to alter proposal status) and notes the prerequisite FEEGOW_ALLOW_WRITES=true, but does not explicitly state when not to use or provide 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that this is a write operation ('ESCRITA — altera dados'), requires the environment variable FEEGOW_ALLOW_WRITES=true, and uses HTTP PUT. It does not detail side effects or irreversible actions, but the write requirement and method are clearly stated.
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, efficiently structured sentence covering purpose, optionality, constraints, and HTTP method. No redundant words; all information is pertinent.
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 does not mention return values or success/failure behavior. For a mutation tool with no output schema, agents may benefit from knowing what the response contains. Despite good annotations on other aspects, this omission limits 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%, so baseline is 3. The description adds value by clarifying that all fields except id are optional, specifying enum values for tipoValor ('V' for money, 'P' for percentage), and providing date format guidance ('yyyy-mm-dd'), 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 'Edita um voucher existente', which is a specific verb (edit) and resource (voucher). It distinguishes from sibling tools like create_voucher, cancel_voucher, and list_vouchers.
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 notes that all fields except id are optional and provides format hints, but it does not explicitly state when to use this tool versus alternatives (e.g., when needing to cancel, use feegow_cancel_voucher). Context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the burden. It explicitly states the tool is a CONSULTA (non-destructive) and explains that pagination and filters go in the body. But it lacks information about authorization requirements, rate limits, or whether the response includes pagination metadata.
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 paragraph that front-loads the purpose and key information. It is concise, but could benefit from a more structured format (e.g., bullet points for parameters or behavior).
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 lists the fields returned (name, code, category, etc.), which compensates for the lack of an output schema. It also explains pagination. However, it does not describe the JSON structure of the response or whether there are pagination metadata fields.
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 clarifying the HTTP method (POST) and providing an example body for pagination ('perPage': 100, 'page': 1). This helps the agent understand how to invoke the tool correctly.
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's a stock position consultation for products, listing specific fields. It explicitly says it's a query that does not alter data, and the verb 'Consulta' (consult) is specific. Among sibling tools like feegow_entry_product or feegow_get_product_position, this tool is clearly for listing products with filters and pagination.
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 explains how to use pagination and filters, and notes that despite using POST it's a read-only operation. However, it does not explicitly mention when to use this tool vs alternatives like feegow_get_product_position for a single product.
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?
Discloses read-only nature (no data changes), pagination method, and date format. With no annotations, this provides essential safety and usage context beyond 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence conveys purpose, method, behavior, and endpoint. No wasted words; front-loaded with key intent.
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 query tool: covers input parameters, pagination, date format, and read-only nature. Lacks return structure, but no output schema exists, and typical position queries suffice with this info.
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 has 100% parameter description coverage, so the description adds only marginal value (e.g., default pagination values). 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 it retrieves product stock position, explicitly labels it as a query (CONSULTA), and distinguishes it from sibling product manipulation tools like entry/exit/movement.
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 it's a read-only operation despite POST, which prevents misuse. Does not explicitly contrast with alternatives, but the context of stock query versus entry/exit 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?
With no annotations, the description carries full burden. It discloses HTTP method (GET) and pagination behavior, but does not discuss idempotency, auth requirements, or error handling. Adequate but not exhaustive.
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?
Single sentence with parenthetical HTTP endpoint. Front-loaded with purpose. 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?
Covers purpose, parameters, and pagination. Without an output schema, it could mention the return type (list of plans), but it is functionally complete for a list 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% (baseline 3). Description adds value by explaining that page/perPage control pagination and id filters a specific plan, which is additive 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 'Lista/consulta os planos do cartão de benefícios', which is a specific verb (list/consult) and resource (benefit card plans). It distinguishes from siblings like create_benefit_plan or list_benefit_contracts.
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 indicates when to use pagination or filter by id, but does not explicitly exclude use for other operations. Context is clear but no alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavior. It explicitly states it is a write operation and currently limited to SADT, and notes exclusions. This is good transparency for a mutation tool, though it could mention potential 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single sentence with clear tags for domain, action, exclusions, write requirement, and HTTP endpoint. No redundancy; every part earns 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 explains the action and limitations but does not mention the response format or error handling. With no output schema, the agent may need to infer return behavior. Adequate but not fully complete.
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?
Input schema covers all parameters with descriptions (100% coverage). The description adds value by clarifying the current restriction to billing_type_id=2 (SADT), which is not in the schema. This helps the agent avoid invalid calls.
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 edits attributes of a billing guide ('guia de convênio'), specifies current limitation to SADT, and lists exclusions (procedures, attachments, professionals). This distinguishes it from sibling tools like feegow_insert_billing_guide and feegow_get_billing_guide.
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 the write requirement (FEEGOW_ALLOW_WRITES=true) and scope limitation (SADT only), but does not explicitly state when to use this tool versus alternatives like feegow_insert_billing_guide for creation or feegow_get_billing_guide for retrieval. The exclusions implicitly guide 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?
With no annotations, the description carries the full burden. It declares the tool is a write operation ('ESCRITA — altera dados'), specifies the HTTP method (POST), and notes the environment variable requirement. It does not mention side effects or rate limits, but the essential behavioral context is provided.
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, front-loaded sentence with essential details. The status mapping is embedded compactly, and the write requirement is highlighted. No unnecessary words or repetition.
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 output or return value. For a creation endpoint, knowing what is returned (e.g., proposal ID) is important for further actions. Given the complexity (nested objects, multiple required fields) and no output schema, this gap reduces 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?
Schema coverage is 100%, and the description adds value by explaining the status_id mapping (1-5) and the date format (dd-mm-yyyy), which are not in the schema descriptions. This enhances understanding 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 the tool creates a proposal with a list of procedures, using a specific verb ('cria') and resource ('proposta'). It distinguishes from sibling tools like feegow_list_proposals and feegow_change_proposal_status 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a prerequisite (FEEGOW_ALLOW_WRITES=true) and maps status_id values, but does not explicitly state when to use this tool versus alternatives. The clear purpose and write indication partially compensate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the write requirement for non-GET methods and the path construction. However, it does not mention other behavioral traits like error handling, response format, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. Essential information is front-loaded. Every sentence adds value.
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 generic nature and lack of output schema, the description covers the purpose, usage condition, and path construction. It could mention that the response mirrors the API's response, but overall it's sufficient for a fallback 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 covers 50% of parameters with descriptions (method and path). Description adds context for path (relative, example) and method (write constraint). But body and query parameters are not explained beyond schema, so the description adds moderate value.
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's a generic call to any Feegow API endpoint when no specific tool exists. It uses the verb 'Chamada genérica' (generic call) and explicitly distinguishes from siblings by indicating it's a fallback.
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?
Provides clear when-to-use (when no specific tool) and a key constraint: methods different from GET require FEEGOW_ALLOW_WRITES=true. This helps the agent decide and configure correctly.
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:

[![mdia-feegow-mcp MCP server](https://glama.ai/mcp/servers/mdiaoficial/mdia-feegow-mcp/badges/card.svg)](https://glama.ai/mcp/servers/mdiaoficial/mdia-feegow-mcp)

Score Badge

Copy to your README.md:

[![mdia-feegow-mcp MCP server](https://glama.ai/mcp/servers/mdiaoficial/mdia-feegow-mcp/badges/score.svg)](https://glama.ai/mcp/servers/mdiaoficial/mdia-feegow-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/mdiaoficial/mdia-feegow-mcp'

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