MCP Câmara BR

Server Quality Checklist

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

Latest release: v1.1.0
Disambiguation4/5
Most tools have distinct purposes targeting specific resources and actions (e.g., buscar_deputados vs. detalhar_deputado), but there is some overlap between diagnosticar_consulta and sugerir_ferramentas, both suggesting tool usage. Additionally, resumo_* tools provide optimized versions of detailed tools (e.g., resumo_despesas_deputado vs. despesas_deputado), which could cause confusion if not carefully described, though descriptions help clarify.
Naming Consistency5/5
Tool names follow a highly consistent snake_case pattern with clear verb_noun structures throughout (e.g., buscar_deputados, detalhar_evento, analise_despesas_partido). There are no deviations in naming conventions, making the set predictable and easy to parse for agents.
Tool Count2/5
With 63 tools, the count is excessive for a single server, even given the broad domain of legislative data. This many tools can overwhelm agents, increase complexity, and likely includes redundancy (e.g., multiple summary vs. detailed tools). A more focused set of 15-30 tools would be more appropriate for usability.
Completeness5/5
The tool set provides comprehensive coverage for the Brazilian Chamber of Deputies domain, including CRUD-like operations (buscar, detalhar), analyses (analise_*, ranking_*), summaries (resumo_*), and utilities (exportar_dados, ufs). There are no obvious gaps; it supports full workflows for deputies, propositions, events, votes, and more.
Average 3.3/5 across 63 of 63 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the action ('busca') without disclosing behavioral traits like whether it's read-only (implied but not stated), pagination behavior (though parameters hint at it), rate limits, authentication needs, or what the output looks like. For a search tool with no annotation coverage, this leaves 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?
The description is a single, efficient sentence ('Busca legislaturas da Câmara dos Deputados') that is front-loaded and wastes no words. It could be slightly more informative, but it's appropriately sized for its minimal content, earning a high score for 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 complexity (a search tool with 5 parameters), no annotations, and no output schema, the description is incomplete. It doesn't explain the return values, error conditions, or how parameters interact (e.g., pagination defaults). With schema coverage at 100%, parameters are documented, but overall context for effective use is lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all 5 parameters well-documented in the schema (e.g., 'data' for date search, 'pagina' for page number). The description adds no additional parameter semantics beyond the schema, so it meets the baseline of 3 where the schema does the heavy lifting but doesn't compensate or enhance understanding.
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 'Busca legislaturas da Câmara dos Deputados' clearly states the verb ('busca' - search) and resource ('legislaturas' - legislatures), making the basic purpose understandable. However, it doesn't differentiate from sibling tools like 'detalhar_legislatura' (detail legislature) or specify what 'search' entails (e.g., filtering, listing). This makes it adequate but vague about 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 versus alternatives. It doesn't mention sibling tools like 'detalhar_legislatura' for detailed views or clarify if this is for listing all legislatures versus filtered searches. Without any context on prerequisites or alternatives, usage is unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but provides none. It doesn't indicate whether this is a read-only operation, what data format is returned, potential error conditions, rate limits, or authentication requirements. The description only states what the tool does at a high level without any operational 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 extremely concise - a single Portuguese sentence that directly states the tool's purpose. There's no wasted language, repetition, or unnecessary elaboration. It's front-loaded with the core functionality and appropriately sized for a simple lookup tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is insufficient. While the purpose is clear, it doesn't address what 'detalhes' (details) actually means - what specific information is returned about a legislature. Given the lack of structured metadata about behavior and output, the description should provide more context about what users can expect from this 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?
The description adds no parameter information beyond what the schema already provides (100% coverage). The schema clearly documents that 'id' is a required number representing the legislature ID. Since schema coverage is complete, the baseline score of 3 is appropriate - the description doesn't add value but the schema fully documents 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 verb ('Obtém detalhes' - Gets details) and resource ('de uma legislatura específica' - of a specific legislature), making the purpose immediately understandable. It doesn't explicitly distinguish from sibling tools like 'buscar_legislaturas' (which likely lists multiple legislatures), but the focus on a single specific legislature is clear from the description.
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. There's no mention of when to choose this over 'buscar_legislaturas' (which likely returns a list) or other detail-oriented tools like 'detalhar_deputado' or 'detalhar_proposicao'. No context about prerequisites, timing, or use cases is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool analyzes presence and participation, but doesn't describe what the analysis entails (e.g., metrics, formats, or limitations), whether it requires authentication, rate limits, or what the output looks like. This is a significant gap for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. It avoids unnecessary words and directly states what the tool does. However, it could be slightly more structured by explicitly separating purpose from context or limitations.
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 analyzing presence and participation, no annotations, and no output schema, the description is incomplete. It doesn't explain what the analysis returns (e.g., statistics, lists, summaries), potential errors, or behavioral traits. For a tool with no structured support, more detail is needed to guide 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?
The schema description coverage is 100%, with clear descriptions for all three parameters ('idDeputado', 'dataInicio', 'dataFim'). The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Analisa a presença e participação de um deputado em eventos (reuniões, sessões, audiências) em um período específico.' It specifies the verb ('analisa'), resource ('presença e participação de um deputado'), and scope ('eventos em um período específico'). However, it doesn't explicitly differentiate from sibling tools like 'eventos_deputado' or 'discursos_deputado', which might have overlapping functionality.
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 doesn't mention sibling tools like 'eventos_deputado' (which might list events for a deputy) or 'discursos_deputado' (which might analyze speeches), nor does it specify prerequisites or exclusions. Usage is implied by the description but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states this is a listing operation, which implies read-only behavior, but doesn't disclose any behavioral traits like pagination, rate limits, authentication requirements, error conditions, or what format the list returns. For a tool with zero annotation coverage, this is insufficient.
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, clear sentence in Portuguese that directly states the tool's purpose without any wasted words. It's appropriately sized and front-loaded with 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?
Given no annotations and no output schema, the description is incomplete. It doesn't explain what the output looks like (e.g., list format, fields included), any limitations, or behavioral context. For a tool that presumably returns data, this leaves significant gaps for an AI agent to understand how to use it effectively.
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 description doesn't add any parameter semantics beyond what's in the schema. However, schema description coverage is 100% (the 'id' parameter is fully described in the schema), so the baseline score is 3. The description doesn't compensate but doesn't need to since the schema already documents the single required parameter adequately.
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 os autores de uma proposição legislativa' clearly states the action (list) and target resource (authors of a legislative proposition). It's specific enough to understand the tool's function, though it doesn't explicitly differentiate from sibling tools like 'detalhar_proposicao' or 'ranking_proposicoes_autor' which might have overlapping purposes.
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. With siblings like 'detalhar_proposicao' (detail proposition) and 'ranking_proposicoes_autor' (ranking proposition authors), there's no indication of when this specific listing tool is preferred or what distinguishes it from related 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, so the description carries the full burden of behavioral disclosure. It only states the action ('busca') without detailing whether this is a read-only operation, if it requires authentication, rate limits, pagination behavior, or what the response format looks like. This is inadequate for a tool with parameters and no output 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?
The description is a single, efficient sentence with no wasted words. It is appropriately sized and front-loaded, directly stating the tool's purpose without unnecessary elaboration.
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 is incomplete. It does not explain what the tool returns (e.g., list of blocs with details), behavioral aspects like pagination or error handling, or how to interpret parameters in context, leaving significant gaps for an AI 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?
The input schema has 100% description coverage, with clear parameter descriptions (e.g., 'ID da legislatura', 'Número da página'). The description does not add any additional meaning beyond the schema, but since schema coverage is high, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Busca blocos parlamentares da Câmara dos Deputados' (Searches parliamentary blocs of the Chamber of Deputies). It specifies the verb ('busca') and resource ('blocos parlamentares'), but does not differentiate from sibling tools like 'detalhar_bloco' or 'buscar_frentes', which prevents a score of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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 when to use 'buscar_blocos' over 'detalhar_bloco' for detailed information or 'buscar_frentes' for related entities, nor does it specify 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It states it's a search operation, implying read-only behavior, but doesn't mention pagination behavior (despite pagination parameters), rate limits, authentication needs, or what the return format looks like. The description is minimal and lacks important operational 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 a single, efficient sentence that states exactly what the tool does with zero wasted words. It's appropriately sized for a simple search tool and is front-loaded with the core 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?
For a search tool with 3 parameters and no output schema, the description is insufficient. It doesn't explain what constitutes a 'frente parlamentar', how results are returned, what fields are included, or how pagination works. With no annotations and incomplete behavioral context, users lack important information to use this tool effectively.
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 description adds no parameter information beyond what's already in the schema (which has 100% coverage with clear descriptions for idLegislatura, pagina, and itens). The baseline is 3 since the schema does the heavy lifting, but the description doesn't provide additional context about how these parameters affect the search.
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 ('Busca' - searches) and resource ('frentes parlamentares da Câmara dos Deputados' - parliamentary fronts of the Chamber of Deputies), making the purpose immediately understandable. It doesn't distinguish from sibling tools like 'detalhar_frente' or 'frentes_deputado', but it's not vague or tautological.
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 'detalhar_frente' (which likely provides details on a specific front) or 'frentes_deputado' (which likely lists fronts for a specific deputy). There's no mention of prerequisites, 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?
With no annotations provided, the description carries the full burden of behavioral disclosure but provides minimal information. It indicates this is a search operation but doesn't describe what the search returns (list format, fields included), whether results are paginated (though parameters suggest they are), authentication requirements, rate limits, or error conditions. The description doesn't contradict any annotations since none exist, but it fails to provide essential behavioral context for a search tool with 8 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, efficient sentence that states the core purpose without unnecessary words. It's front-loaded with the essential information and contains zero redundant or verbose elements. The Portuguese phrasing is direct and clear, making every word earn its place in the description.
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 search tool with 8 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what the search returns (format, fields), how results are structured, whether there are limitations on date ranges or other filters, or how to interpret empty results. The combination of rich parameter schema but minimal behavioral description creates significant gaps for an agent trying to use this tool effectively.
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 8 parameters thoroughly with descriptions, enums, and constraints. The description adds no parameter-specific information beyond what's in the schema - it doesn't explain how parameters interact, which combinations are most useful, or provide examples of typical queries. The baseline score of 3 reflects adequate parameter documentation entirely through 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 verb ('busca' - searches) and resource ('partidos políticos representados na Câmara dos Deputados' - political parties represented in the Chamber of Deputies). It distinguishes from obvious siblings like 'detalhar_partido' (detail party) by indicating this is a search/filtering operation rather than retrieving details of a specific party. However, it doesn't explicitly differentiate from other search tools like 'buscar_deputados' or 'buscar_blocos' beyond 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when this search tool should be used instead of 'detalhar_partido' for specific party details, or how it relates to 'buscar_blocos' or 'buscar_deputados' for finding related political entities. There's no indication of prerequisites, limitations, or typical use cases for this search functionality.
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 states it 'obtains detailed information,' implying a read-only operation, but doesn't disclose behavioral traits such as authentication needs, rate limits, error handling, or what 'detailed information' includes (e.g., format, completeness). This is inadequate for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized for a simple lookup tool, though it 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?
Given no annotations and no output schema, the description is incomplete. It doesn't explain what 'informações detalhadas' includes (e.g., fields, structure), potential errors, or how results are returned. For a tool with no structured output documentation, this leaves significant gaps for an agent to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'id' documented as 'ID do deputado.' The description adds no additional meaning beyond this, as it doesn't explain parameter semantics like valid ID ranges or sources. With high schema coverage, the baseline score of 3 is appropriate, as the schema does the heavy lifting.
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 'Obtém informações detalhadas de um deputado específico' clearly states the action (obtains detailed information) and resource (a specific deputy). It distinguishes from siblings like 'buscar_deputados' (which likely lists multiple deputies) by specifying detailed information for a single deputy, though it doesn't explicitly name the sibling for comparison.
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 doesn't mention prerequisites like needing a deputy ID, compare with similar tools (e.g., 'obter_perfil_completo_deputado'), or specify use cases. This leaves the agent without context for selection among 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 are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'gets details' but doesn't describe what details are returned, whether it's a read-only operation, error handling, or any constraints like rate limits. For a tool with no annotations, this leaves significant gaps in understanding its 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, clear sentence that efficiently conveys the core purpose without unnecessary words. It's front-loaded with the main action and resource, making it easy to parse. Every part of the sentence earns its place by specifying what is being detailed.
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 annotations and no output schema, the description is insufficient for a tool that retrieves details. It doesn't explain what kind of details are returned (e.g., event metadata, participants, dates), the response format, or potential errors. For a detail-retrieval tool with no structured output information, this leaves the agent with significant uncertainty about the tool's behavior and results.
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 the single parameter 'id' documented as 'ID do evento' (event ID). The description doesn't add any additional meaning beyond this, such as format examples or where to find the ID. With high schema coverage, the baseline score of 3 is appropriate as the schema handles the parameter documentation adequately.
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 detalhes' - Gets details) and resource ('de um evento específico da Câmara' - of a specific Chamber event), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'buscar_eventos' (which likely lists events) or 'eventos_deputado' (events by deputy), though the specificity of 'detalhar' (detail) versus 'buscar' (search) provides some implicit distinction.
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 doesn't mention sibling tools like 'buscar_eventos' for listing events or 'eventos_deputado' for events related to a deputy, nor does it specify prerequisites or contexts for use. The agent must infer usage from the tool name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it 'obtains details' but doesn't disclose behavioral traits such as whether it's a read-only operation, potential rate limits, authentication needs, error handling, or what 'detalhes' entails (e.g., returns structured data or raw text). For a tool with no annotations, this leaves significant gaps in understanding its 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 that directly states the tool's purpose without unnecessary words. It is front-loaded and wastes no space, making it easy to parse quickly.
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 annotations and no output schema, the description is incomplete. It doesn't explain what details are returned, potential errors, or usage context. For a tool that likely returns structured party data, more information is needed to guide the agent effectively, especially without annotations to cover behavioral aspects.
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 the parameter 'id' documented as 'ID do partido'. The description adds no additional meaning beyond this, as it doesn't explain format, valid ranges, or examples. With high schema coverage, the baseline is 3, and the description doesn't compensate with extra insights.
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 'Obtém detalhes de um partido político específico' clearly states the action (obtains details) and resource (specific political party). It distinguishes from sibling tools like 'buscar_partidos' (which likely searches/list parties) by specifying retrieval of details for a specific party. However, it doesn't explicitly contrast with 'detalhar_bloco' or 'detalhar_deputado' which follow a similar pattern for other entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a party ID), contrast with 'buscar_partidos' for listing parties, or specify use cases like fetching metadata for analysis. The description alone implies usage only when you have a specific party ID, but this is not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'obtém informações detalhadas' (gets detailed information), implying a read-only operation, but doesn't specify aspects like authentication requirements, rate limits, error handling, or the format of returned data. For a tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence: 'Obtém informações detalhadas de uma proposição legislativa.' It's front-loaded with the core action and resource, with no wasted words or unnecessary elaboration. This makes it easy for an AI agent to quickly understand the tool's intent.
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 a legislative data tool with no annotations and no output schema, the description is incomplete. It doesn't cover what 'informações detalhadas' includes (e.g., text, status, authors), how results are structured, or potential limitations. For a tool that likely returns rich data, more context is needed to ensure proper 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?
The input schema has 100% description coverage, with one parameter 'id' documented as 'ID da proposição' (ID of the proposition). The description doesn't add any meaning beyond this, as it doesn't explain the ID format, source, or examples. With high schema coverage, the baseline score of 3 is appropriate, as the schema adequately handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Obtém informações detalhadas de uma proposição legislativa' (Gets detailed information about a legislative proposition). It specifies the verb 'obtém' (gets) and the resource 'proposição legislativa' (legislative proposition), making the action clear. However, it doesn't differentiate from sibling tools like 'buscar_proposicoes' (which likely searches for propositions) or 'detalhar_votacao' (which details votes), leaving room for ambiguity in tool selection.
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 doesn't mention prerequisites (e.g., needing a proposition ID), exclusions, or comparisons to siblings such as 'buscar_proposicoes' for searching or 'resumo_tramitacao_proposicao' for summaries. This lack of context could lead to incorrect tool selection by an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'obtains details' but doesn't specify what those details include (e.g., vote results, metadata, timestamps), whether it's a read-only operation, or if there are any rate limits or authentication requirements. This leaves significant gaps for a tool that likely returns structured data about votes.
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, clear sentence with zero wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every part of the sentence earns its place by conveying essential information without redundancy.
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 is incomplete for a tool that likely returns detailed vote information. It doesn't hint at the structure or content of the returned details (e.g., vote outcomes, participant lists, timestamps), leaving the agent with insufficient context to understand what to expect from invoking this 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?
The input schema has 100% description coverage, with the single parameter 'id' documented as 'ID da votação'. The description adds no additional meaning beyond this, such as format examples or where to find the ID. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, though the description doesn't compensate for any 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 'Obtém detalhes de uma votação específica' clearly states the verb ('Obtém detalhes') and resource ('votação específica'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'buscar_votacoes' (which likely searches for multiple votes) or 'votos_votacao' (which might get vote breakdowns), leaving some ambiguity about its unique 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 versus alternatives. It doesn't mention prerequisites (e.g., needing a specific vote ID), exclusions, or comparisons to siblings like 'buscar_votacoes' (for lists) or 'votos_votacao' (for vote details), leaving the agent to infer usage from context 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 full burden for behavioral disclosure. It states this is a list operation, implying it's read-only, but doesn't mention pagination behavior (despite having pagina/itens parameters), rate limits, authentication requirements, or what the return format looks like. For a tool with 6 parameters and no output schema, this leaves 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states exactly what the tool does with zero wasted words. It's appropriately sized for a straightforward list operation and gets directly to the point.
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 tool with 6 parameters, no annotations, and no output schema, the description is insufficient. While concise, it doesn't address key contextual elements like pagination behavior, return format, or how the filtering parameters (dataInicio, dataFim, keywords) interact. The agent would need to infer too much from the schema alone.
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 all parameters are documented in the schema. The description doesn't add any parameter-specific information beyond what's already in the schema. The baseline score of 3 reflects adequate coverage through the schema alone.
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 os discursos de um deputado' clearly states the verb ('lista') and resource ('discursos de um deputado'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'resumo_discursos_deputado' or 'eventos_deputado', but the core action is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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. With sibling tools like 'resumo_discursos_deputado' (summary of speeches) and 'eventos_deputado' (deputy events), there's no indication of when this list-focused tool is preferred over those options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool lists events but does not cover critical aspects like pagination behavior (implied by 'pagina' and 'itens' parameters), rate limits, authentication needs, or error handling. This is a significant gap for a tool with multiple 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, clear sentence in Portuguese that directly states the tool's function without unnecessary words. It is appropriately sized and front-loaded, making it efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no annotations, and no output schema, the description is incomplete. It lacks information on behavioral traits (e.g., pagination, errors), usage context compared to siblings, and output format. This makes it inadequate for an agent to fully understand how to invoke and interpret results.
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 fully documents all parameters (e.g., 'id' for deputy ID, date ranges for filtering). The description does not add any meaning beyond the schema, such as explaining how pagination works or default values. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Lista os eventos de que um deputado participou' (Lists the events that a deputy participated in). It specifies the verb ('lista') and resource ('eventos'), but does not distinguish it from sibling tools like 'buscar_eventos' or 'eventos_orgao', which limits it to a 4.
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 sibling tools such as 'buscar_eventos' (which might search events broadly) or 'eventos_orgao' (which lists events by organization), leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states the basic function without mentioning pagination behavior (implied by 'pagina' and 'itens' parameters), rate limits, authentication requirements, or what format the returned events will have. For a tool with 6 parameters and no output schema, this is insufficient behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence in Portuguese that directly states the tool's purpose without any unnecessary words. It's perfectly front-loaded and wastes no space on 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?
For a tool with 6 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what 'eventos' means in this context, what data the events contain, how pagination works, or any constraints on date ranges. The user must infer everything from parameter names alone.
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 description coverage is 100%, so all parameters are documented in the schema itself. The description doesn't add any additional parameter semantics beyond what's already in the schema descriptions. This meets the baseline expectation when schema coverage is complete.
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 os eventos de um órgão da Câmara' clearly states the action (list) and resource (events of a legislative body), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'buscar_eventos' or 'eventos_deputado', which appear to be related event-finding 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 about when to use this tool versus alternatives like 'buscar_eventos' or 'eventos_deputado'. The description only states what it does, not when it's appropriate or what distinguishes it from similar tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool exports data but lacks critical behavioral details: whether this is a read-only operation, if it modifies data, what permissions are required, how errors are handled, or what the output looks like. The description is minimal and doesn't compensate for the absence of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without fluff. It is appropriately sized for a simple export tool, though it could be more front-loaded with key usage details.
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 (data transformation with 4 parameters) and lack of annotations and output schema, the description is insufficient. It doesn't explain what the exported data looks like, how formats differ, or behavioral constraints, leaving significant gaps for an agent to understand and use the tool effectively.
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 parameters are well-documented in the schema. The description adds no additional semantic context beyond implying that 'tool' refers to source tools and 'params' are data to export, which is already covered. Baseline score of 3 is appropriate as the schema does the heavy lifting.
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 ('Exporta dados') and the resource ('de outras ferramentas'), specifying the transformation to different formats (JSON, CSV, Markdown). It distinguishes itself from sibling tools by focusing on data export rather than analysis or retrieval, though it doesn't explicitly name alternatives for comparison.
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 mentions exporting data from other tools but doesn't specify prerequisites (e.g., needing data from another tool first), exclusions, or typical use cases, leaving the agent to infer 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 are provided, so the description carries full burden. It states it's a listing operation, implying read-only behavior, but doesn't disclose any behavioral traits like pagination, rate limits, authentication needs, error conditions, or output format. For a tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Portuguese that directly states the tool's function without any fluff. It's front-loaded with the core purpose and appropriately sized for a simple lookup tool. 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 no annotations, no output schema, and a simple parameter (100% schema coverage), the description is incomplete. It lacks behavioral context (e.g., what the output looks like, any limitations), which is critical for an agent to use it correctly. For a tool with zero structured metadata beyond input schema, the description should do more to compensate.
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% (the 'id' parameter is fully described in the schema as 'ID do deputado'), so the baseline is 3. The description doesn't add any parameter semantics beyond what's in the schema—it doesn't explain format, constraints, or examples for the ID. It relies entirely on the schema for parameter documentation.
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 verb ('Lista') and resource ('frentes parlamentares') with specific scope ('das quais um deputado é membro'). It distinguishes from sibling tools like 'buscar_frentes' (general search) and 'membros_frente' (reverse lookup), though not explicitly. The purpose is specific but lacks explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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 'buscar_frentes' or 'membros_frente'. The description implies usage for listing a deputy's parliamentary fronts but doesn't specify prerequisites, exclusions, or comparison with similar tools. It's a basic functional statement without contextual 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool lists members but doesn't describe key behaviors: whether it's a read-only operation, how pagination works (given 'pagina' and 'itens' parameters), what the output format looks like, or any rate limits or permissions required. For a tool with 5 parameters and no annotations, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence in Portuguese that directly states the tool's function without unnecessary words. It's front-loaded with the core purpose and appropriately sized for a listing tool, with zero waste or redundancy.
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 (5 parameters, no output schema, no annotations), the description is incomplete. It lacks information on behavioral traits (e.g., pagination, output format), usage context compared to siblings, and doesn't address the absence of an output schema. For a tool that likely returns a list of members with temporal filtering, more guidance is needed for effective agent 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?
The description adds no parameter-specific information beyond what's in the input schema. Since schema description coverage is 100% (all parameters have descriptions in the schema), the baseline score is 3. The description doesn't compensate with additional context, such as explaining how 'dataInicio' and 'dataFim' filter members by date or default behaviors, but it doesn't need to given the schema's completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Lista os membros de um órgão da Câmara' (Lists the members of a Chamber body/organ). It specifies the verb ('Lista') and resource ('membros de um órgão'), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'membros_frente' or 'membros_partido', which list members of other entities, so it doesn't reach the highest score.
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 doesn't mention sibling tools (e.g., 'membros_frente' for front members, 'membros_partido' for party members) or specify contexts where this tool is preferred. Usage is implied from the name and description alone, with no explicit when/when-not instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool lists members, implying a read-only operation, but doesn't clarify if it's paginated (though parameters suggest it might be), what the output format is, or any rate limits or authentication requirements. For a tool with 6 parameters and no annotations, this lack of behavioral detail is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence: 'Lista os membros (deputados) de um partido.' It's front-loaded with the core purpose, has no unnecessary words, and efficiently communicates the tool's function without redundancy. This is an example of optimal 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 tool with 6 parameters, no annotations, and no output schema, the description is incomplete. It doesn't address key contextual aspects like pagination behavior (implied by 'pagina' and 'itens' parameters), what the output looks like (e.g., list of deputies with details), or how date ranges and legislature IDs affect results. This leaves significant gaps for an agent to understand the tool fully.
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 description coverage is 100%, with all parameters clearly documented in the input schema (e.g., 'id' as party ID, 'dataInicio' as start date). The description doesn't add any semantic details beyond what the schema provides, such as explaining how parameters interact (e.g., date ranges filter members by time). Given the high schema coverage, 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 clearly states the tool's purpose: 'Lista os membros (deputados) de um partido' (Lists the members (deputies) of a party). It specifies the verb ('Lista') and resource ('membros (deputados) de um partido'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'buscar_deputados' (search deputies) or 'detalhar_deputado' (detail deputy), which might have overlapping functionality.
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 doesn't mention any prerequisites, exclusions, or compare it to sibling tools such as 'buscar_deputados' or 'detalhar_deputado', leaving the agent to infer usage context based on the tool name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool lists organs for a deputy, implying a read-only operation, but doesn't disclose any behavioral traits such as pagination handling (suggested by 'pagina' and 'itens' parameters), rate limits, authentication needs, or what happens with optional date parameters. The description is minimal and lacks crucial operational context beyond the basic function.
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, clear sentence in Portuguese: 'Lista os órgãos dos quais um deputado é membro'. It is front-loaded with the core purpose, has zero wasted words, and is appropriately sized for a simple list operation. Every part of the sentence earns its place by directly stating the tool's 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 complexity (a list tool with 5 parameters, including optional dates and pagination), no annotations, and no output schema, the description is incomplete. It doesn't address key contextual aspects like the format of returned data (e.g., list of organ names with details), how pagination works, or the effect of date filters. For a tool with multiple parameters and no structured output information, the description should provide more guidance to be fully 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?
The input schema has 100% description coverage, with all parameters clearly documented in Portuguese (e.g., 'ID do deputado', 'Data de início (YYYY-MM-DD)'). The description adds no additional meaning beyond what the schema provides—it doesn't explain how parameters like 'dataInicio' and 'dataFim' filter results or the default behavior for pagination. Given the high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but doesn't detract either.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Lista os órgãos dos quais um deputado é membro' (Lists the organs/organizations of which a deputy is a member). It specifies the verb ('lista' - lists) and resource ('órgãos dos quais um deputado é membro'), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'membros_orgao' (which might show members of an organ) or 'buscar_orgaos' (which might search for organs generally), so it doesn't reach the highest score.
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 doesn't mention sibling tools like 'membros_orgao' (which could be for listing members of a specific organ) or 'orgaos_evento' (which might list organs related to an event), nor does it specify prerequisites or exclusions. Usage is implied by the name and description alone, with no explicit context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states it's a listing operation, implying read-only behavior, but doesn't cover critical aspects like response format, pagination, error handling, or rate limits. For a tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core purpose and appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a simple input schema, the description is incomplete. It lacks details on return values (e.g., what data fields are included in the list), behavioral traits, or usage context, making it inadequate for full 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%, so the schema already documents the 'id' parameter as 'ID da votação'. The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints. Baseline 3 is appropriate when schema does the heavy lifting.
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') and the resource ('orientações de bancada em uma votação específica'), making the purpose understandable. It doesn't explicitly distinguish from siblings like 'detalhar_votacao' or 'votos_votacao', but the focus on 'orientações de bancada' (bench guidance) provides some differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, exclusions, or compare it to sibling tools like 'votos_votacao' or 'comparativo_votacoes_bancadas', leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool generates a ranking but doesn't describe key behaviors: whether it returns a list or summary, if it's paginated or limited, what the output format is (e.g., JSON with fields like name and count), or any performance considerations (e.g., time range limits). For a ranking tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Portuguese that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action ('Gera ranking') and includes all key elements (resource and criteria). There is zero waste, making it highly concise 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 the complexity (a ranking tool with 3 parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't explain the output (e.g., what fields are returned, format), behavioral aspects like sorting or limits, or how it interacts with sibling tools. For a tool that likely returns structured data, more context is needed to guide effective use by an AI 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?
The input schema has 100% description coverage, with clear parameter descriptions in Portuguese. The tool description adds no additional parameter semantics beyond what the schema provides (e.g., it doesn't explain the meaning of 'quantidade', 'aprovadas', or 'tramitacao' in more detail). With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Gera ranking de deputados por quantidade de proposições apresentadas, aprovadas ou em tramitação' (Generates ranking of deputies by quantity of propositions presented, approved, or in progress). It specifies the verb ('gera ranking'), resource ('deputados'), and criteria ('proposições apresentadas, aprovadas ou em tramitação'). However, it doesn't explicitly differentiate from sibling tools like 'ranking_partidos_tamanho' or 'analise_presenca_deputado', which also involve rankings or analyses of deputies.
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 doesn't mention sibling tools like 'ranking_partidos_tamanho' (for party size rankings) or 'analise_presenca_deputado' (for deputy presence analysis), nor does it specify prerequisites, such as needing deputy IDs or years for filtering. Usage is implied by the parameters but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. While 'Lista' implies a read-only operation, the description doesn't specify what 'related' means (e.g., by topic, by author, by legislative process), what format the results come in, whether there are limits on results, or any authentication requirements. This leaves significant behavioral questions unanswered.
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, clear sentence that states exactly what the tool does without any unnecessary words. It's perfectly front-loaded with the core functionality and wastes no space on 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?
For a tool with no annotations and no output schema, the description is insufficiently complete. While it states the basic purpose, it doesn't explain what 'related' means in practice, what format the results take, or any behavioral constraints. Given the lack of structured data elsewhere, the description should provide more context about the tool's operation 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?
The input schema has 100% description coverage, with the single parameter 'id' clearly documented as 'ID da proposição.' The description doesn't add any additional parameter information beyond what the schema already provides, which is appropriate given the high schema coverage. The baseline score of 3 reflects adequate but minimal parameter documentation.
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' - lists) and resource ('proposições relacionadas a uma proposição' - related propositions to a proposition), making the purpose immediately understandable. However, it doesn't distinguish this tool from sibling tools like 'buscar_proposicoes' or 'detalhar_proposicao', which might also handle propositions in different ways.
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. With sibling tools like 'buscar_proposicoes' (search propositions) and 'detalhar_proposicao' (detail proposition), there's no indication of when this specific 'list related propositions' function is appropriate versus those other options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it's a list operation, implying read-only behavior, but doesn't cover aspects like whether it returns all themes or a subset, pagination, error handling, or authentication needs. This leaves significant gaps for an AI agent to understand how to invoke it correctly.
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, clear sentence in Portuguese that directly states the tool's purpose without unnecessary words. It's front-loaded and efficiently communicates the core function, making it easy for an AI agent to parse quickly.
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 is incomplete. It doesn't explain what the output looks like (e.g., list format, data structure), potential errors, or usage context. For a tool with one parameter but no structured output information, more descriptive detail is needed to ensure the AI can use it effectively.
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 the single parameter 'id' documented as 'ID da proposição'. The description doesn't add any extra meaning beyond this, such as format examples or constraints. Since schema coverage is high, the baseline score of 3 is appropriate, as the schema adequately handles parameter semantics.
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 os temas de uma proposição' clearly states the action (list) and resource (themes of a proposition) in Portuguese, making the purpose understandable. However, it doesn't differentiate from sibling tools like 'detalhar_proposicao' or 'tipos_proposicao', which might handle related but different aspects of propositions.
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. For example, it doesn't specify if this is for thematic analysis versus other proposition details, or mention prerequisites like needing a proposition ID first from another tool like 'buscar_proposicoes'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions generating a 'visual timeline' with 'milestones and statistics', but doesn't specify output format (e.g., image, text, JSON), data sources, rate limits, authentication needs, or error handling. For a tool with no annotations and an unspecified output schema, this leaves significant gaps in understanding its 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 in Portuguese that directly states the tool's purpose without unnecessary words. It's front-loaded with the core functionality and includes key details like 'visual timeline', 'milestones', and 'statistics', making it easy to parse quickly.
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 (generating a visual timeline with statistics), lack of annotations, and no output schema, the description is incomplete. It doesn't address critical aspects like the output format (e.g., whether it returns an image, structured data, or a link), how to interpret the timeline, or any limitations (e.g., data availability, processing time). This makes it inadequate for an agent to fully understand how to use the tool effectively.
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 both parameters ('idProposicao' and 'formato') with descriptions and enum values. The description doesn't add any meaning beyond what the schema provides, such as explaining how 'idProposicao' is obtained or the practical differences between 'resumido' and 'completo' formats. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Gera uma linha do tempo visual da tramitação de uma proposição com marcos importantes e estatísticas' (Generates a visual timeline of a proposition's processing with important milestones and statistics). It specifies the verb 'gera' (generates), resource 'linha do tempo' (timeline), and scope 'tramitação de uma proposição' (proposition processing). However, it doesn't explicitly differentiate from sibling tools like 'resumo_tramitacao_proposicao' or 'tramitacoes_proposicao', which might offer similar functionality.
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 doesn't mention any prerequisites, context, or comparisons to sibling tools such as 'resumo_tramitacao_proposicao' or 'tramitacoes_proposicao', leaving the agent to infer usage based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'lista' (list) implies a read-only operation, the description doesn't address important behavioral aspects such as pagination behavior (implied by 'pagina' and 'itens' parameters but not explained), rate limits, authentication requirements, error conditions, or what format the historical data is returned in. For a tool with 5 parameters and no annotations, this is insufficient.
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, clear sentence that efficiently communicates the core function without unnecessary words. It's appropriately sized for a straightforward list operation and gets directly to the point with zero wasted verbiage.
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 tool with 5 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what the tool returns (historical data format), how pagination works, what happens when date ranges are specified, or any behavioral constraints. The single sentence description leaves too many questions unanswered for proper tool selection and 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?
The description doesn't provide any additional parameter information beyond what's already in the schema. However, since schema description coverage is 100% (all 5 parameters have descriptions in Portuguese), the baseline score of 3 is appropriate. The description doesn't add value regarding parameter usage, constraints, or relationships between parameters like 'dataInicio' and 'dataFim'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Lista o histórico de tramitações de uma proposição' (Lists the history of proceedings of a proposition). It specifies the verb ('lista' - list) and resource ('tramitações de uma proposição' - proceedings of a proposition), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'resumo_tramitacao_proposicao' or 'timeline_tramitacao', which likely provide similar or overlapping functionality.
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. There are multiple sibling tools related to propositions (e.g., 'buscar_proposicoes', 'detalhar_proposicao', 'resumo_tramitacao_proposicao', 'timeline_tramitacao'), but the description doesn't indicate when this specific tool is appropriate or what distinguishes it from those other options.
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 states it's a listing operation but doesn't disclose behavioral traits like pagination, rate limits, authentication requirements, what 'últimas' means (e.g., time range or count), or the format of returned data. For a tool with no annotation coverage, this leaves 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Portuguese that directly states the tool's purpose without any unnecessary words. It's appropriately sized and front-loaded with the core functionality.
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 annotations, no output schema, and a single parameter with full schema coverage, the description is incomplete. It doesn't explain what 'últimas' entails (e.g., most recent by date, limited count), the return format, or how it differs from similar sibling tools. For a listing tool in a complex domain with many alternatives, more context is needed.
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 the single parameter 'ordem' with its enum values. The description doesn't add any parameter-specific information beyond what's in the schema, such as default behavior or how ordering affects the 'últimas' aspect. Baseline 3 is appropriate when schema does the heavy lifting.
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' - lists) and resource ('últimas votações realizadas na Câmara dos Deputados' - latest votes in the Chamber of Deputies). It's specific about what the tool does, though it doesn't explicitly differentiate from sibling tools like 'buscar_votacoes' or 'votacoes_evento' which might have overlapping functionality.
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 'buscar_votacoes' or 'votacoes_evento'. It doesn't mention any prerequisites, exclusions, or specific contexts where this tool is preferred 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 are provided, so the description carries the full burden of behavioral disclosure. It states it's a listing operation, implying read-only behavior, but doesn't cover aspects like pagination, rate limits, authentication needs, error handling, or what the output format looks like (e.g., list of vote objects). This leaves significant gaps for a tool with no output 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?
The description is a single, clear sentence in Portuguese: 'Lista as votações ocorridas em um evento'. It's front-loaded with the purpose, has zero waste, and is appropriately sized for a simple tool, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 parameter, no annotations, no output schema), the description is incomplete. It lacks details on behavioral traits (e.g., output format, error cases) and usage guidelines relative to siblings, which are crucial for an agent to invoke it correctly without structured output information.
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 description mentions 'em um evento' (in an event), which aligns with the single parameter 'id' described in the schema as 'ID do evento'. With 100% schema description coverage, the schema already documents the parameter well, so the description adds minimal value beyond reinforcing the context. Baseline 3 is appropriate as the schema does the heavy lifting.
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 as votações ocorridas em um evento' clearly states the verb ('Lista') and resource ('votações'), specifying it's for votes that occurred in an event. It's specific enough to understand the core function, though it doesn't explicitly differentiate from sibling tools like 'buscar_votacoes' or 'votacoes_proposicao', which might have overlapping purposes.
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. With siblings like 'buscar_votacoes' (search votes), 'votacoes_proposicao' (votes on a proposition), and 'detalhar_votacao' (detail a vote), the description lacks context on prerequisites, exclusions, or comparisons, leaving the agent to infer usage based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states this is a listing operation, implying it's likely read-only, but doesn't confirm safety aspects like whether it's non-destructive or has rate limits. It also doesn't describe the return format, pagination behavior, or error conditions, leaving significant gaps for an agent to understand how to use it effectively.
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 in Portuguese that directly states the tool's function without unnecessary words. It's front-loaded with the core purpose and wastes no space on repetition or fluff, making it easy for an agent to parse quickly.
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 (6 parameters, no output schema, and no annotations), the description is incomplete. It lacks information about the return structure (e.g., what data is listed), behavioral traits like pagination or error handling, and differentiation from similar tools. For a listing tool with multiple filtering options, more context is needed to guide proper 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?
The input schema has 100% description coverage, providing clear documentation for all 6 parameters (e.g., 'ID do órgão', 'Data de início (YYYY-MM-DD)'). The description adds no additional parameter semantics beyond what's in the schema, such as explaining relationships between parameters (e.g., how 'idProposicao' filters results) or usage tips. With high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Lista as votações de um órgão da Câmara' clearly states the action (list) and resource (votações/votes of an órgão/organ), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'votacoes_evento' (votes of an event) or 'votacoes_proposicao' (votes of a proposition), which have similar listing functions for different entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 doesn't mention sibling tools like 'votacoes_evento' or 'votacoes_proposicao' that might serve similar purposes for different contexts, nor does it specify prerequisites or constraints beyond the implied need for an organ ID.
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. While 'Lista' (Lists) implies a read-only operation, it doesn't specify whether this returns all votes or is paginated, what format the results take, whether there are rate limits, or any authentication requirements. For a tool with 3 parameters and no annotation coverage, this leaves significant behavioral questions unanswered.
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, clear sentence that states the tool's core function without any unnecessary words. It's appropriately sized for a simple listing tool and gets straight to the point with zero wasted verbiage.
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 tool with 3 parameters, no annotations, and no output schema, the description is insufficiently complete. While it states what the tool does, it doesn't explain what the output looks like, how results are structured, whether there are limitations on the data returned, or any error conditions. The agent would need to guess about the return format and behavioral characteristics.
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 description coverage is 100%, so all parameters are documented in the schema itself. The description doesn't add any parameter-specific information beyond what's already in the schema descriptions (ID da proposição, Ordem de listagem, Campo para ordenação). This meets the baseline expectation when schema documentation is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'Lista as votações relacionadas a uma proposição' (Lists votes related to a proposition), which is a specific verb+resource combination. It distinguishes this from sibling tools like 'buscar_votacoes' (search votes) and 'votacoes_evento' (votes by event) by focusing specifically on proposition-related votes. However, it doesn't explicitly differentiate from 'detalhar_votacao' (detail vote), which might be a more specific lookup tool.
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 doesn't mention when this tool is appropriate versus 'buscar_votacoes' (which might search votes more broadly) or 'detalhar_votacao' (which might provide detailed information about a specific vote). There's no context about prerequisites, limitations, 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 are provided, so the description carries the full burden of behavioral disclosure. It states the tool lists deputies related to an event, implying a read-only operation, but doesn't specify details like pagination, rate limits, authentication needs, or what 'presentes ou relacionados' entails (e.g., attendance vs. association). For a tool with no annotations, this is insufficient to fully understand its 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, clear sentence that efficiently conveys the tool's purpose without unnecessary words. It is front-loaded with the core action and resource, making it easy to parse. There is no wasted text, earning a top score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one required parameter, no output schema, no annotations), the description is minimally adequate. It states what the tool does but lacks details on usage context, behavioral traits, or output format. Without annotations or an output schema, more guidance would be beneficial, but it meets the basic threshold for a simple list 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 has 100% description coverage, with the parameter 'id' documented as 'ID do evento'. The description adds no additional semantic information beyond this, such as format examples or constraints. Given the high schema coverage, the baseline score of 3 is appropriate, as the schema adequately covers the parameter meaning without extra value from 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's purpose: 'Lista os deputados presentes ou relacionados a um evento' (Lists deputies present or related to an event). It specifies the verb ('Lista') and resource ('deputados'), and indicates the scope ('presentes ou relacionados a um evento'). However, it does not explicitly differentiate from sibling tools like 'eventos_deputado' or 'detalhar_evento', which might have overlapping functionality, so it doesn't reach the highest score.
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 doesn't mention prerequisites, exclusions, or compare it to sibling tools such as 'buscar_deputados' or 'eventos_deputado', which could be relevant for similar queries. This lack of contextual guidance limits its utility for an AI agent.
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 states the tool 'obtains details' but doesn't disclose behavioral traits such as whether it's a read-only operation, what kind of details are returned (e.g., members, dates, statistics), error handling, or rate limits. For a tool with no annotations, this leaves significant gaps in understanding its 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, clear sentence with no wasted words. It's front-loaded with the core purpose ('Obtém detalhes'), making it easy to scan and understand quickly. Every part of the sentence contributes directly to explaining the tool's function.
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 low complexity (1 parameter, no nested objects) and high schema coverage, the description is minimally adequate. However, with no annotations and no output schema, it doesn't fully compensate by explaining return values or behavioral context. It meets basic needs but lacks depth 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?
The input schema has 100% description coverage, with the 'id' parameter documented as 'ID do bloco (número ou string)'. The description doesn't add any parameter semantics beyond this, such as examples of valid IDs or where to obtain them. With high schema coverage, the baseline score of 3 is appropriate, as the schema adequately covers parameter 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 'Obtém detalhes de um bloco parlamentar específico' clearly states the action (obtain details) and resource (specific parliamentary block). It distinguishes from sibling tools like 'buscar_blocos' (which likely searches or lists blocks) by specifying it's for detailed information about a specific block. However, it doesn't explicitly contrast with other 'detalhar_' tools (e.g., 'detalhar_deputado'), though the resource type makes 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 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 doesn't mention prerequisites (e.g., needing a block ID from 'buscar_blocos'), exclusions, or comparisons to similar tools like 'detalhar_partido' or 'buscar_blocos'. The agent must infer usage from the name and context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'obtém detalhes' (gets details), implying a read-only operation, but does not specify what details are returned, potential errors (e.g., invalid ID), or any rate limits or authentication requirements. For a tool with no annotations, this leaves significant gaps in understanding its behavior and constraints.
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, clear sentence: 'Obtém detalhes de uma frente parlamentar específica.' It is front-loaded with the core purpose, has no redundant words, and efficiently communicates the tool's function without unnecessary elaboration. This makes it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one required parameter, no output schema, no annotations), the description is minimally adequate. It states what the tool does but lacks details on output format, error handling, or usage context. For a basic lookup tool, this might suffice, but it does not provide a complete picture for effective use, especially without annotations to fill in behavioral gaps.
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 the parameter 'id' documented as 'ID da frente' (ID of the front). The description does not add any additional meaning beyond this, such as format examples or sourcing instructions. Given the high schema coverage, a baseline score of 3 is appropriate, as the schema adequately covers parameter semantics without extra value from 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's purpose: 'Obtém detalhes de uma frente parlamentar específica' (Gets details of a specific parliamentary front). It specifies the verb 'obtém' (gets) and the resource 'frente parlamentar' (parliamentary front), making the action and target explicit. However, it does not differentiate from sibling tools like 'buscar_frentes' (search fronts) or 'membros_frente' (front members), which could imply similar functionality, so it misses full sibling distinction.
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, such as needing an ID from another tool like 'buscar_frentes', or compare it to siblings like 'detalhar_bloco' (detail block) or 'membros_frente' (front members). Without such context, users may struggle to select the correct tool among related options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Obtém detalhes' implies a read-only operation, it doesn't explicitly state whether this requires authentication, has rate limits, what format the details are returned in, or if there are any side effects. For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior beyond the basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that directly states the tool's purpose without any unnecessary words. It's front-loaded with the core action and resource, making it immediately understandable. Every word earns its place in conveying the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's apparent simplicity (single required parameter, no output schema, no annotations), the description is minimally adequate. It states what the tool does but lacks context about when to use it versus siblings, behavioral details, or output expectations. For a read operation with good schema coverage, it meets basic needs but leaves room for improvement in guidance and transparency.
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 the single parameter 'id' clearly documented as 'ID do órgão' (ID of the body). The description doesn't add any additional parameter information beyond what the schema provides, such as format examples or valid ranges. With complete schema coverage, the baseline score of 3 is appropriate as the schema does the heavy lifting.
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 verb ('Obtém detalhes' - Gets details) and resource ('de um órgão específico da Câmara' - of a specific Chamber body), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'buscar_orgaos' (which likely lists multiple bodies) or 'orgaos_deputado' (which might list bodies related to a deputy), but the specificity of 'detalhar' (detail) versus 'buscar' (search/find) provides some implicit distinction.
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. There are multiple sibling tools that involve 'orgaos' (bodies), such as 'buscar_orgaos' (likely for listing), 'orgaos_deputado' (bodies of a deputy), and 'eventos_orgao' (events of a body), but the description doesn't indicate when this detailed view is appropriate versus those other tools. No 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?
No annotations are provided, so the description carries full burden. It states this is a list operation but doesn't disclose behavioral traits like whether it returns all leaders or only current ones, pagination behavior, rate limits, authentication requirements, or what 'leaders' specifically means in this context (e.g., formal leadership positions).
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, clear sentence that efficiently communicates the core purpose without unnecessary words. It's appropriately sized for a simple lookup tool and front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with one parameter and no output schema, the description is minimally adequate. However, without annotations or output schema, it should ideally provide more context about what 'leaders' means and what the return format looks like. The completeness is borderline given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with the single parameter 'id' documented as 'ID do partido'. The description doesn't add any additional parameter semantics beyond what the schema already provides, such as format examples or where to find party IDs. With complete schema coverage, 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 verb ('Lista' - lists) and resource ('líderes de um partido na Câmara' - leaders of a party in the Chamber), making the purpose immediately understandable. It doesn't explicitly distinguish from sibling tools like 'membros_partido' or 'detalhar_partido', but the focus on 'leaders' provides some implicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like 'membros_partido' (which might list all members) or 'detalhar_partido' (which might provide party details). The description doesn't mention prerequisites, context, or exclusions for 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 carries the full burden of behavioral disclosure. It states the tool lists members, implying a read-only operation, but doesn't specify whether it returns all members, paginated results, or any constraints like rate limits or authentication needs. For a tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence: 'Lista os membros de uma frente parlamentar'. It's front-loaded with the core purpose, has zero wasted words, and is appropriately sized for a simple tool. Every part of the sentence earns its place by directly stating the tool's function.
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 low complexity (one required parameter, no output schema, no annotations), the description is minimally complete. It states what the tool does but lacks behavioral details (e.g., response format, pagination) and usage context. Without annotations or output schema, the description should do more to compensate, but it's adequate for a basic listing 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?
The input schema has 100% description coverage, with the 'id' parameter documented as 'ID da frente'. The description doesn't add any additional meaning beyond this, such as format examples or context about where to obtain the ID. Given the high schema coverage, the baseline score of 3 is appropriate, as the schema already provides adequate parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Lista os membros de uma frente parlamentar' (Lists the members of a parliamentary front). It uses a specific verb ('Lista') and resource ('membros de uma frente parlamentar'), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'frentes_deputado' or 'detalhar_frente', which reduces clarity in context.
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 doesn't mention prerequisites (e.g., needing a front ID), exclusions, or comparisons to similar tools like 'frentes_deputado' (which might list fronts for a deputy) or 'detalhar_frente' (which could provide front details). This leaves the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'obtém' (gets) information, implying a read-only operation, but doesn't clarify aspects like authentication requirements, rate limits, error handling, or the format of the returned composition data. For a tool with no annotations, this leaves significant gaps in understanding its behavior and constraints.
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, clear sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action ('obtém') and resource, making it easy to understand at a glance. There's no redundancy or fluff, earning a high score for efficiency and structure.
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 moderate complexity (fetching board composition for a legislature), the description is minimally adequate. It lacks an output schema, so users don't know the structure of the returned data (e.g., what 'composição' includes). With no annotations and incomplete behavioral details, it relies heavily on the input schema for parameter info. This makes it functional but incomplete for full contextual 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?
The input schema has 100% description coverage, with clear parameter descriptions (e.g., 'ID da legislatura', 'Data de início (YYYY-MM-DD)'). The tool description doesn't add any additional semantic context beyond what the schema provides, such as explaining how parameters interact (e.g., if 'dataInicio' and 'dataFim' filter results within the legislature). With high schema coverage, the baseline score of 3 is appropriate, as the schema adequately documents parameters without extra help from 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's purpose: 'Obtém a composição da mesa diretora de uma legislatura' (Gets the composition of the board of directors of a legislature). It specifies the verb ('obtém' - gets) and resource ('mesa diretora de uma legislatura' - board of directors of a legislature), making the action and target explicit. However, it doesn't differentiate from sibling tools like 'detalhar_legislatura' or 'buscar_legislaturas', which might provide related but different information.
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 doesn't mention prerequisites, such as needing a specific legislature ID, or compare it to sibling tools like 'detalhar_legislatura' (which might give general legislature details) or 'buscar_legislaturas' (which might list legislatures). Without this context, users must infer usage from the tool name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states this is a list operation, implying it's likely read-only and non-destructive, but doesn't confirm this or disclose other behavioral traits such as data freshness, pagination, error handling, or authentication needs. For a tool with no annotations, this leaves significant gaps in understanding its 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 that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly. Every part of the sentence contributes to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (single parameter, no output schema, no annotations), the description is minimally complete. It covers the basic purpose but lacks details on usage context, behavioral traits, and output format. For a simple list tool, this might suffice, but it doesn't provide enough information for optimal agent decision-making without 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?
The input schema has 100% description coverage, with the 'id' parameter clearly documented as 'ID do deputado'. The description doesn't add any meaning beyond this, such as format examples or sourcing details. With high schema coverage, the baseline score of 3 is appropriate, as the schema adequately handles parameter semantics.
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 verb ('Lista') and resource ('ocupações registradas de um deputado'), making the purpose specific and understandable. It distinguishes from siblings like 'detalhar_deputado' or 'obter_perfil_completo_deputado' by focusing on occupations rather than general details or full profiles, though it doesn't explicitly mention these distinctions.
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. For example, it doesn't clarify if this is for current or historical occupations, or how it differs from related tools like 'profissoes_deputado' (which might list professions) or 'obter_perfil_completo_deputado' (which could include occupations). The description lacks 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it's a listing operation, implying read-only behavior, but doesn't specify whether it returns all organs or a filtered subset, pagination details, error conditions, or authentication requirements. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence in Portuguese that directly states the tool's function without unnecessary words. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.
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 low complexity (single required parameter, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks details on usage context, behavioral traits, or output format, which would be helpful for an agent to use it effectively without trial and error.
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 description implies the 'id' parameter is for an event, matching the schema's 100% coverage where 'id' is described as 'ID do evento'. Since schema coverage is high, the baseline is 3, and the description adds no additional parameter semantics 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 clearly states the tool's purpose as 'Lista os órgãos relacionados a um evento' (Lists the organs/agencies related to an event), which is a specific verb+resource combination. It distinguishes itself from sibling tools like 'buscar_orgaos' (search organs) and 'orgaos_deputado' (organs of a deputy) by focusing on event-related organs, though it doesn't explicitly contrast with these alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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 doesn't mention prerequisites, context for usage, or differentiate from similar tools like 'buscar_orgaos' or 'orgaos_deputado', leaving the agent to infer based on the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes a read operation ('obtém'), implying it is likely non-destructive, but does not confirm this or address other behavioral traits like error handling, rate limits, authentication needs, or response format. For a tool with no annotations, this leaves significant gaps in understanding how it behaves beyond its basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that clearly states the tool's purpose without unnecessary words. It is front-loaded with the core action and resource, and the parenthetical clarification adds useful context without redundancy. Every part of the description earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a simple read operation with one parameter) and the absence of annotations and output schema, the description is minimally adequate. It explains what the tool does but lacks details on behavior, usage context, or output format. For a tool with no structured data beyond the input schema, it provides a basic understanding but leaves gaps that could hinder effective agent 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?
The input schema has 100% description coverage, with the parameter 'id' documented as 'ID do evento' (ID of the event). The description does not add any additional semantic context beyond this, such as format examples or constraints. Given the high schema coverage, a baseline score of 3 is appropriate, as the schema adequately covers the parameter meaning without extra value from 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's purpose: 'Obtém a pauta de um evento (proposições a serem discutidas/votadas)' which translates to 'Gets the agenda of an event (propositions to be discussed/voted on).' It specifies the verb 'obtém' (gets) and the resource 'pauta de um evento' (agenda of an event), with additional clarification in parentheses. However, it does not explicitly differentiate from sibling tools like 'detalhar_evento' or 'votacoes_evento', which might provide overlapping or related information about events.
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 any prerequisites, context, or exclusions, such as when to choose this over 'detalhar_evento' for event details or 'votacoes_evento' for voting information. Without such guidelines, the agent must infer usage from the tool name and description 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 states it's a list operation, implying read-only behavior, but doesn't mention any constraints like rate limits, authentication needs, or what the output format might be (e.g., list of strings, structured data). This leaves gaps for an AI agent to understand how to handle the tool effectively.
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, clear sentence that directly states the tool's purpose without any unnecessary words or fluff. It's front-loaded and efficiently communicates the core functionality, making it easy to parse.
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 simple nature of the tool (one parameter, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks details on output format, error handling, or behavioral traits, which could be important for an AI agent to use it correctly in 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?
The input schema has 100% description coverage, with the single parameter 'id' clearly documented as 'ID do deputado'. The description doesn't add any extra meaning beyond this, such as format examples or valid ranges, but the schema provides adequate information, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/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 ('profissões registradas de um deputado'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'ocupacoes_deputado' or 'obter_perfil_completo_deputado', which might have overlapping functionality, so it doesn't reach the highest score.
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 'ocupacoes_deputado' or 'obter_perfil_completo_deputado', nor does it mention any prerequisites or exclusions. It's a basic statement of purpose 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it's a listing operation ('Lista'), implying it's likely read-only, but doesn't confirm this or describe other behaviors such as pagination, error handling, or data format. For a tool with no annotations, this leaves significant gaps in understanding how it behaves beyond the basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence in Portuguese that efficiently conveys the tool's purpose without unnecessary words. It's front-loaded with the key action and resource, making it easy to parse. There's no wasted language, and it fits well within typical length expectations for tool descriptions.
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 low complexity (one parameter, no output schema, no annotations), the description is minimally adequate. It states what the tool does but lacks details on usage context, behavioral traits, or output format. Without annotations or an output schema, the description should ideally provide more guidance on what to expect, but it meets the basic requirement for a simple listing 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?
The input schema has 100% description coverage, with one parameter 'id' documented as 'ID da votação' (voting ID). The description adds no additional parameter semantics beyond what the schema provides, such as format examples or sourcing hints. With high schema coverage, the baseline score of 3 is appropriate, as the schema adequately covers the parameter details without extra help from 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's purpose: 'Lista os votos de deputados em uma votação específica' (Lists the votes of deputies in a specific voting). It specifies the verb ('Lista'), resource ('votos de deputados'), and scope ('em uma votação específica'), making it clear what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'detalhar_votacao' or 'votacoes_evento', which might provide related but different information.
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 doesn't mention prerequisites (e.g., needing a voting ID from another tool), exclusions, or comparisons to siblings like 'detalhar_votacao' (which might give voting details without votes) or 'historico_votos_deputado' (which focuses on a deputy's vote history). This lack of context could lead to misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the action ('analisa e agrega') but does not describe key behavioral traits such as data source, update frequency, permissions required, rate limits, or error handling. For a tool with no annotations, this leaves significant gaps in understanding how it operates beyond basic functionality.
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 that front-loads the core functionality without unnecessary words. It directly states what the tool does and the aggregation options, making it easy to understand quickly. Every part of the sentence contributes to clarifying the tool's 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 the complexity of analyzing expenses with multiple parameters and no output schema, the description is insufficient. It lacks details on what the output looks like (e.g., format, structure), how results are presented for different aggregation types, or any limitations (e.g., data availability, time ranges). Without annotations or an output schema, the description should provide more context to ensure proper 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%, so the schema already documents all parameters thoroughly. The description adds minimal value beyond the schema by mentioning aggregation types ('totais, médias ou por categoria'), which aligns with the 'tipoAgregacao' enum. However, it does not provide additional semantic context, such as examples of categories or interpretation of results, beyond what the schema specifies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: analyzing and aggregating expenses of deputies from a political party over a period, with totals, averages, or by category. It specifies the verb ('analisa e agrega'), resource ('despesas dos deputados de um partido'), and scope ('em um período'). However, it does not explicitly differentiate from sibling tools like 'despesas_deputado' or 'resumo_despesas_deputado', which might handle individual deputy expenses.
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 by mentioning aggregation types ('totais, médias ou por categoria'), but it does not provide explicit guidance on when to use this tool versus alternatives. For example, it does not specify when to choose this over 'despesas_deputado' for individual expenses or other expense-related tools. The context is clear but lacks comparative or exclusionary 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions search functionality and date filtering but doesn't describe pagination behavior (implied by parameters), rate limits, authentication needs, error conditions, or what the return format looks like. For an 11-parameter search tool with no output schema, this leaves significant behavioral 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?
The description is appropriately concise with two sentences: one stating the purpose and scope, and one providing a practical tip. Both sentences add value, and the structure is front-loaded with the core functionality. It could be slightly improved by explicitly mentioning pagination or result format.
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 (11 parameters, no annotations, no output schema), the description provides adequate basic context about what the tool searches for and a useful tip about date filtering. However, it doesn't address important aspects like result format, pagination behavior, or how to interpret the search results, leaving the agent to infer these from parameter names alone.
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 11 parameters thoroughly with descriptions, examples, defaults, and constraints. The description adds minimal value by specifically calling out 'dataInicio + dataFim' as a useful combination, but doesn't provide additional semantic context beyond what's in the schema. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('busca') and resource ('eventos da Câmara dos Deputados') with examples of event types (reuniões, sessões, audiências). It distinguishes from siblings like 'detalhar_evento' by indicating this is a search/filtering tool rather than a detail view, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage guidance through the DICA (tip) about using date ranges for specific periods, suggesting this is useful for temporal filtering. However, it doesn't explicitly state when to use this versus other event-related tools like 'eventos_deputado' or 'eventos_orgao', 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that the tool searches by various criteria and provides usage tips, but fails to disclose critical behavioral traits: it doesn't indicate whether this is a read-only operation (though implied by 'busca'), doesn't mention pagination behavior (despite having 'pagina' and 'itens' parameters), doesn't describe the return format or structure, and doesn't mention rate limits or authentication requirements. The description adds minimal behavioral context beyond the basic search function.
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 perfectly concise and well-structured: one sentence stating the purpose followed by a practical usage tip. Every word earns its place, with no redundancy or unnecessary information. The front-loaded purpose statement makes the tool's function immediately clear, and the tip provides actionable guidance 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?
Given the tool's complexity (11 parameters, no output schema, no annotations), the description is incomplete. While concise, it doesn't address important contextual aspects: it doesn't describe the return format (critical for a search tool with no output schema), doesn't explain pagination behavior despite having pagination parameters, doesn't mention error conditions or limitations, and doesn't provide guidance on parameter combinations beyond the basic examples. For a tool with this many parameters and no structured output documentation, the description should do more to help the agent understand what to expect.
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 description adds some parameter semantics by mentioning 'nome', 'uf', and 'partido' in the usage tip, but with 100% schema description coverage, the input schema already provides comprehensive documentation for all 11 parameters including descriptions, examples, enums, defaults, and constraints. The description's tip about combining 'uf' + 'partido' is helpful but doesn't add significant meaning beyond what's already in the well-documented schema. This meets the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Busca deputados por diversos critérios' (Searches deputies by various criteria). It specifies the verb ('busca') and resource ('deputados'), making the function immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'detalhar_deputado' or 'obter_perfil_completo_deputado', which likely provide detailed information about specific deputies rather than searching/filtering multiple deputies.
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 clear usage guidance with the 'DICA' (TIP) section: 'Use "nome" para busca por nome, ou combine "uf" + "partido" para filtrar por região e partido.' This gives practical examples of when to use specific parameter combinations. However, it doesn't explicitly state when NOT to use this tool (e.g., vs. sibling tools for detailed single-deputy information) or mention alternatives for different search 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 are provided, so the description carries the full burden of behavioral disclosure. It mentions 'incluindo disciplina partidária' (including party discipline), which adds some context about what the tool calculates. However, it doesn't describe the return format (e.g., structured data, summary statistics), potential limitations (e.g., data availability, error handling), or performance aspects (e.g., response time, data freshness), leaving significant gaps for a tool with analytical functions.
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 in Portuguese that directly states the tool's purpose without unnecessary words. It is front-loaded with the core function ('Compara como diferentes bancadas partidárias votaram') and adds a key feature ('incluindo disciplina partidária') concisely. There is no redundancy or fluff, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no annotations, and no output schema, the description is moderately complete. It clearly defines the tool's purpose and hints at behavioral aspects (party discipline analysis), but lacks details on output structure, error conditions, or usage constraints. Given the analytical nature and absence of structured behavioral data, more context would be beneficial, but it meets a minimum viable level by explaining what the tool does.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for all three parameters: 'idVotacao' (vote ID), 'incluirOrientacoes' (include leadership guidance and party discipline calculation), and 'incluirAusentes' (include absent deputies in the count). The description adds minimal value beyond the schema by implying the tool uses 'idVotacao' and mentions 'disciplina partidária' (party discipline), which loosely relates to 'incluirOrientacoes'. Given the high schema coverage, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Compara como diferentes bancadas partidárias votaram em uma votação específica, incluindo disciplina partidária' (Compares how different party blocs voted in a specific vote, including party discipline). It specifies the verb (compare), resource (party bloc votes), and scope (specific vote with party discipline analysis), distinguishing it from sibling tools like 'votos_votacao' (individual votes) or 'orientacoes_votacao' (voting guidance).
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 context through 'em uma votação específica' (in a specific vote), suggesting it should be used when analyzing voting patterns by party blocs for a particular vote. However, it doesn't explicitly state when to use this tool versus alternatives like 'votos_votacao' (which might show individual votes) or 'detalhar_votacao' (which might provide vote details), 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 carries the full burden of behavioral disclosure. It mentions the tool 'suggests' tools, implying it's a read-only advisory function, but doesn't describe what the suggestion output looks like (e.g., list of tool names, explanations), whether it has limitations (e.g., based on available data), or any performance considerations. For a tool with no annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that are front-loaded with the core purpose and followed by usage guidance. Every word earns its place, with no redundancy or fluff. It efficiently communicates the essential information in a structured manner.
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 advisory nature, single parameter with full schema coverage, and no output schema, the description is minimally adequate. It covers purpose and usage but lacks details on behavioral aspects like output format or limitations. With no annotations and no output schema, the description should do more to compensate, but it meets the bare minimum for a simple suggestion 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?
The description doesn't explicitly mention parameters, but the input schema has 100% description coverage for its single parameter 'consulta', which is well-documented with examples. Since schema coverage is high, the baseline is 3 even without parameter details in the description. The description's context about 'consultas complexas' (complex queries) indirectly relates to the parameter but doesn't add specific semantic 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's purpose: 'Sugere quais ferramentas usar para uma determinada consulta sobre a Câmara dos Deputados' (Suggests which tools to use for a specific query about the Chamber of Deputies). It specifies the verb 'sugere' (suggests) and the resource 'ferramentas' (tools) with the domain context. However, it doesn't explicitly differentiate from sibling tools like 'diagnosticar_consulta', which might have overlapping functionality.
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 clear usage context: 'Use antes de fazer consultas complexas para entender o melhor caminho' (Use before making complex queries to understand the best path). This indicates when to use it (before complex queries) and implies its role as a planning tool. However, it doesn't explicitly state when not to use it or name alternatives among the many 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions search functionality but doesn't describe important behavioral aspects like pagination behavior (implied by 'pagina' and 'itens' parameters but not explained), rate limits, authentication requirements, or what happens when no parameters are provided (all parameters are optional). The tip about starting with date ranges or proposition ID is helpful context, but more behavioral details 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 perfectly concise and well-structured: one clear purpose statement followed by a practical usage tip. Every sentence earns its place, and the information is front-loaded with the most important guidance immediately following the purpose statement. No wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (9 parameters, no annotations, no output schema), the description is adequate but has clear gaps. It explains the purpose and gives usage tips, but doesn't describe the return format, error conditions, or behavioral constraints. For a search tool with many parameters and no output schema, more context about what results to expect would be helpful. The description is complete enough for basic usage but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 9 parameters thoroughly with descriptions, examples, defaults, and constraints. The description adds marginal value by suggesting two common usage patterns (date range vs. proposition ID search), but doesn't provide additional parameter semantics beyond what's already in the schema. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Busca votações realizadas na Câmara dos Deputados' (Searches for votes held in the Chamber of Deputies). This specifies the verb ('busca') and resource ('votações'), and the location context is helpful. However, it doesn't explicitly differentiate from sibling tools like 'votacoes_evento', 'votacoes_orgao', or 'votacoes_proposicao', which appear to be more specific variants.
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 clear usage guidance: 'DICA: Comece com dataInicio + dataFim para buscar votações em um período, ou use idProposicao para votações de uma proposição específica.' This gives practical advice on when to use different parameter combinations. However, it doesn't explicitly state when NOT to use this tool versus the more specific sibling tools (e.g., 'votacoes_proposicao'), which would be needed for a perfect score.
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. While it mentions the tool 'sugere o melhor fluxo de ferramentas' (suggests the best tool flow), it doesn't disclose behavioral traits like what format the suggestion comes in, whether it's interactive, if it requires specific permissions, or what happens when no suitable tools are found. For a guidance tool with zero annotation coverage, this is inadequate.
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 just two sentences that each serve a distinct purpose: the first states what the tool does, the second states when to use it. There's zero wasted language and it's perfectly front-loaded with the core functionality.
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 (analysis and suggestion function), lack of annotations, and no output schema, the description is somewhat incomplete. It explains the purpose and usage well but doesn't address what the tool actually returns or how the suggestion mechanism works. For a guidance tool with no structured output information, more behavioral 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 description coverage is 100%, providing a clear description and examples for the 'objetivo' parameter. The description doesn't add any additional parameter semantics beyond what's already in the schema, so it meets the baseline of 3 where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Analisa o objetivo do usuário e sugere o melhor fluxo de ferramentas a usar' (Analyzes the user's objective and suggests the best tool flow to use). It specifies the verb 'analisa' (analyzes) and resource 'objetivo do usuário' (user's objective), but doesn't explicitly differentiate from sibling tools like 'sugerir_ferramentas' which might have similar functionality.
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?
The description provides explicit usage guidance: 'Use esta ferramenta quando não souber qual ferramenta escolher ou quiser evitar erros' (Use this tool when you don't know which tool to choose or want to avoid errors). This clearly defines when to use this tool versus alternatives, addressing the agent's decision-making context directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool returns a ranking but does not disclose key behavioral traits such as data freshness, potential rate limits, authentication requirements, or error handling. For a read-only tool with no annotation coverage, this leaves significant gaps in understanding its operational 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 appropriately sized and front-loaded, with the core purpose stated first and example questions added for clarity. Every sentence earns its place by enhancing understanding without redundancy or unnecessary detail.
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 moderate complexity (3 parameters, no output schema, no annotations), the description is adequate but incomplete. It explains what the tool does and when to use it, but lacks details on behavioral aspects like data sources, limitations, or return format. Without annotations or an output schema, more context would be beneficial for effective agent 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?
The schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description does not add any additional meaning or context about the parameters beyond what the schema provides, such as explaining why 'confirmar' is required or typical use cases for 'idLegislatura' and 'limite'. Baseline 3 is appropriate when the schema does the heavy lifting.
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 with a specific verb ('Retorna') and resource ('ranking dos maiores partidos na Câmara por número de deputados'), distinguishing it from sibling tools like 'buscar_partidos' (which likely lists all parties) and 'detalhar_partido' (which provides details for a specific party). It also includes example questions that illustrate its use case.
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 clear context for when to use this tool ('Ideal para perguntas como...'), listing specific question types it addresses. However, it does not explicitly mention when not to use it or name alternative tools for related queries, such as 'buscar_partidos' for unfiltered party lists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes the search behavior (partial name matching, case-insensitive) and preference for acronym search, which is useful. However, it doesn't mention pagination behavior (though parameters exist), rate limits, authentication requirements, or what the response format looks like. For a search tool with 9 parameters and no annotations, this leaves 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - just two sentences that efficiently convey the tool's purpose and main usage patterns. Every word earns its place, with clear examples that help understanding without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 9 parameters, no annotations, and no output schema, the description is somewhat incomplete. While it covers the core search functionality well, it doesn't address pagination behavior, result format, or error conditions. The high parameter count and lack of output schema mean users need more context about what to expect from this 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 the schema already documents all 9 parameters thoroughly. The description adds some value by explaining the search logic for 'sigla' and 'nome' parameters (acronym vs. partial name search, case-insensitive), but doesn't provide additional context for the other 7 parameters beyond what's in the schema. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 for 'órgãos da Câmara' (chamber bodies) and provides specific examples of what types of bodies are included (commissions, boards, councils, etc.). It distinguishes itself from sibling tools like 'detalhar_orgao' (which details a specific body) by focusing on search functionality.
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 clear context on when to use this tool: when searching for bodies by acronym (e.g., 'CE') or by partial name (e.g., 'educação'). It mentions that acronym search is preferred if known, offering some usage guidance. However, it doesn't explicitly state when NOT to use it or mention specific alternatives like 'detalhar_orgao' for getting detailed information about a known body.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the tool searches by various criteria, which implies it's a read-only operation, but doesn't explicitly state this. It provides a usage tip about parameter combinations, which adds some behavioral context, but doesn't cover other aspects like rate limits, authentication needs, or error handling. The description adds value but doesn't fully compensate for the lack of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and well-structured: one sentence stating the purpose, followed by a practical tip. Every sentence earns its place, with zero waste. It's front-loaded with the core functionality and provides actionable guidance efficiently.
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 (19 parameters, no annotations, no output schema), the description is somewhat complete but has gaps. It explains the purpose and provides usage guidance, which helps, but doesn't cover behavioral aspects like what the return format looks like, pagination details, or error scenarios. For a search tool with many parameters, more context about results 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 description coverage is 100%, so the schema already documents all 19 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema. It provides general advice about starting with few parameters, but this doesn't enhance the semantic understanding of individual parameters. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Busca proposições legislativas (PLs, PECs, MPs, etc.) por diversos critérios.' It specifies the resource (legislative propositions) and the action (search by various criteria). However, it doesn't explicitly differentiate from sibling tools like 'detalhar_proposicao' or 'ranking_proposicoes_autor', which might have overlapping functionality.
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?
The description provides explicit usage guidance: 'DICA: Comece com poucos parâmetros (ex: siglaTipo + ano, ou apenas keywords) e adicione filtros gradualmente.' This tells the agent how to approach using the tool effectively, including starting with minimal parameters and adding filters gradually. This is practical advice for optimal tool invocation.
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 of behavioral disclosure. It does well by detailing the return structure (lista, resumo, alinhamento, análise por temas) and specifying the analysis scope. However, it doesn't mention potential limitations like data availability, rate limits, authentication needs, or error conditions that would be important for a tool with comprehensive analysis.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized. It starts with the core purpose, provides usage examples, details the return structure, and ends with a prerequisite note. While efficient, the question list format could be slightly more concise, and the analysis details might be better summarized rather than listed exhaustively.
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 complexity (comprehensive voting analysis) and lack of output schema, the description does a good job explaining what the tool returns. It details the multi-faceted output structure including lists, summaries, alignments, and thematic analysis. However, without annotations or output schema, it could benefit from more behavioral context about limitations or data freshness.
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 4 parameters thoroughly. The description adds minimal value beyond the schema - it only reinforces that 'idDeputado' is required and should come from 'buscar_deputados'. No additional parameter semantics are provided beyond what's in 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 the tool's purpose with specific verbs ('retorna o histórico de votos', 'com análise completa') and distinguishes it from siblings by focusing on a deputy's voting history with comprehensive analysis. It explicitly mentions the resource (deputado específico) and scope (histórico de votos), making it distinct from tools like 'ultimas_votacoes' or 'votos_votacao'.
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?
The description provides explicit guidance on when to use this tool vs alternatives. It lists specific question types the tool answers, names a prerequisite tool ('use buscar_deputados primeiro'), and implicitly distinguishes it from siblings by focusing on deputy-specific voting analysis rather than general voting data or other deputy attributes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: it returns complete fiscal documents that can generate extensive text, warns about potential overflow, and suggests mitigation strategies (using 'resumido' format or limiting items). However, it doesn't cover aspects like rate limits, authentication needs, or error handling, which keeps it from a perfect score.
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 efficiently structured in three sentences with zero waste. The first sentence states the purpose, the second provides prerequisite guidance, and the third offers important usage warnings and optimization tips. Each sentence earns its place by adding critical information for the agent.
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 complexity (10 parameters, no output schema, no annotations), the description does well by covering purpose, prerequisites, sibling differentiation, and behavioral warnings. However, it lacks details on output structure, pagination behavior, or error cases, which would be helpful for a tool with this many parameters and no output 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?
The schema description coverage is 100%, providing comprehensive documentation for all 10 parameters. The description adds minimal parameter semantics beyond the schema, only mentioning the 'formato' parameter's effect on payload size. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't significantly enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Lista') and resource ('despesas de um deputado da cota parlamentar'), making the purpose specific. It distinguishes from sibling tools by explicitly mentioning 'resumo_despesas_deputado' as an alternative for overview purposes, showing clear differentiation.
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?
The description provides explicit guidance on when to use this tool vs. alternatives: it instructs to use 'buscar_deputados' first to obtain the ID, and recommends 'resumo_despesas_deputado' for an overview instead. It also includes warnings about potential text overflow and suggests using 'formato=resumido' to mitigate this, covering both prerequisites and 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?
With no annotations provided, the description carries full burden. It discloses the parallel call behavior ('em uma única chamada paralela') which is valuable context. However, it doesn't mention performance characteristics, rate limits, authentication requirements, or what happens with invalid IDs. For a tool that aggregates multiple data types, more behavioral context would be helpful.
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 perfectly concise with two sentences that each earn their place. The first sentence defines the tool's comprehensive scope and parallel execution. The second provides clear usage guidance. No wasted words, front-loaded with the core functionality.
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 no annotations and no output schema, the description does well by specifying the comprehensive data types returned and when to use it. However, it could better address the complexity of aggregating multiple data types by mentioning potential performance implications or completeness guarantees. The guidance on when to use versus specialized siblings is particularly valuable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with the single parameter 'id' documented as 'ID do deputado'. The description doesn't add parameter-specific information beyond what the schema provides, but with only one parameter and complete schema coverage, the baseline is high. The description's context about what data the tool returns helps understand what the ID parameter will retrieve.
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 with a specific verb ('Obtém' - gets) and resource ('dados de um deputado'), listing comprehensive data types (detalhes, despesas recentes, discursos, etc.). It explicitly distinguishes from siblings by emphasizing it provides 'TODOS os dados' in 'uma única chamada paralela', contrasting with more specialized tools like detalhar_deputado, despesas_deputado, or discursos_deputado.
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?
The description provides explicit usage guidance: 'Use isso preferencialmente para responder perguntas gerais sobre um parlamentar.' This clearly indicates when to use this tool (for general questions about a parliamentarian) versus when to use more specialized sibling tools for specific aspects like expenses, speeches, or events.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes what the tool returns (aggregated totals, top 10 expenses, statistics) and its optimization for agents with context limitations. It doesn't mention rate limits, authentication needs, or error conditions, but for a read-only summary tool, the behavioral description is quite 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 efficiently structured with zero wasted sentences. It starts with the core purpose, then lists the specific return format, and concludes with clear usage guidelines. Every sentence adds essential 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 summary tool with no annotations and no output schema, the description provides strong contextual completeness. It explains what data is returned, when to use it versus alternatives, and the optimization rationale. The main gap is the lack of output format details, but given this is a summary tool with clear behavioral description, it's mostly 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?
The input schema has 100% description coverage, so the schema already documents all parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema. This meets the baseline expectation when schema coverage is complete.
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: it returns an OPTIMIZED SUMMARY of a deputy's expenses, specifically aggregating totals by expense type, showing top 10 largest individual expenses, and providing statistics. It explicitly distinguishes itself from the sibling tool 'despesas_deputado' by emphasizing it's for a high-level overview rather than detailed documents.
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?
The description provides explicit guidance on when to use this tool versus alternatives. It states: 'Use this tool preferably instead of 'despesas_deputado' when you need an overview' and 'Use 'despesas_deputado' only if you need to see ALL detailed documents.' This clearly defines the context and alternative tool for different needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behavioral traits: it returns optimized summaries instead of full texts (addressing data size constraints), specifies the structured output components (statistics, keywords, summarized speeches, theme grouping), and mentions automatic theme detection. It doesn't cover potential limitations like rate limits or error conditions, but provides substantial operational 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 efficiently structured: it opens with the core purpose, immediately lists the output components in bullet points for clarity, and concludes with explicit usage guidelines. Every sentence adds value—no redundant or vague statements. The bullet points make the output format easily scannable.
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 complexity (summarization with multiple output components) and lack of annotations/output schema, the description does an excellent job of explaining what the tool returns. It details the four output components clearly. The only minor gap is the absence of explicit error handling or performance characteristics, but for a read-only summary tool, the description provides sufficient context 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?
The input schema has 100% description coverage, so parameters are well-documented in the schema itself. The tool description doesn't add any parameter-specific information beyond what's in the schema descriptions. This meets the baseline of 3 when schema coverage is high, as the description doesn't need to compensate but also doesn't enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Retorna um RESUMO OTIMIZADO dos discursos de um deputado' (returns an optimized summary of a deputy's speeches). It specifies the output format (statistics, keywords, top 10 summarized speeches, theme grouping) and explicitly distinguishes it from the sibling tool 'discursos_deputado' by contrasting summary vs. full text retrieval.
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?
The description provides explicit usage guidelines: 'Use esta ferramenta preferencialmente ao invés de 'discursos_deputado' quando precisar de visão geral. Use 'discursos_deputado' apenas se precisar ler textos completos de discursos específicos.' It clearly states when to use this tool (for overview/context-limited agents) versus the alternative (for full text of specific speeches), including the rationale (avoiding 500KB+ data).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well: it explains the tool optimizes for context-limited agents, filters out repetitive entries, limits key events to maximum 20, and focuses on important milestones. It doesn't mention rate limits, authentication needs, or error conditions, but provides substantial behavioral context for a read-only summary 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 efficiently structured: first sentence states the core purpose, followed by bullet points detailing what's included, then explicit usage guidelines. Every sentence earns its place with no redundancy, and information is front-loaded appropriately.
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 summary tool with no annotations and no output schema, the description does well: it explains what the tool returns (statistics, key events, committees, timeline), when to use it vs alternatives, and its optimization for context-limited agents. It doesn't describe the exact output format or error handling, but provides substantial context 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 description coverage is 100%, so the schema already documents all three parameters (id, dataInicio, dataFim) with their purposes and formats. The description doesn't add any parameter-specific information beyond what's in the schema, maintaining the baseline score of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns an 'optimized summary of the legislative history of a proposition' and specifies what it includes: general statistics, key events (max 20), committees with status/timing, and a summarized timeline. It explicitly distinguishes from sibling 'tramitacoes_proposicao' by emphasizing it's for overview vs. detailed movements.
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?
The description provides explicit guidance: 'Use this tool preferably instead of 'tramitacoes_proposicao' when you need an overview' and 'Use 'tramitacoes_proposicao' only if you need to see ALL detailed dispatches and movements of a specific period.' This clearly defines when to use this tool versus its alternative.
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 describes the tool's output (listing event types with examples) but doesn't disclose behavioral traits like response format, pagination, or error handling. The description is accurate but lacks operational details needed for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste: the first states purpose with examples, the second provides usage guidelines. Every word adds value, and it's front-loaded with the core functionality.
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 (0 parameters, no output schema, no annotations), the description is nearly complete. It explains what the tool does and how to use it with sibling tools. A minor gap exists in not specifying the return format (e.g., list of strings/objects), but this is acceptable for such a straightforward 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 tool has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing instead on the tool's purpose and usage. A baseline of 4 is applied since no parameters exist.
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 ('tipos de eventos realizados na Câmara'), with specific examples of event types included. It distinguishes from sibling tools like 'buscar_eventos' by focusing on event categories rather than individual events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool: 'Use para filtrar eventos específicos em buscar_eventos ou entender a agenda legislativa.' It provides clear alternatives (use with 'buscar_eventos') and context (understanding legislative agenda), distinguishing it from other event-related 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 implies a read-only operation by listing types, but doesn't disclose behavioral traits like rate limits, authentication needs, or response format. The example types add some context, but key behavioral details are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste: first states purpose with examples, second provides explicit usage guidance. It's front-loaded with the core function and efficiently structured for quick understanding.
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 zero-parameter, read-only listing tool with no annotations or output schema, the description is reasonably complete. It covers purpose, provides examples, and gives usage context. However, it lacks details on output format or potential limitations, leaving some gaps in full contextual understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage (empty schema). The description doesn't need to explain parameters, and it appropriately focuses on the tool's purpose and usage. Baseline is 4 for zero-parameter tools when the description is adequate.
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 with a specific verb ('Lista') and resource ('todos os tipos de proposições legislativas'), including key attributes ('siglas e descrições'). It distinguishes from siblings like 'buscar_proposicoes' by focusing on metadata rather than actual propositions.
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?
Explicit guidance is provided: 'Use para descobrir a sigla correta ao buscar proposições com buscar_proposicoes.' This directly states when to use this tool (to find correct acronyms) and references the alternative tool ('buscar_proposicoes') for the related action, offering clear context for tool selection.
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 describes what the tool returns (UF names and acronyms) and its purpose, but lacks details on behavioral traits like rate limits, error handling, or response format. It's adequate but not rich in behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste: the first states the purpose, the second provides usage guidelines. It's front-loaded with the core function and efficiently structured for clarity.
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 low complexity (0 parameters, no output schema, no annotations), the description is complete enough for its purpose. It explains what the tool does and when to use it, though it could add more on output format or limitations to reach a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description correctly implies no inputs are required, aligning with the schema. Baseline is 4 for 0 parameters, as it doesn't need to compensate for any 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 the tool's purpose with specific verbs ('Lista todas as Unidades Federativas') and resources ('estados do Brasil'), and distinguishes it from siblings by specifying it provides UF data for validation or filtering deputies, unlike other tools focused on deputies, parties, or proposals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool: 'Use para validar siglas de UF ou obter a lista completa de estados ao filtrar deputados por região em buscar_deputados.' This provides clear alternatives (e.g., use for validation or filtering) and context for sibling tool integration.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively communicates this is a read-only lookup tool for reference data (status codes/IDs), implies no destructive operations, and suggests it returns a list of status options. However, it doesn't explicitly mention whether the list is complete, static, or paginated, leaving some behavioral aspects unspecified.
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 efficiently structured in three sentences: purpose statement, usage guidance with specific alternative tool reference, and concrete examples. Every sentence adds value without redundancy, making it appropriately sized and front-loaded with the most critical information first.
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 zero-parameter lookup tool with no annotations and no output schema, the description provides excellent context about what the tool returns (status codes/IDs for filtering) and how to use the results. The only minor gap is the lack of explicit information about the return format (e.g., whether it's a simple list or structured objects), but the examples strongly imply usable identifiers.
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 tool has 0 parameters with 100% schema description coverage, so the baseline would be 4 even without parameter information in the description. The description correctly indicates no parameters are needed ('lista as situações' implies a simple list operation), which aligns perfectly with the empty input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Lista as situações possíveis de proposições legislativas' (lists possible legislative proposition statuses). It specifies the resource (proposition statuses) and verb (list), and distinguishes from siblings like 'buscar_proposicoes' (search propositions) by focusing on metadata rather than actual propositions.
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?
The description explicitly states when to use this tool: 'Use esta tool para obter o ID ou sigla de uma situação quando precisar filtrar proposições por status em buscar_proposicoes.' It provides a clear alternative (buscar_proposicoes) and gives concrete examples of use cases (finding propositions in progress, listing archived bills, searching approved constitutional amendments).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It implies this is a read-only operation (listing types) and adds context about the organizational structure of the Câmara. However, it doesn't specify behavioral traits like rate limits, authentication needs, or response format, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with two sentences that efficiently convey purpose and usage. Every sentence adds value without redundancy, making it concise and well-structured.
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 complexity (simple list operation with 0 parameters) and lack of annotations/output schema, the description is mostly complete. It covers purpose and usage well but could improve by specifying response format or behavioral constraints, though this is less critical for a read-only 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 tool has 0 parameters with 100% schema description coverage. The description doesn't need to add parameter details, but it compensates by explaining the purpose and usage context. A baseline of 4 is appropriate for a parameterless tool with high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Lista') and resource ('tipos de órgãos da Câmara dos Deputados'), providing specific examples like comissões permanentes, CPIs, Mesa Diretora, etc. It effectively distinguishes this tool from sibling tools like 'buscar_orgaos' by focusing on types rather than individual organs.
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?
The description explicitly states when to use this tool: 'Use para filtrar órgãos por tipo em buscar_orgaos ou entender a estrutura organizacional da Câmara.' It provides clear alternatives (e.g., use with 'buscar_orgaos') and context for organizational understanding.
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:

[![AgenteCidadaoMCP MCP server](https://glama.ai/mcp/servers/gvc2000/AgenteCidadaoMCP/badges/card.svg)](https://glama.ai/mcp/servers/gvc2000/AgenteCidadaoMCP)

Score Badge

Copy to your README.md:

[![AgenteCidadaoMCP MCP server](https://glama.ai/mcp/servers/gvc2000/AgenteCidadaoMCP/badges/score.svg)](https://glama.ai/mcp/servers/gvc2000/AgenteCidadaoMCP)

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/gvc2000/AgenteCidadaoMCP'

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