Senado BR MCP

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint and openWorldHint. Description adds default date (today) and return structure details, which provides additional behavioral context beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is concise, front-loads purpose, then details output and alternatives. Every sentence adds value with no waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (2 optional params, output schema present), the description provides complete context including default, return shape, and sibling tool references.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with descriptions for both parameters. Description adds meaning by explaining the default for 'data' and the filtering use of 'siglaComissao', enhancing beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description explicitly states it obtains the agenda of meetings of all commissions on a date with optional filter. It also distinguishes itself from related tools by naming alternatives for history and details.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says when to use this tool (for date-based agenda) and when to use alternatives (senado_reunioes_comissao for history, senado_reuniao_comissao for details). Provides clear guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=true and openWorldHint=true, and the description aligns as a read operation. It discloses the return structure in detail, increasing transparency beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Single paragraph, front-loaded with purpose, no wasted words. Concisely covers purpose, parameters, returns, and sibling references.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema (as per context), the description provides a clear breakdown of the return structure and references sibling tools. Complexity is low and the description is fully adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the description adds contextual meaning: explains each parameter (data, escopo, dataFim) with defaults and constraints (e.g., dataFim only for escopo=cn), and defines the escopo enum values.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it obtains the agenda of plenary sessions, specifies the scope (Senado or Congresso Nacional), and distinguishes from siblings like 'senado_resultado_plenario' and 'senado_encontro_plenario' for different purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly explains when to use this tool vs alternatives: for results use 'senado_resultado_plenario', for session details use 'senado_encontro_plenario'. Also provides parameter guidance: 'Use escopo dia/mes/cn; sem data assume hoje'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations provide readOnlyHint and openWorldHint. The description adds behavioral context: ordering by production, return structure, partial search without accents, and a default/max limit. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single paragraph that efficiently provides purpose, return structure, filters, and cross-tool usage. Every sentence earns its place with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema (context signal), the description adequately covers purpose, parameters, return fields, and related tools. It provides sufficient information for an agent to use the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds value by explaining that nome uses partial search without accents and confirming the default and maximum for limite, exceeding the schema's descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the tool lists parliamentary authors of ongoing processes, ordered by production, with specific fields returned. It distinguishes from sibling tools by mentioning the codigo can be used in senado_obter_senador or senado_search_processos.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains optional filters (uf, nome, limite) with details like partial search without accents and default/max limits. It implies usage for finding authors of pending processes, but does not explicitly exclude scenarios or compare to all alternatives, though it does mention related tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the description adds value by specifying the requirement of at least one parameter and the error behavior. It does not contradict annotations and provides additional context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, with three sentences: first states purpose and return structure, second gives usage constraint and error condition, third provides cross-references. No wasted words, front-loaded with essential info.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (4 optional parameters, output schema present), the description covers purpose, return format, usage constraints, and links to related tools. No missing information; it's fully self-contained.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, with each parameter described. The description adds meaning by stating the requirement for at least one parameter, listing examples of 'tipo' values, and explaining the return format. This goes beyond the schema's individual descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it searches federal legal norms by type, number, year, or date, and specifies the return structure. It distinguishes itself from sibling tools like senado_obter_legislacao and senado_tabelas_referencia, which are referenced for detail and valid types.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states that at least one parameter is required (or an error is returned), and directs users to use the returned 'codigo' in senado_obter_legislacao for details and to consult senado_tabelas_referencia for valid types. This provides clear when-to-use and when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint and openWorldHint, confirming a read operation with potentially incomplete results. The description adds value by detailing the return structure (count, total, materias[] with specific fields), pagination behavior (limite default 100, max 500, truncation warning), and the role of 'codigo', enhancing transparency beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is moderately sized but front-loaded with the core action. It efficiently packs criteria, return format, and cross-reference without redundancy, though slightly longer than minimal due to detailed return field listing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's 7 parameters (0 required but needing at least one), full schema coverage, and available output schema, the description covers return value structure, usage of 'codigo', limit behavior, and conditions for truncation. It is complete for the agent to use correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema coverage, the description still adds meaning by grouping parameters (tipo, número, ano, etc.), mentioning examples like PEC, PL, PLP, MPV, and emphasizing the need for at least one criterion. This clarifies usage beyond the schema's individual descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool searches legislative matters (matérias) by various criteria, with specific examples of types. It distinguishes from siblings by mentioning the use of 'codigo' in 'senado_obter_materia' for further details, making the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description advises that at least one criterion must be provided, and outlines default and maximum limits. It also hints at when to use a different tool ('senado_obter_materia') for detailed information, providing useful context for selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond annotations (readOnlyHint, openWorldHint), the description adds details about the return structure, aggregation options, truncation behavior (limite cap with aviso), and ordering. It also advises getting codSenador from another tool, enhancing behavioral transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise yet comprehensive, front-loading the purpose and return structure, then covering modes, filters, and a cross-reference. Every sentence adds unique information with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 8 parameters and an output schema, the description covers the essential information: modes, filters, truncation, and reference to another tool. It is complete enough for an agent to use effectively, though output schema details are not duplicated.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Parameters have 100% schema description coverage, so baseline is 3. The description adds value by explaining the modes, default behavior, and that filtering is partial. It also describes the return structure difference between modes, which the schema does not convey.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it retrieves CEAPS expenses for senators in a year, specifying the resource (despesas CEAPS) and verb (gets/returns). It distinguishes from siblings by focusing on this specific expense type, which is not covered by other tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use the tool (to query CEAPS expenses) and mentions filters and modes. However, it does not explicitly state when not to use it or provide alternatives among sibling tools, though the context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond annotations (readOnlyHint, openWorldHint), the description details return format, limits (default 100, max 500), behavior for empty sections (count 0, empty itens), and error on invalid type/section combinations. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single well-structured paragraph, front-loaded with the main purpose, then systematically explaining parameters, return format, and usage. Every sentence adds value with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With annotations indicating read-only and open-world behavior, the description covers return structure, limits, and edge cases. No explicit output schema provided, but the description compensates well, making it complete enough for an agent to use effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds significant meaning: explains enum values for tipo and secao, their constraints (aditivos only for contratos, acionamentos only for atas), and default/max for limite. This enriches the parameter understanding beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Detalha uma seção específica de uma contratação.' It explains the two key parameters (tipo and secao) with their enum values and meanings, and relates to sibling tools by mentioning how to obtain the id beforehand.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly instructs to obtain the id via senado_contratos or senado_contratacoes_lista first, and warns about invalid combinations returning error. This provides clear context for when to use this tool and prerequisite steps, though it doesn't give extensive when-not-to-use scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint and openWorldHint. The description adds transparency about response structure per tipo, truncation behavior with 'aviso', and that 'menores_aprendizes' come as raw API records. No contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single paragraph but well-structured, front-loading the main action. It is informative but could be slightly more concise; however, every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema (implied by the described return structure), the description completes the picture by explaining what each tipo returns and the truncation warning. It covers all aspects needed for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so parameters are defined. The description adds semantics beyond schema: explains that filter is applied on Worker across all fields, clarifies default and max limit, and describes the response format for each tipo, which is not in schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it lists three specific types of records (atas, notas, menores aprendizes) with optional text filter. It distinguishes itself from sibling 'senado_contratacao_detalhe' by mentioning deepening into a specific item. The verb 'Lista' and resource 'contratacoes' are specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly tells when to use the sibling tool for deepening ('Para aprofundar uma ata/empenho, use o id em senado_contratacao_detalhe'). It implies usage for listing, but no explicit when-not-to-use. Overall clear context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=true, indicating safe read operation. The description adds value by specifying the limit parameter (default 50, max 500) and the aviso field for truncation. This provides practical behavioral context beyond what annotations convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences, each efficient and front-loaded. First sentence states purpose and filters, second specifies return structure, third covers behavior (limit/truncation) and links to related tool. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema (return structure described), 100% parameter coverage, and annotations, the description is complete. It explains functionality, filtering, return format, limits, truncation warning, and provides a clear next step (senado_contratacao_detalhe). Meets all needs for a search tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with descriptions for each parameter. The description lists the filter criteria and mentions they are applied upstream, but does not significantly add new information beyond the schema. It reinforces the usage but doesn't provide deeper semantics (e.g., format, restrictions). Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool searches for Senate administrative contracts with specific verb 'Busca' and resource 'contratos administrativos do Senado'. It lists multiple filter criteria (fornecedor, CNPJ, ano, numero, objeto, mão de obra) and distinguishes itself from sibling tools by referencing 'senado_contratacao_detalhe' for detailed follow-up.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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 (to search contracts by various criteria) and when to use another tool (senado_contratacao_detalhe for details on a specific contract). It also explains the limit and truncation behavior. However, it does not explicitly mention when not to use this tool or contrast with other sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide readOnlyHint and openWorldHint. Description adds return structure and parameter format. It does not mention pagination limits or performance considerations, but it is adequate given annotations and 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with purpose and parameter info. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Output schema exists, so return values are covered. Description includes return shape and sibling context. Tool is straightforward and description is complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. Description adds format YYYYMMDD but this is already in schema. It does not add significant new meaning beyond what schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists all speeches in plenary within a date range, with specific parameters and format. It distinguishes from siblings by mentioning alternatives for specific senator speeches and 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use (list all speeches in date range) and when to use alternatives (senado_discursos_senador for specific senator, senado_discurso_texto for full text).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=true and openWorldHint=true. The description adds that the operation is a list (read) and details the return structure, including that 'apartes' have a similar structure. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single paragraph but front-loads the main purpose, then covers parameters, output, and cross-references to other tools. Every sentence adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is comprehensive given the tool's complexity: it covers all parameters, output structure, and related tools. It lacks explicit mention of pagination or maximum date range, but the openWorldHint and schema patterns mitigate this.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% coverage, and the description adds significant value: it explains the 'tipo' parameter's default and options, the purpose of date and 'casa' filters, and provides the exact output fields. This goes beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it lists 'pronunciamentos' of a senator, filterable by period and house, and distinguishes between 'discursos' and 'apartes'. It references related tools for getting the senator code and full text, differentiating from siblings like senado_discursos_plenario and senado_discurso_texto.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use 'discursos' vs 'apartes' via the 'tipo' parameter, and directs users to obtain the 'codigoSenador' from 'senado_listar_senadores' and to get full text from 'senado_discurso_texto'. It does not explicitly state when not to use this tool, but the context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide readOnlyHint=true and openWorldHint=true. Description adds meaningful context about return format (object with codigoPronunciamento and texto), which is beyond schema. No contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tightly-focused sentences with no extraneous information. Every sentence serves a purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple tool (1 required parameter, output schema present), description covers input source, output structure, and purpose completely.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with description 'Código do pronunciamento'. Description adds value by explaining how to obtain the parameter from other tools, going beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states verb 'Obtém' (retrieves) and resource 'texto integral de um pronunciamento/discurso específico'. It distinguishes from siblings by specifying that the parameter comes from senado_discursos_senador or senado_discursos_plenario.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly instructs to first obtain codigoPronunciamento from sibling tools, providing clear when-to-use guidance and avoiding misuse.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=true. Description adds that results are ordered by quantidade descending and that codigoParlamentar only works with tipo=autoria, providing behavioral details beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Single paragraph, front-loaded with main action and parameter details, concise with no redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given output schema exists and tool has 3 parameters with clear semantics, the description covers purpose, parameters, output structure, and usage tip, making it comprehensively complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers all parameters with descriptions. Description adds context on enum values, filter constraints, and output ordering, providing additional meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it provides statistics of distribution of matters in a committee, specifies parameters (siglaComissao, tipo, codigoParlamentar), and distinguishes itself by referencing senado_listar_comissoes for getting the committee acronym.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Description indicates it is useful for measuring legislative workload and tells users to obtain siglaComissao from a sibling tool, though it does not explicitly mention when not to use this tool or provide direct alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds behavioral details beyond annotations: it explains ordering (by concentration or difference), default values, and output structure. Annotations indicate readOnlyHint=true and openWorldHint=true, which the description supports. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single paragraph of ~5 sentences, efficiently front-loading the main purpose and then detailing each mode's criteria. It avoids unnecessary words and ends with a clear sibling reference.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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, two modes, no required params, output schema present), the description fully covers behavior, defaults, and return format. It also guides the agent to a sibling tool for detailed consultation, ensuring completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage for all parameters. The description adds context about defaults (e.g., 85% for percentualMinimo, 15 for margemPolarizacao) and ordering logic, enhancing the schema's meaning without redundancy.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool analyzes e-Cidadania public consultations by citizen agreement degree, with two modes ('consenso' and 'polarizada'). It distinguishes itself from the sibling tool 'senado_ecidadania_obter_consulta' by explicitly directing users there for detailed consultation info.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use each mode: 'consenso' for high vote concentration, 'polarizada' for balanced voting. It also mentions the sibling tool for details. However, it doesn't explicitly state when not to use this tool or provide alternative contexts beyond the sibling.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Adds context beyond annotations: describes return format, default limit, filtering. Annotations already provide readOnly and openWorld hints, so description complements well.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Single paragraph, front-loaded with purpose, then return and parameters, then sibling guidance. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers purpose, return structure, parameters, and sibling differentiation. Output schema exists, so no need to detail returns further.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with descriptions, but description adds meaning: highlights limite default, status filter, and return structure (count, consultas).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the tool lists public consultations from e-Cidadania where citizens vote on matters. Distinguishes from siblings by mentioning detail and analysis tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says when to use this tool (list consultations) and when to use alternatives for details or analysis.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and openWorldHint, so the description adds value by detailing the return structure (count, eventos with specific fields) and default limit (20) with max (100). No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences cover purpose, return structure with filters, and alternative tool. Each sentence is packed with relevant information without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema existence and rich parameter schema, the description adequately covers tool behavior. It could mention pagination or authentication, but annotations offset some gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All parameters are described in schema, but the description enriches them with usage context (e.g., ordering by comments for ranking, filtering by status/commission). It provides practical guidance beyond schema definitions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it lists interactive events (audiências públicas, sabatinas, lives) from e-Cidadania, and distinguishes itself from the sibling tool for event details (senado_ecidadania_obter_evento) and other list tools (consultas, ideias).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly recommends using the sibling tool for full event details, and gives ordering advice for ranking. It does not explicitly state when not to use it, but the context is clear enough.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

A descrição vai além das anotações (readOnlyHint, openWorldHint) ao detalhar comportamento de paginação (padrão 20 por página, máximo 100), ordenação por apoios/data/comentários, e estrutura de retorno. Não contradiz as anotações, que indicam operação de leitura segura.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A descrição é concisa em duas frases principais, com informação essencial na primeira linha. Não há palavras desnecessárias; cada frase agrega valor funcional.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Considerando a complexidade (5 parâmetros, nenhum obrigatório, esquema completo, esquema de saída existente), a descrição cobre todos os aspectos: propósito, parâmetros, paginação, ordenação, filtros, e referência ao tool irmão. Não faltam informações relevantes.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

A cobertura do esquema é 100% e a descrição adiciona significado além das descrições dos parâmetros: explica como usar ordenarPor, ordem e status para ranking, e menciona o limite padrão. Exemplos práticos aumentam o valor além do esquema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

A descrição especifica claramente que o ferramenta lista ideias legislativas do portal e-Cidadania, incluindo o formato de retorno e campos, e diferencia-se dos irmãos ao mencionar que para detalhes completos deve-se usar senado_ecidadania_obter_ideia. O verbo 'Lista' e o recurso 'ideias' são específicos.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

A descrição fornece orientações explícitas: 'Para um ranking das mais apoiadas, ordene por apoios' com exemplo de parâmetros, e também indica quando não usar (para detalhes completos, use outro tool). Exclui alternativas e contextos de uso.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint and openWorldHint. The description adds value by detailing the return object fields and noting which fields may be null (comissao and dates). This disclosure beyond annotations helps set expectations about possible null values.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences, front-loaded with the main purpose, then return details, then source guidance. Every sentence provides necessary information without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has one parameter, good annotations, and an existing output schema, the description is complete. It covers what the tool does, what it returns, and how to get input. No gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and the description adds context beyond the schema by explaining how to obtain the required 'id'. It tells users to get it from two specific sibling tools, which adds semantic meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves details of a specific e-Cidadania public consultation. It uses a specific verb 'Obtém' and identifies the resource as 'detalhe de uma consulta pública específica do e-Cidadania'. It distinguishes from sibling tools by instructing to obtain the id from list/analysis tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly tells users to obtain the id from senado_ecidadania_listar_consultas or senado_ecidadania_consultas_analise before using this tool. This provides clear guidance on prerequisites. It does not explicitly state when not to use, but the scope is well-defined by the 'id' requirement.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint=true and openWorldHint=true. The description goes beyond by listing all return fields (id, titulo, descricao, etc.) and noting optional videoUrl, giving full behavioral expectations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise: one sentence for purpose, followed by a structured list of return fields, then a usage note. No wasted words, information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With only one parameter, clear annotations, and a comprehensive description of return fields (acting as an output schema), the agent has all necessary context to use the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers 'id' with description 'ID do evento'. The description adds value by explaining where to get the id, i.e., from listar_eventos, aiding correct invocation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Obtém' and resource 'detalhe de um evento interativo do e-Cidadania', specifying exactly what the tool does. It distinguishes itself from sibling tools like listar_eventos by being the detail retriever.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly instructs to obtain the id via senado_ecidadania_listar_eventos, providing a clear prerequisite. Does not discuss when not to use or alternatives, but context is adequate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate readOnlyHint and openWorldHint. Description adds that 'descricao' is truncated at ~2000 characters and explains 'plConvertido'. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences: first states purpose and return fields, second gives prerequisite. No extraneous information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With full schema coverage, output schema, and clear description including truncation notice and reference to list tool, the tool is completely specified for its simple retrieval purpose.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers the only parameter fully (100%). Description does not add new semantic meaning for the parameter itself, but provides usage context. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it retrieves details of a legislative idea from e-Cidadania, lists returned fields, and distinguishes from sibling 'senado_ecidadania_listar_ideias'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly directs to obtain the id via the list tool, providing a clear prerequisite. Does not mention when not to use, but the single-parameter tool is straightforward.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds behavioral details beyond annotations: it specifies the output format (up to 10 suggestions with fields), filtering criteria with defaults, and ordering by participation. Annotations already declare readOnlyHint and openWorldHint, which are consistent with a read/suggestion operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise paragraph with all essential information front-loaded: purpose, output structure, filtering options, and sibling tool guidance. Every sentence adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one optional nested parameter), annotations, and implied output schema from the description, the description is fully complete. It covers input parameters, expected output, and follow-up actions.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema coverage is 100% with descriptions, so the schema already documents parameters. The description adds meaningful context by explaining the criteria in natural language (e.g., 'evita temas com ~50/50' for evitarPolarizacao) and linking them to the output structure.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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 temas para uma enquete pública mensal (seleção de pauta)' with specific verb and resource. It differentiates from sibling tools by focusing on suggestion rather than listing or retrieval, and explicitly names alternatives for follow-up.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for using this tool to get top engaging topics and explicitly directs the agent to use 'senado_ecidadania_obter_consulta' or 'senado_ecidadania_obter_ideia' for investigating suggestions. However, it does not discuss when to avoid this tool or compare with other analysis tools like 'senado_ecidadania_consultas_analise'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide readOnlyHint=true and openWorldHint=true; the description adds valuable behavioral context such as requiring at least one of nome/cnpj, partial search behavior, and limit parameter with maximum of 100. It does not contradict annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and concise: it first states the purpose and parameters, then the return format, then usage constraints, and finally links to siblings. Every sentence adds value, and it is appropriately front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (search with multiple parameters, output format, constraints) and the presence of output schema (described textually) and annotations, the description is complete: it covers search behavior, required inputs, return fields, limits, and connection to other tools. No significant gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and the description adds meaning beyond schema by clarifying that at least one of nome/cnpj must be provided (though not required in schema), describing partial search for CNPJ/CPF, and explaining the reason for the limit ('a base completa é grande').

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool searches for companies that contract with the Senate by name or CNPJ/CPF, uses a specific verb 'Busca' and resource 'empresas que contratam com o Senado', and distinguishes from siblings by directing to use `senado_contratos` or `senado_contratacao_detalhe` for detailed information.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states that providing `nome` or `cnpj` is required (though schema marks them optional), warns that the full base is large, and mentions the `limite` parameter with defaults and max. It does not list explicit alternatives or when not to use, but it effectively guides usage with constraints and links to sibling tools for further detail.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate read-only and open-world (return varies). Description adds: result can be empty for a section, error if codigo missing, and that encontro is a raw object. No contradictions with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Single paragraph, front-loaded with purpose. Every sentence provides useful information (structure, sections, edge cases, prerequisite). Could be slightly more concise, but structure is clear.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given moderate complexity (4 variants) and no explicit output schema, the description adequately describes return format and behavior. It also explains error and empty results. Coordination with sibling tools is covered.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds meaning: explains that codigo should be from other tools, and details what each secao value returns (e.g., tipo, data, situação for detalhes). This goes beyond schema definitions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns details of a legislative plenary session (specific verb and resource). It distinguishes from siblings by mentioning sources for obtaining the required code (senado_agenda_plenario, senado_resultado_plenario) and by explaining the different sections.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains prerequisite: obtain codigo from specific sibling tools. It also describes each section's purpose, guiding selection. However, it does not explicitly state when not to use this tool compared to all alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint=true and openWorldHint=true. Description adds behavioral details: return structure (tipo, modo, ano, totalLinhas, agregado[] with chave/valores, limit with aviso to truncation), which is not present in annotations. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is only a few sentences, front-loaded with purpose, then covers return structure, usage guidance, and differentiation from sibling. Every sentence provides value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 4 parameters, various modes, and an output schema (described in text), the description fully covers: purpose, data ranges, return schema, parameter usage, filtering advice, and sibling distinction. No gaps evident given the complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds context beyond schema descriptions: explains valid combinations of tipo and modo (e.g., despesas with por-acao/por-grupo/por-fonte, receitas with por-origem) and suggests using ano filter to reduce volume. This enriches parameter understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it handles Senate budget execution (expenses since 2013, revenues since 2012) and distinguishes from the sibling tool 'senado_orcamento_parlamentar' which deals with parliamentary amendments. The verb 'execução orçamentária' and resource 'Senado' are specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit guidance: use 'detalhe' only after filtering with 'ano' to reduce volume; explains which modes apply to despesas vs receitas; and explicitly warns not to confuse with the sibling tool. Also suggests filtering by year before requesting detail.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint and openWorldHint. The description adds behavioral context: data from 2013 onward, return structure with totals and per-item fields, and that nome allows partial search. It does not contradict annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with purpose and required params, then output details and optional filters. No redundancy, every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema and annotations, the description fully explains what the tool returns, the meaning of key fields, and provides a cross-reference to a sibling tool. No gaps for the agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds meaning: explains the return object structure, that nome is a partial search, limite has a default and max, and the date range. This goes beyond the schema's simple descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('retorna') and resource ('horas extras pagas a servidores do Senado'), specifies the date range, and distinguishes from sibling tools by focusing on overtime payments and referencing the alternative tool for full remuneration.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states required parameters (ano, mes), optional filters (nome, limite with defaults and max), and directs users to a sibling tool ('senado_remuneracoes_servidores') for alternative use cases.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations declare readOnlyHint: true and openWorldHint: true. The description adds significant behavioral context: return format with count, total, and licitacoes; raw API data; limit defaults to 50, max 500. No contradiction with annotations; the description enriches the transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with three sentences, front-loaded with the core purpose, then format, constraints, and sibling tool reference. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema (not shown but indicated), the description adequately covers the tool's purpose, parameters, output structure, constraints, and sibling guidance. It fully addresses the complexity of a search tool with multiple optional parameters.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, but the description adds value beyond schema: it provides an example format for 'numero' (19/2018), clarifies the relationship between parameters and the requirement of at least one, and explains the default and max for 'limite'. This extra context earns a score above the baseline of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Busca' (search) and the resource 'licitações do Senado' (Senate bidding processes). It also distinguishes itself from siblings by specifying search by exact number or object text and explicitly mentions the sibling tool 'senado_contratos' for contract details.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit usage conditions: at least one of 'numero' or 'objeto' is required, otherwise an error is returned. It also guides the user to 'senado_contratos' if they need the resulting contract, offering a clear alternative.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint=true and openWorldHint=true. The description adds valuable behavioral context: it explains the return structure (`{ count, liderancas }`) and the fields within each item (`tipo`, `descricao`, `unidadeLideranca`, `parlamentar`). This goes beyond annotations and helps the agent understand what to expect.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise: two sentences front-loading the purpose and then covering filters and an alternative. Every sentence adds value, with no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 4 optional parameters, a clear output schema, and good annotations, the description provides sufficient context: what the tool returns, how to filter, and a pointer to a related tool. No gaps remain for effective use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. However, the description adds clarity by explaining the meaning of the `casa` parameter (SF/CN) and `vigente` (S/N), and mentions that filters can be combined. It also clarifies that without filters all data is returned, which is not fully explicit in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description starts with a clear verb 'Lista' (lists) and specific resource 'lideranças do Senado e do Congresso Nacional', immediately conveying what the tool does. It distinguishes itself from the sibling `senado_listar_blocos` by mentioning that for bloc composition another tool should be used.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly lists the available filters (`casa`, `codigoParlamentar`, `vigente`, `siglaTipoLideranca`) and states that without filters it returns all leaderships. It also points to an alternative tool for blocos. However, it does not explicitly state when not to use this tool or provide exclusions for specific use cases.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate read-only and open-world; description adds specific return structure (count, blocos with fields), which is helpful but not necessary for behavioral transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with purpose and return, followed by usage guidance; no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no parameters and presence of output schema, description fully covers what the tool does, returns, and how to use it with siblings.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, so description has no need to explain them; baseline score 4 for zero parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it lists all parliamentary blocs and their member parties, specifies return format, and distinguishes from sibling tools like senado_obter_bloco and senado_liderancas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says to use this tool to find the code of a bloco then use senado_obter_bloco for details, and directs to senado_liderancas for leadership info.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint=true. The description adds that the endpoint only returns active commissions, so ativa=false gives empty list. Provides useful behavioral context beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the main purpose, no filler. Every sentence adds meaningful information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 2 parameters, output described in detail, and sibling tools referenced, the description is fully complete. It covers return structure, edge cases, and usage context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds value by explaining the effect of ativa=false and listing the enum values for tipo, which is already in schema but clarifies their meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it lists active commissions with filters, and specifies the returned fields (codigo, sigla, etc.). It distinguishes itself from siblings by noting it is used to discover sigla for other tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states to use this tool to find sigla for senado_obter_comissao and senado_reunioes_comissao, and explains that ativa=false yields empty list. It does not explicitly state when not to use, but the context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description confirms readOnlyHint and openWorldHint by stating it's a listing operation. It discloses behavioral details: default `emExercicio=true`, partial matching ignoring accents/case, and local filtering for uf/partido. No contradictions with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is clear and front-loaded with the main purpose. While somewhat lengthy (multiple sentences), each sentence adds value and there is no redundancy. Could be slightly more concise, but highly effective.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists, the description sufficiently explains the return format (`{ count, senadores }` with fields like `codigo`, `nome`, `partido`, etc.) and links to related tools. Covers all necessary context for an agent to use correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and the description adds significant meaning: explains that `nome` is for partial match to retrieve `codigo`, clarifies defaults for `emExercicio`, and states that `uf`/`partido` filter locally. Also describes output structure, which goes beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists senators, with two modes (current or legislature) and optional filters. It distinguishes from sibling tools like 'senado_senadores_afastados' and 'senado_obter_senador' by mentioning when to use each.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit guidance on filter usage: use `nome` for partial match to get `codigo`, and use `codigo` in other tools. Mentions alternative tool for non-exercising senators. However, the claim that `uf`/`partido` filter locally is not fully explained (e.g., whether it's client-side or server-side).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses the return format and fields, consistent with the readOnlyHint annotation. It adds context beyond annotations by specifying exact output structure and parameter effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with purpose, no redundant information, and efficiently conveys all necessary details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the single parameter, full schema coverage, existing output schema, and clear annotations, the description covers purpose, usage, output structure, and alternative tool, making it fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds meaning by explaining the values (senado vs. congresso) and their implications, going beyond the enum definition.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists members of the Mesa Diretora for either the Senate or Congress, using specific verbs and resources, and distinguishes it from the sibling tool senado_liderancas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly tells when to use this tool (to list board members) and when not (for party leadership, use senado_liderancas), and explains the parameter choice between senado and congresso.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate readOnlyHint=true and openWorldHint=true, which are consistent with the description. The description adds significant behavioral detail beyond annotations: it explains the two modes (resumo and texto), the structure of the response (id, tipo, sessao, data, totalBlocos, blocos), and constraints like max 20 blocks per call in texto mode and pagination using sequenciaInicio/sequenciaFim. This provides a clear understanding of the tool's behavior without contradicting annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single paragraph that efficiently packs a lot of information. It starts with the core purpose and then details return structure, modes, and related tools. While it could be structured with bullet points for improved readability, every sentence contributes useful information, and it is not overly verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that an output schema exists and the tool has 6 parameters (1 required), the description is highly complete. It explains how to obtain the required 'id', the two modes with their differences, pagination details, filtering by speaker, and links to sibling tools for media and session IDs. This ensures an agent can effectively use the tool without additional lookups.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% (all 6 parameters are described in the input schema). The description adds value by explaining the purpose of the 'modo' parameter in detail, how 'sequenciaInicio' and 'sequenciaFim' enable pagination, and how 'orador' filters blocks by speaker. It does not simply repeat the schema but provides practical usage context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Obtém' and the resource 'notas taquigráficas (transcrição oficial)' and distinguishes between plenary sessions and committee meetings via the 'tipo' parameter. It differentiates from sibling tools by specifying how to obtain the 'id' from related tools like 'senado_agenda_plenario' and 'senado_reuniao_comissao', and notes the availability of media via 'senado_videos_taquigrafia'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides guidance on when to use the tool: to retrieve official transcripts of sessions. It also explains how to obtain the required 'id' from other tools, which is helpful context. However, it does not explicitly state when NOT to use the tool or compare it to alternatives for transcription retrieval, which would enhance clarity.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate read-only and open world. Description adds details: returns specific fields, null for extinction date on active blocks, and error behavior for nonexistent code. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences, front-loaded with purpose, no unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given output schema (which describes return object), annotations, and simple 1-param input, description fully covers behavior, error handling, and prerequisite.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema 100% covers parameter 'codigo' with description. Description adds prerequisite info (get from senado_listar_blocos), adding value beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clear verb 'Obtém' and resource 'bloco parlamentar específico pelo seu código'. Distinguishes from sibling tools like senado_listar_blocos (which lists all) and senado_obter_comissao (different entity).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit guidance: obtain 'codigo' via senado_listar_blocos first, and note that invalid code returns error with specific message.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description explains that the sigla is resolved internally to a numeric code, which is a behavioral detail not in annotations. It also details output structures for both secao options. Annotations already indicate readOnlyHint and openWorldHint, and no contradiction exists.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single dense paragraph that front-loads purpose and efficiently covers parameters, output structures, and a cross-reference. It is concise without omitting critical information, though a bulleted list could improve readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the existence of an output schema (not shown but indicated), the description provides sufficient detail on the two sections and internal resolution. It covers all necessary context for an agent to select and invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema description coverage, the description adds value by explaining the meaning of secao ('resumo' vs 'membros'), providing example siglas (CCJ, CAE), and describing output fields beyond simple types.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Obtém dados') and resource ('comissão'), identifies the key parameters (sigla, secao), and clearly distinguishes from sibling tools like senado_listar_comissoes by referencing it for discovering siglas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description tells when to use this tool (to get commission data by sigla) and directs users to senado_listar_comissoes to find valid siglas. However, it does not explicitly state when not to use it or mention alternatives for other commission-related tasks (e.g., meetings).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate read-only, but description adds value by detailing the return object structure and fields, going beyond basic annotation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences: first states purpose and return fields, second gives prerequisite. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given simple input and annotations, the description adequately explains what the tool does and returns. Could mention error cases but not essential.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Parameter 'codigo' is fully described in schema with 100% coverage; description adds no additional meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it obtains details of a specific federal legal norm by code, and lists return fields. Distinguishes from sibling tool 'senado_buscar_legislacao'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly instructs to obtain the code first via 'senado_buscar_legislacao', providing clear when-to-use and alternative.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations (readOnlyHint, openWorldHint) are consistent with read-only access. Description adds behavioral details not in annotations, such as truncation behavior, default limits, and inclusion of aviso when truncated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is detailed and well-structured, front-loading the main purpose and then breaking down each secao. Though lengthy, every sentence adds valuable information; minor reduction could improve conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description still fully explicates return structures for all secao options, covers parameter behavior, and provides a complete picture for tool usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Despite 100% schema coverage, description significantly enriches parameter meaning by explaining secao values, default behavior, applicable limits, and the return structure for each option, exceeding what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool retrieves data for a specific materia using codigoMateria, differentiates between secao options, and explicitly references sibling tool senado_buscar_materias for obtaining the required ID.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Describes when to use each secao (detalhe for full details, tramitacao for history, textos for documents) and directs to senado_buscar_materias for finding codigoMateria. Lacks explicit exclusion scenarios but provides clear usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and openWorldHint. The description adds value by listing the exact fields returned, confirming the read-only nature and providing transparency about the output shape. It does not disclose any additional behavioral traits beyond annotations, but the added context is sufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with two sentences: first states purpose and lists output fields, second gives usage guidance. Every word adds value, no redundancy, and it is well-structured for quick comprehension.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the low parameter count, full schema coverage, annotations present, and description covering purpose, usage, and output fields, the description is complete for its complexity. No output schema needed as description lists fields.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There is only one parameter, idProcesso. Schema description covers its meaning, but the description adds crucial context that this ID must be obtained from other tools, enhancing usability beyond the schema alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description begins with a clear verb 'Obtém detalhes completos' and identifies the specific resource 'processo legislativo' by its id. It lists all return fields, and explicitly distinguishes from sibling tools by naming alternatives for obtaining the ID and for more detailed queries.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly instructs to obtain idProcesso via senado_search_processos or senado_buscar_materias before using this tool. It also states when to use senado_processo_detalhe instead for emendas, relatorias, or prazos, providing clear when-to-use and when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No contradiction with annotations (readOnlyHint=true). Description adds detail on the return object structure (fields listed), which is beyond annotations. No destructive behavior implied.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Four sentences, each serves a purpose: purpose, return format, parameter requirement, and alternative tool. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema (mentioned in description) and sufficient annotations, the description fully covers what the tool does, what it returns, and how to use it. No missing context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline 3. Description adds value by stating the parameter is required and advising how to obtain it ('via senado_listar_senadores'), going beyond the schema description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the verb 'Obtém' and resource 'detalhe biográfico de um senador'. It distinguishes from sibling tools by mentioning 'senado_senador_historico' for related but different data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly tells when to use this tool (to get biographical details) and when not to (use 'senado_senador_historico' for other histories). Also guides the user to obtain the required parameter from 'senado_listar_senadores'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate readOnlyHint and openWorldHint. The description adds contextual details such as the conditional return shape (multiple votes vs single vote) and the alias relationship between codigoVotacao and codigoSessao, which enhances transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no redundant information. Front-loaded with purpose and key details, then prerequisite. Very concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the single parameter and existing output schema, the description covers input derivation, output structure in both scenarios, and prerequisite, making it fully sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description for codigoVotacao is complete, and the description adds semantic value by explaining that codigoVotacao is actually the codigoSessao, providing essential context beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it retrieves voting details by a specific code, includes nominal votes, and describes the return structure. It distinguishes the tool from its sibling by specifying the prerequisite call to senado_search_votacoes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly instructs to obtain codigoSessao via senado_search_votacoes before calling, providing clear context. Could be improved by mentioning when not to use this tool, but the guidance is strong.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond readOnlyHint and openWorldHint annotations, the description details response structures for each tipo, empty list behavior, and confirms no other parameters.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Dense but slightly verbose; could be tightened without losing clarity. However, it is well-structured with code formatting.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Fully complete given the output schema exists; description provides enough context for correct invocation and understanding.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Adds significant meaning beyond schema: explains default value, maps each enum option to its response shape, and confirms no other parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it lists parliamentary amendments and support letters, specifies the two tipos, and explicitly distinguishes from sibling tool senado_execucao_orcamentaria for internal budget.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly tells when to use (for federal budget amendments), when not to use (for internal Senate budget) and names the alternative tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses the return structure in detail (count, votacoes, fields like codigoVotacao, orientacoes, etc.) and notes that the tool is read-only and open-world. This adds value beyond annotations which already indicate readOnlyHint and openWorldHint.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, consisting of two main sentences. It front-loads the core purpose and then details the return structure. While it packs a lot of information, it remains readable and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema, the description provides sufficient context: it explains the tool's output format, parameter combinations, and references an alternative. It fully addresses the tool's usage scenario.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema coverage is 100%, the description adds meaning by explaining that parameters 'data' (single day) or 'dataInicio'/'dataFim' (period) can be used, and implies at least one should be provided. This clarifies usage beyond the schema's simple descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool returns party leadership voting orientation and placar, specifically for analyzing party discipline. It distinguishes itself from sibling tools like senado_resultado_plenario by explicitly mentioning it returns orientation data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description tells the agent when to use this tool (for orientation) and explicitly points to an alternative: 'Para o resultado das sessões use senado_resultado_plenario.' It also instructs on parameter usage, specifying that a single date or a period can be provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses the output structure {tabela, count, total, aviso?, registros[]}, explains behavior for empty tables (count=0, empty list), and details the optional filter; annotations already indicate read-only, so no contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Single paragraph contains all necessary information but could benefit from bullet points for easier scanning; however, it is not verbose and front-loads the purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of multiple tables and parameters, the description covers all aspects: purpose, parameter semantics, output structure, and edge cases (empty results, use of filters).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All three parameters have schema descriptions (100% coverage), and the description adds value by explaining how 'tabela' determines output type, the maximum and default for 'limite', and the filter behavior across fields.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool retrieves personnel tables from the Senate, lists specific table options differentiating between aggregate quantitative and nominal lists, and explicitly distinguishes from sibling tool 'senado_servidores' for nominal registration of servers.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly describes when to use each table type (aggregate vs nominal) and provides a direct alternative ('senado_servidores') for a different use case, making context and exclusions clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnlyHint and openWorldHint annotations, the description details the return structure ({ secao, count, total, aviso?, itens }), pagination (limite with default 100, max 500), and notes that prazos returns raw API records. No contradictions with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is comprehensive and well-structured with bullet points, but somewhat lengthy. It front-loads the main purpose and uses clear formatting, but could be slightly more concise. Still, every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (10 parameters, conditional behavior based on secao), the description is remarkably complete. It covers all parameter combinations, return format, limits, and references external tools for prerequisite data. The output schema existence reduces burden, but description still provides necessary context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds significant value: for each secao it lists returned fields and applicable filters (e.g., codigoParlamentarAutor for emendas), explains date format (YYYYMMDD or ISO), and clarifies conditional parameters like dataReferencia for relatorias/prazos.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it details legislative process aspects based on the 'secao' parameter, listing three sections (emendas, relatorias, prazos) with their respective fields. It distinguishes from siblings by referencing prerequisite tools (senado_search_processos, senado_tabelas_processo) and specific use cases.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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 each section, acceptable filters, and prerequisite steps (getting idProcesso from another tool). It advises to inform at least one filter. It lacks explicit exclusion conditions but overall offers 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=true, and the description does not contradict. It adds behavioral details like the limite cap (500) and truncation warning ('aviso'), which go beyond annotations. Missing details on rate limits or authentication but sufficient for a read-only tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Single paragraph, dense but well-structured. Front-loads key purpose and parameters. Could be improved with section breaks but remains concise and informative without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given moderate complexity (two modes, six parameters), the description covers output shapes, filters, and limits. References sibling tool for registration. Missing details on error handling or exact date format, but overall adequate for usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 100% coverage, so baseline is 3. The description adds value by explaining output shapes for each modo, indicating that nome and tipoFolha are partial searches, and detailing the aggregated vs individual fields. This meaningfully extends the schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves salary data for Senate employees by year/month, with two distinct modes (resumo and detalhe). It explicitly differentiates from sibling tool 'senado_servidores' for employee registration, making the purpose specific and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides guidance on when to use resumo vs detalhe, suggests filters to avoid long lists in detalhe, and references the sibling tool for registration. However, it does not explicitly state when not to use this tool or list alternatives beyond one sibling.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint=true and openWorldHint=true. Description adds pagination behavior (page beyond total returns count 0) and edge case (CPIs without requerimentos return empty list). No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is efficient: front-loaded with purpose, then pagination, return format, and edge cases. Each sentence adds information; no fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers return structure, pagination, how to obtain siglas, and handles edge cases. Output schema is noted as present, and description supplements it well.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline 3. Description adds meaning: pagina is index based on 0 defined by upstream, siglaCpi examples given. Adds value beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it lists requerimentos of a CPI by siglaCpi with pagination. It distinctively tells how to obtain siglas via sibling tool 'senado_listar_comissoes', effectively differentiating from other tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly instructs to use 'senado_listar_comissoes' to discover siglas. Explains pagination: page index starts at 0, count=0 indicates end. Does not state when not to use, but context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint and openWorldHint. The description adds behavioral context: returns all sessions without pagination, describes response structure with possible null fields for items not yet deliberated, and explains empty results. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, front-loading the main purpose, and every sentence adds value. No redundant or filler content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (multiple nested fields, edge cases), the description comprehensively explains the return format, including fields like codigoSessao, data, itens, and handling of null results and empty sessions. It also covers the escopo parameter variations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with both parameters well described. The description echoes schema details (date format, escopo enum) but does not add significant new information beyond what the schema already provides. Baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states what the tool does: returns results of plenary sessions for a given date, including agenda items, opinions, and outcomes. It distinguishes itself from siblings by mentioning alternative tools for prior agenda (senado_agenda_plenario) and voting orientation (senado_orientacao_bancada).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear when-to-use guidance (getting session results) and when-not-to-use guidance (for prior agenda or voting orientation), naming specific alternative tools. It also explains scope options (sf, cn, mes).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and openWorldHint. The description adds critical details: return format (codigo, tipo, resultado), variable fields, empty object for unvoted veto, and error on invalid code—all beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured but slightly verbose. Each sentence adds value (purpose, return format, edge cases, parameter guidance, source for code). Could be trimmed slightly but overall efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists (not shown), the description covers return structure, edge cases (empty, error), and parameter semantics. No obvious gaps for a single-item retrieval tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, baseline 3. The description explains the 'tipo' enum values (veto, materia, dispositivo), default, and how to interpret 'codigo' based on type, adding value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves the result of a nominal vote on a presidential veto, specifies the return structure, and distinguishes it from the sibling tool 'senado_vetos' by referencing it for obtaining the code.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use (to get veto result), behavior for non-existent code (error) and unvoted veto (empty object), and directs to 'senado_vetos' for the code. It lacks explicit alternatives but provides sufficient context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the tool is safe. The description adds value by detailing the structure of the returned object, including fields like partes and links, which provides transparency beyond the annotations. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise: two sentences with no filler. The first sentence states the action, and the second lists the return fields. It is front-loaded and every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has only one parameter with 100% schema coverage and a known output schema (though not provided), the description fully explains the input source and the output structure. For a detail retrieval tool with clear annotations, it is complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema provides a description for codigoReuniao, but the description adds context by explaining that it is the code from the agenda or list tools. This extra guidance helps the agent understand how to obtain the parameter value, going beyond the schema's own description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: to detail a committee meeting by its code. It distinguishes from sibling tools like senado_agenda_comissoes and senado_reunioes_comissao by specifying that the codigoReuniao should be obtained from those tools, indicating that this tool provides detailed information rather than listing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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 the tool (when you have a codigoReuniao) and explicitly mentions where to obtain that code (from senado_agenda_comissoes or senado_reunioes_comissao). It does not explicitly state when not to use it, but the alternative tools are implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.