Senado BR MCP

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering safety and idempotency. The description adds transparent behavioral details: default date (today), return structure with fields, and optional filters. 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 concise (two sentences) and front-loaded: first sentence states primary purpose and parameters, second covers return format and sibling distinctions. One more sentence could be combined, but it's efficient and well-structured.

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 annotations (readOnly, idempotent) and an output schema (though not shown, indicated as present), the description is complete: it explains return shape, default date, filter, and links to siblings. No gaps for a tool with two non-required parameters and clear semantics.

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, each parameter explained. The description adds semantic value by stating the default for 'data' (today) and explaining the return shape, which enriches understanding beyond schema alone. Slight deduction since schema already covers core 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 obtains the meeting agenda for all commissions on a specific date, with an optional filter by commission acronym. It explicitly distinguishes from sibling tools 'senado_reunioes_comissao' (historical data) and 'senado_reuniao_comissao' (meeting details), ensuring no ambiguity.

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 this tool (agenda for a specific date) and when to use alternatives (historical data via 'senado_reunioes_comissao', meeting details via 'senado_reuniao_comissao'). This helps the agent choose correctly among siblings.

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, idempotentHint=true, etc. The description adds value by detailing the return structure (`{ data, escopo, count, sessoes }`), default behavior (assume hoje), and that it returns the agenda (a read operation). 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 concise sentences: purpose+return, parameter usage, alternative tools. No fluff, front-loaded, easy to scan.

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 covers all essential aspects: what the tool does, input parameters with defaults, output structure with fields, and links to related tools. Given the tool's complexity (3 optional params, output schema alluded to), this is comprehensive.

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% for three parameters, each with descriptions. The description adds minor context (e.g., default for data, escopo options), but does not significantly enhance beyond the schema. 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 verb 'Obtém' (gets) and resource 'agenda de sessões de plenário' with scope (dia/mês/cn) and content (pauta de matérias). It also distinguishes from sibling tools by explicitly naming alternatives for results and session 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 clear guidance on parameter usage (escopo, data default) and explicitly names alternative tools for different purposes (resultado_plenario, encontro_plenario). However, it does not explicitly outline when not to use this 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?

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the description adds value by detailing return structure (count, total, autores), sorting, partial search behavior, and limit constraints, 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?

Three sentences: first covers purpose and output, second lists fields, third explains filters and integration. No redundant words, front-loaded with key action.

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, output structure, optional filters, default/max limit, and how to use the output in other tools. Given the presence of an output schema and low complexity, the description is 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: it specifies that 'nome' performs partial search without accents, and 'limite' defaults to 50 with max 1000, which is not evident from schema descriptions 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?

Description states 'Lista parlamentares autores de processos em tramitação' with a specific verb (lista) and resource (autores), and distinguishes from siblings by mentioning sorting by production and returning author codes, which are used in other tools like senado_obter_senador.

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 the agent to use the 'codigo' in senado_obter_senador or senado_search_processos, providing clear chaining guidance. Also explains filter options and default limit, though lacks explicit when-not-to-use statements.

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 set readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds value by specifying the minimum parameter requirement, the response structure (count and normas with fields), and error behavior. 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?

Three concise sentences with no waste. First sentence states purpose, second details return format, third provides usage constraints and cross-references. Front-loaded 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 4 parameters (none required), output schema exists, and annotations cover risk, the description fully covers what the tool does, its constraints (at least one param), the return shape, and links to related tools for deeper actions. 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 description coverage is 100% (all 4 parameters have descriptions). The description merely lists the parameters in a summary ('por tipo, numero, ano ou data') without adding new semantic info. 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?

Description clearly states it searches federal legal norms by specific parameters (tipo, numero, ano, data) and distinguishes from sibling tools like senado_obter_legislacao (for details) and senado_tabelas_referencia (for valid tipos). Verb 'Busca' and resource 'normas jurídicas federais' 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?

Explicitly states that at least one parameter is required, otherwise returns error. Provides clear guidance on when to use this tool vs. alternatives: use codigo in senado_obter_legislacao for details and consult senado_tabelas_referencia for valid tipos.

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, idempotentHint, destructiveHint=true/false. The description adds return structure details (count, total, materias[] with fields) and truncation behavior (includes 'aviso'), which complements the annotations well without contradiction.

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

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

The description is a single well-organized paragraph with front-loaded purpose, followed by usage patterns, return structure, and cross-reference. Every sentence adds value, slightly longer than minimal but 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 11 parameters, high schema coverage, and existing output schema, the description covers all essential aspects: purpose, usage guidance, parameter semantics, return structure, and interaction with sibling tools. No gaps for an AI agent to select and invoke 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 meaningful context: explains default ordering (`ordenarPor: 'dataApresentacao'` favors recent requests), clarifies `sigla` values (PEC, PL, etc.), and describes `limite` default/max and truncation behavior. These add 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 searches legislative matters by multiple criteria (type, number, year, keywords, author, date range, status), and explicitly distinguishes from the sibling tool `senado_obter_materia` by guiding when to use `codigo` for 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?

Provides explicit when-to-use guidance (e.g., for recent matters use specific parameters) and when-not-to (avoid calling details for listing, use `senado_obter_materia` for detail/tramitação/textos). Also gives concrete example for 'matérias recentes sobre X'.

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?

With rich annotations (readOnly, idempotent), the description adds significant context: output structure for aggregated/detail modes, filtering behavior (partial match), truncation with warning, and the need to use another tool for senator codes. 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?

Concise, front-loaded with purpose, structured with semicolons and line breaks, every sentence adds value. 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 8 parameters (1 required), 100% schema coverage, and output schema, the description covers output shape for all modes, filtering, truncation, and a pointer to a related tool. Complete for a data 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?

Description explains 'modo' behavior and output shape for each mode, filtering partial match semantics, and truncation limit with warning alert. This adds meaning beyond the schema, which only lists 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?

The description clearly states it returns CEAPS expenses for senators in a given year, with specific output shape for different modes. It uniquely identifies the resource (despesas CEAPS) and distinguishes from sibling tools by topic.

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?

No explicit when-to-use or when-not-to-use instructions. It mentions obtaining codSenador via another tool, implying a prerequisite, but does not compare with siblings or advise on mode 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 already indicate a safe read operation. The description adds critical behavioral details: validation rules (aditivos only for contratos, acionamentos only for atas), return format with pagination (limite, count, itens), and error handling for invalid combinations, all 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?

The description is a single, well-structured paragraph that front-loads the main purpose. Every sentence adds value, covering parameters, return format, and usage notes without redundancy or 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?

Given the tool's complexity (4 parameters, enums, validation rules, pagination) and the presence of an output schema, the description is comprehensive. It covers all aspects: parameter meanings, valid combinations, return shape, pagination behavior, and error conditions.

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 baseline is 3. The description adds significant meaning: it explains the semantic differences between 'tipo' values (contract vs. price agreement vs. budget reservation) and lists valid 'secao' combinations, providing context the schema alone does not.

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 with a specific verb ('detalha') and resource ('seção específica de uma contratação'). It explains the meaning of 'tipo' and 'secao' values, and directs users to obtain the 'id' from sibling tools, effectively distinguishing it from list 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 provides clear usage context, including how to obtain the 'id' from related tools and the valid combinations of 'secao' and 'tipo'. However, it does not explicitly state when this tool should be preferred over alternatives or when not to use it.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, indicating a safe, read-only operation. The description adds behavioral details beyond annotations: it specifies the return structure ({ tipo, count, total, registros }), differentiates the format for 'menores_aprendizes' as raw API records, and describes the truncation behavior with 'aviso'. 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 well-structured: it starts with the tool's purpose, then output format, then details about limits and alternatives. Every sentence adds value, though it could be slightly more concise. It fits the definition of concise for a tool with moderate complexity.

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 3 parameters (one required), annotations indicating safety, and the description provides return format and behavioral details, it is quite complete. The description covers what is needed for an agent to use the tool correctly, including when to use an alternative 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%, so baseline is 3. The description adds context beyond the schema: it explains that 'filtro' is applied on the Worker to all fields, and reiterates the default and maximum for 'limite'. This provides useful semantic 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 what the tool does: lists specific types of contract records (atas de registro de preço, notas de empenho, menores aprendizes) with optional text filtering. It distinguishes from the sibling tool senado_contratacao_detalhe, which is mentioned as an alternative for deeper 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 explicitly says when to use this tool (to list these contract types) and when not to use it (for deeper detail, use senado_contratacao_detalhe). It also mentions the limit and truncation behavior, providing 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 indicate read-only, idempotent, non-destructive. The description adds behavioral context such as the limit of results (default 50, max 500), truncation warning (aviso), and the specific return fields, which go 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?

The description is extremely concise (two sentences) and well-structured: first sentence states purpose and filters, second sentence details return format, limits, and usage hint. 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 7 optional parameters, output schema, and clear annotations, the description covers purpose, return structure, pagination limits, and a usage flow to a sibling tool. It is complete for an AI agent to select and invoke this 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% with each parameter having a description. The description reiterates the search filters but adds minimal new semantics (e.g., 'filtros aplicados pela API upstream'). It does not significantly enhance 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 that the tool searches Senate administrative contracts by various criteria (fornecedor, CNPJ, ano, numero, objeto, maoDeObra). It also specifies the return structure and how to use the returned id for further details, distinguishing it from sibling tools like senado_contratacao_detalhe.

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 hints at usage flow (search then use id for details) but does not explicitly state when to use this tool versus alternative listing tools like senado_contratacoes_lista. It provides truncation behavior but lacks explicit when-not-to-use guidance.

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

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

Annotations already provide readOnlyHint, idempotentHint, etc. Description adds return structure details but no additional behavioral context beyond parameter format, which is also in 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, neither wasted. First sentence covers purpose and parameters; second gives output structure and alternatives. Very 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 simple two-parameter tool with output schema, description covers input, output, and alternatives. Could mention pagination or limits, but not critical.

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 and patterns. Description restates format and required status, adding minimal new 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?

The description clearly states the verb 'Lista' and resource 'discursos realizados em plenário' with required date parameters. It differentiates from siblings by naming two alternative tools for 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?

Explicitly states when to use (list all plenary speeches in a date range) and when not to (for specific senator speeches or full text) with direct references to 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 indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the tool's safe nature is covered. The description adds transparency about the output structure (including fields like codigo, data, casa, resumo, etc.) and clarifies that no full text is returned. It does not mention pagination or rate limits, but the openWorldHint may imply extensive results.

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 essential information: purpose, parameters, output, and cross-references. It is front-loaded with the main action. While it could be more structured (e.g., bullet points), it remains clear and 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 the tool's complexity (5 parameters, 1 enum, output schema), the description is fairly complete. It explains the output structure in detail, links to related tools, and clarifies the behavior of the tipo parameter. It does not specify if results are paginated or limited, but the openWorldHint suggests broad coverage.

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 5 parameters have schema descriptions (100% coverage), so the schema already provides basic semantics. The description adds value by explaining the default for tipo, the distinction between discursos and apartes, and the output shape for each tipo. It also ties the parameters to the tool's purpose (filtering by period and house).

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 (speeches) of a senator, with filtering by period and house. It distinguishes from sibling tools by explicitly referencing senado_listar_senadores for obtaining the senator code and senado_discurso_texto for full text. It also specifies the tipo parameter differentiating discursos (own speeches) from apartes (interventions), making the tool's scope 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 provides clear context on when to use this tool: to list a specific senator's speeches with optional filtering. It explains the default for tipo and recommends using other tools for related tasks. However, it does not explicitly state when not to use it versus senado_discursos_plenario (which may list all plenary speeches), though the per-senator focus is implied.

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`, `idempotentHint: true`, and `destructiveHint: false`, which the description does not contradict. The description adds value by explaining the output structure but does not disclose potential error behavior or data completeness. The bar is lowered due to annotations, so a score of 3 is appropriate.

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

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

The description consists of three concise sentences with no extraneous information. It front-loads the core purpose, immediately followed by output format and prerequisite, making it easy to parse.

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 simple retrieval tool with one required parameter and good annotations, the description is nearly complete. It explains the output, prerequisite, and usage flow. Lacks mention of error handling or validation, but overall sufficient 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% with a description 'Código do pronunciamento'. The description adds context by linking the parameter to sibling tool outputs, which is helpful but does not significantly enhance the schema's meaning. Baseline for high coverage is 3, and the marginal context does not raise it further.

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 full text of a specific speech, specifies the output format with `codigoPronunciamento` and `texto`, and directs the user to sibling tools to obtain the required code. This leaves no ambiguity about the tool's function.

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

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

The description explicitly tells when to use this tool: after obtaining the `codigoPronunciamento` from `senado_discursos_senador` or `senado_discursos_plenario`. It provides a clear prerequisite and distinguishes from siblings by indicating this tool retrieves full text while others list speeches.

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, idempotent, and non-destructive behavior. The description adds context about the return structure and parameter interactions (e.g., codigoParlamentar only works with tipo=autoria), which is valuable 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?

The description is two sentences, efficiently covering purpose, parameters, output, and usage hint. No redundant information, and the structure is front-loaded with the main 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 moderate complexity (3 parameters, 1 required, 1 enum), the description fully covers the tool's behavior, parameters, and output format. The presence of rich annotations and a schema with 100% coverage means the description adds sufficient context without omission.

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 are fully described in the schema, and the description adds additional meaning: the default value for tipo, the exclusive use of codigoParlamentar with autoria, and the output structure. This goes beyond the schema to provide clear semantics.

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 provides distribution statistics of bills in a committee, with specific parameters and output format. It distinguishes from siblings by mentioning the prerequisite tool senado_listar_comissoes to obtain 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?

The description gives a clear use case (measuring legislative workload) and advises how to get the required committee acronym. However, it does not explicitly state when not to use this tool or compare it to alternatives among siblings, which would improve 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?

Adds context beyond annotations: explains behavior of status (aberta/encerrada/todas), that closed before first load are not captured, and return structure. 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?

Well-structured and front-loaded, but somewhat lengthy. Could be trimmed slightly, but justified by complexity of two modes and status explanation.

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 all aspects: purpose, modes, parameters, status behavior, and return shape. Output schema exists, so return explanation is 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%, but description adds meaning by explaining parameters in context of modes (e.g., percentualMinimo, margemPolarizacao) and their defaults, supplementing 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?

Description clearly states it analyzes open e-Cidadania public consultations by citizen agreement degree, distinguishing two modes (consenso and polarizada). It also differentiates from sibling tool for details. Specific verb+resource+scope.

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 each mode (consenso vs polarizada) with parameters, and when to use alternative tool for detail. Status options and default values are clearly described.

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 readOnly, idempotent, non-destructive. The description adds valuable context: data source (CSV Arquimedes), update frequency (semanalmente), special handling of status as archive, and return 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 detailed but not excessively long. It uses bold for key terms and front-loads the main purpose. However, it could be slightly more structured (e.g., bullet list for parameters) to improve scannability.

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?

Despite having an output schema, the description still explains the return format (count, referencePeriod, consultas) and special fields like 'recorteUf'. All 5 parameters are described with behavior. Ranking and filtering are explained. Completely adequate for effective 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 description coverage is 100% (baseline 3), but the description adds significant meaning beyond property descriptions: explains 'uf' adds 'recorteUf' to items, 'materia' allows numeric or text search, 'ordenarPor' ranking behavior, and default values. This enriches 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 accesses historical voting data from e-Cidadania public consultations, with breakdown by UF. It explicitly distinguishes itself from the sibling tool 'senado_ecidadania_listar_consultas' by stating the difference between ongoing vs historical consultations.

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 guidance on when to use this tool (for historical votes, not ongoing consultations) and explicitly names the alternative sibling tool. It also explains the handling of 'Descontinuado' status and gives usage context for parameters like 'uf', 'ordenarPor', etc.

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 idempotentHint, but the description adds valuable context: return format, lifecycle of consultations (aberta to encerrada), and limitation on capturing closed consultations before first ingestion. 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 a single, well-structured paragraph that efficiently conveys purpose, output, lifecycle, parameters, and sibling references. No unnecessary 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 the presence of an output schema (mentioned in context signals) and comprehensive parameter documentation, the description fully covers the tool's functionality, behavior, and relationship to siblings. 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?

Input schema covers all three parameters with descriptions (100% coverage). The description reinforces default values and explains the meaning of status options, 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 lists public consultations from e-Cidadania, focusing on open ones, and details the output structure. It distinguishes from sibling tools by naming specific alternatives for detail and analysis.

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 and refers to sibling tools for specific needs (detail, analysis). It explains the lifecycle of consultations, aiding in appropriate usage, but does not explicitly state when not to use it.

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

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

Annotations already declare readOnlyHint, openWorldHint, etc. The description adds behavioral context: data is a complete corpus (D1), updated weekly, includes thousands of events even closed, and returns a specific structure with count and eventos. 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 fairly long but well-structured: purpose first, then return format, then filters, then examples. Each sentence adds value, though it could be slightly more 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 complexity (5 params, output schema exists, annotations rich), the description is comprehensive: it explains return structure, all filters, sorting, and points to the sibling tool for full details. 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% so baseline is 3. The description adds value beyond schema by explaining the ranking usage (ordenarPor, ordem) and default limit, and by clarifying the return 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?

The description clearly states the tool's purpose: 'Lista eventos interativos do e-Cidadania', a specific verb+resource. It distinguishes from siblings by naming the alternative tool for full details and implies this tool returns the complete set.

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 states when to use this tool (listing events) and when not to (for full details, use senado_ecidadania_obter_evento). It also provides context on data freshness and scope.

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, destructiveHint=false, idempotentHint=true. The description adds that the corpus is persisted in D1, updated weekly, includes ~150k ideas, and that autor/dataPublicacao are null in listing.

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?

Every sentence serves a purpose: purpose, dataset size, return structure, filters, ordering, and sibling tool reference. No wasted words; front-loaded with main action.

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 5 parameters and no output schema details provided, the description covers return format, filtering, ordering, dataset context, and links to the detail tool. Complete 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%, baseline 3. The description adds value by explaining the default for limite (20), the effect of ordenarPor='apoios' with ordem='desc', and that status filters like 'aberta'/'encerrada'/'convertida' are available.

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 'Lista' and resource 'ideias legislativas no e-Cidadania', and distinguishes itself from the sibling tool 'senado_ecidadania_obter_ideia' for detail 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 this tool (list all ideas) and when not (for detail, use the sibling). Also provides an example for ordering by apoios descending to get a ranking.

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, idempotent, non-destructive behavior. Description adds specific return fields and notes nullable fields (comissao, dates). 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 sentences: first covers purpose and return, second gives usage instruction. Zero waste, front-loaded with essential 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?

For a simple tool with one parameter and clear annotations, description fully covers return structure, parameter source, and behavior. Output schema exists but description already lists fields, making it 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?

Only one parameter (id) with 100% schema coverage. Schema already describes 'ID da consulta pública'. Description adds context on where to get id, but does not add new meaning about parameter semantics 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?

Clearly states 'Obtém o detalhe de uma consulta pública específica do e-Cidadania', specifying verb (obter), resource (consulta pública), and scope (específica). Lists return fields, distinguishing it from sibling 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?

Explicitly instructs to obtain the id via sibling tools (senado_ecidadania_listar_consultas or senado_ecidadania_consultas_analise) before using this tool, providing clear when-to-use guidance and 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 declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, indicating safe, non-destructive behavior. The description adds value by detailing the return fields (id, titulo, descricao, data, etc.), including array fields like pauta and convidados, and noting the videoUrl format. This goes 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?

The description is concise, two sentences, front-loaded with the main action. It efficiently lists the return fields without redundancy. 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?

For a simple retrieval tool with one parameter, the description provides complete context: what the tool does, what it returns (including field names and limits like 'até 15 itens'), and how to obtain the required id. The presence of an output schema is noted, but the description adequately covers the key aspects.

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 parameter 'id' is already described in the schema as 'ID do evento' with constraints. The description does not add further semantics about the parameter itself, but it does contextually link the id to the list tool. 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 verb 'Obtém' and the resource 'detalhe de um evento interativo do e-Cidadania'. It distinguishes this from the sibling tool 'senado_ecidadania_listar_eventos' which lists events, while this retrieves details of a specific event.

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 users to obtain the event ID via 'senado_ecidadania_listar_eventos' first, providing clear prerequisite guidance. It lacks explicit 'when not to use' but the context is straightforward given the tool's singular purpose.

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, idempotentHint, destructiveHint. The description adds value by noting that the 'descricao' field is truncated to ~2000 characters, which is a behavioral trait not covered by 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, with three sentences that front-load purpose and return type, include important behavioral detail (truncation), and guidance. 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 output schema exists, the description appropriately lists key fields without enumerating them fully. It mentions the truncation behavior, making it complete for this simple 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?

The schema covers 100% of the single parameter. The description adds context by explaining how to obtain the required 'id' (from the listing tool), which goes beyond the schema's 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 action (obter/get) and the resource (detalhe de uma ideia legislativa). It distinguishes from the sibling listing tool by explicitly instructing to obtain the id via that tool first.

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 provides usage guidance by telling the agent to get the id from 'senado_ecidadania_listar_ideias' first, implying when to use this tool. It does not explicitly mention alternatives or 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?

Annotations already indicate read-only, open-world, idempotent, non-destructive behavior. The description adds context about criteria application, ordering, and return format, with 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?

Well-structured and informative, but slightly verbose in places. Could be trimmed without losing clarity, but still efficient overall.

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 criteria-based suggestion with filtering and output structure, the description covers all necessary aspects: input criteria details, return format (with types and fields), ordering, and maximum items. Output schema exists but description already provides sufficient detail.

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% description coverage for all parameters. The description elaborates on default values and behavior (e.g., apenasEmTramitacao considers only open consultations), adding 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?

The description clearly states the tool suggests topics for a monthly public poll by analyzing consultations and ideas, filtering by engagement metrics. It distinguishes from sibling tools like senado_ecidadania_obter_consulta and senado_ecidadania_obter_ideia.

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 when to use this tool (for generating poll suggestions) and when to use alternatives: to investigate a suggestion, use senado_ecidadania_obter_consulta or senado_ecidadania_obter_ideia based on type.

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, idempotentHint=true, and destructiveHint=false. The description adds value by detailing the output format (fields, max 30 contracts) and the constraint that the base is large, requiring filters. 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 a single, well-structured paragraph. It front-loads the core action and search criteria, then lists output details and constraints. Every sentence is purposeful and adds 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's moderate complexity (3 parameters, output schema provided via description, annotations), the description covers essential aspects: search criteria, output format, limits, and relationship to other tools. Could mention error handling or empty results, but overall complete enough.

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 covers 100% of parameters with descriptions. The description adds the important constraint that at least one of nome or cnpj must be provided, which is not enforced in the schema (0 required). This clarifies usage 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 searches for companies contracting with the Senate by name (min 3 characters) or CNPJ/CPF (partial match). It specifies the output structure, including count, total, and detailed fields per company. It also mentions follow-up tools, providing a complete picture of the tool's purpose.

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 gives usage context: it requires nome or cnpj because the full base is large, and limits results to 'limite' (default 20, max 100). However, it does not explicitly state when to use this tool versus sibling tools like senado_contratacoes_lista or senado_contratos, nor provides when-not 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 already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds significant behavioral context: the return object structure, that encontro can be empty if no data, that an error occurs if codigo is invalid, and that output fields vary by secao. 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 well-organized and front-loaded, but it is moderately long. Every sentence adds value, but it could be slightly more concise. Overall, it efficiently communicates purpose, behavior, and usage.

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), the description does not need to detail return values. It covers error handling, empty results, and parameter sourcing from siblings. For a tool with 2 parameters and enums, this is comprehensive.

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?

Both parameters have schema descriptions (100% coverage). The tool description adds substantial value by detailing the source of codigo and providing detailed explanations of the secao enum values (detalhes, pauta, resultado, resumo) and what each returns, far beyond the schema's brief 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 retrieves details of a legislative meeting (plenary session) given a codigo and secao. It specifies the structure of the return value and distinguishes itself from siblings by explaining that codigo comes from senado_agenda_plenario or senado_resultado_plenario, leaving no ambiguity.

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 this tool (to get details of a session) and provides guidance on obtaining the required codigo parameter from sibling tools. It also notes error conditions and empty results. However, it does not explicitly state when not to use it or list alternatives for different needs, though the sibling context helps.

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, openWorldHint, idempotentHint, and destructiveHint. Description adds value by specifying return structure (tipo, modo, ano, totalLinhas, arrays), sorting, and truncation behavior with 'aviso' 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?

Concise, front-loaded sentences covering purpose, return structure, and usage guidance. No redundant or 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?

Given the tool has 4 parameters, enums, and an output schema, the description covers return format, aggregation modes, limit behavior, date ranges, and sibling differentiation. No missing critical details.

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. Description adds context by mapping 'modo' values to 'tipo' (e.g., por-acao/por-grupo for despesas, por-origem for receitas) and explaining 'ano' and 'limite' impact. This goes beyond the schema's generic 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?

Description clearly states tool retrieves Senado budget execution data, covering expenses and revenues with specific time ranges. It explicitly distinguishes from the sibling tool 'senado_orcamento_parlamentar'.

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 using aggregation modes vs. detail, filtering by year to reduce volume, and default limit. It also warns about truncation and clarifies the tool's uniqueness among siblings. No explicit when-not-to-use conditions beyond sibling distinction.

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 readOnly and idempotent. Description adds context: pagination (limite default 100, max 500), return structure including nested array, and that valorTotal sums the month. 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?

Single sentence that front-loads purpose, then covers return structure and parameters efficiently. No filler.

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 4 parameters, output schema present, and rich annotations, the description explains the output structure explicitly and covers all parameters. Complete for the tool's 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% with descriptions for each parameter. Description reiterates but adds little new: 'busca parcial' for nome and limits for limite are already in schema. No significant enrichment 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?

Describes specific verb+resource: 'Horas extras pagas a servidores do Senado em ano/mês' and returns structured data. Distinguishes from sibling 'senado_remuneracoes_servidores' by mentioning it explicitly.

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?

States when to use (retrieve overtime by month/year), provides optional filters (nome, limite) with defaults, and explicitly points to alternative tool for full remuneration.

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 readOnly and idempotent, but description adds response structure (count, total, licitacoes), limit constraints (default 50, max 500), and error condition. 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?

Two sentences, front-loaded with purpose, concise and informative, 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?

Complete coverage: input constraints, output format, limit behavior, error case, and pointer to sibling tool for follow-up. Output schema exists but description still adds 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% with descriptions, but description adds useful context: exact number format example '19/2018', text search for 'objeto', and the requirement to provide at least one filter. This 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 it searches for Senado bids by exact number or object text, using the verb 'Busca' and specifying the resource. It distinguishes from sibling tool 'senado_contratos' by directing users there 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?

Explicitly states when to use (search by number or object), requires at least one of 'numero' or 'objeto' or an error is returned, and provides clear alternative for contracts: 'use senado_contratos'.

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 idempotentHint=true. Description adds return structure and filter behavior but does not disclose additional behavioral traits beyond what annotations provide.

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

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

Two well-structured sentences: first defines purpose and return, second lists filters 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 4 optional parameters and presence of output schema, description fully explains response structure, all filters, and provides a cross-reference to a related 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 parameter descriptions. Description mentions possible values but does not add significant meaning beyond what schema already 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 it lists leadership (líderes, vice-líderes) of Senate and Congress, specifies return structure and filters, and distinguishes from sibling tool senado_listar_blocos.

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 alternative (senado_listar_blocos for blocos) and explains filtering options, providing clear context for when to use this 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?

Annotations already declare readOnlyHint, destructiveHint, idempotentHint, openWorldHint. Description adds return structure and field details, enhancing transparency beyond annotations without contradiction.

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

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

Two sentences: first covers purpose and output, second gives usage guidance. Every sentence adds value, 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?

Given zero parameters, comprehensive annotations, and output schema implied by description, the description fully covers what the tool does, returns, and how to use it with related tools.

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 baseline 4 applies. Description does not need to add parameter info, and it provides output format 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 tool lists all parliamentary blocs and their member parties, using specific verb and resource. It distinguishes from siblings by directing to senado_obter_bloco for details and senado_liderancas for leaderships.

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 provided: use to discover bloco codes, then detail via senado_obter_bloco; for leaderships use senado_liderancas. Clear when-to-use and 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 read-only, idempotent. Description adds behavior (only active commissions, filter behavior) and return structure, going 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?

Three concise sentences: purpose, return, usage. No redundancy, 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?

For a listing tool with filters, description fully covers purpose, behavior, input, output, and usage context. Agent has all needed info.

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 both parameters (100%). Description adds context: explains behavior of ativa and enumerates tipo values, providing extra 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?

Description clearly states 'lista comissões ativas do Senado' with filters, and distinguishes its output (sigla) for use by sibling 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 states when to use (to discover sigla for other tools) and warns that ativa=false returns empty list.

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, so the tool is known to be safe. The description adds behavioral details: returns { count, senadores } with specific fields, explains partial name matching ignoring accents/case, and clarifies that uf/partido filter locally. 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?

Well-structured, front-loaded with example user requests. Each sentence adds value, covering usage, parameters, output, and cross-references. No fluff or 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 (not shown but indicated), the description sufficiently covers the tool's behavior, parameters, and output structure. It also links to related tools, making it complete for an 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 default for emExercicio (true), the partial matching behavior of nome, and that uf/partido are local filters. It also clarifies the relationship between emExercicio and legislatura.

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 senators with filters for UF/partido/nome, and distinguishes from sibling tools like senado_obter_senador (for details by code) and senado_senadores_afastados (for non-acting senators). The verb 'listar' and examples make the purpose unmistakable.

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 provides when-to-use examples ('liste os senadores em exercício', 'senadores atuais'), describes parameter scenarios (partial name matching, local filtering), and directs to alternatives: 'Use o codigo em senado_obter_senador ou senado_votacoes_senador' and 'Para senadores fora de exercício veja senado_senadores_afastados'.

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 destructiveHint; the description adds context on return structure and parameter behavior without contradicting annotations. 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?

Two sentences with no extraneous words; front-loaded with purpose, then parameter details and return structure.

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 provides a useful summary of return fields and covers parameter options. Meets all needs for this simple 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; description adds value by explaining the meaning of each enum value (senado vs. congresso) and the default.

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 with specific roles, and distinguishes it from the sibling tool for leadership (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?

Explicit guidance on when to use this tool (for Mesa Diretora) vs. alternative (senado_liderancas for leadership), and explains the parameter choice for senado vs. 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?

Given annotations already indicate readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, the description adds substantial behavioral details: pagination (max 20 blocks in texto mode), window controls via sequenciaInicio/Fim, and output structure differences between resumo and texto modes. 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 single paragraph is well-organized and front-loaded with purpose. It efficiently packs return structure, mode details, and usage guidance. Slightly wordy but every sentence earns its place; could be improved with bullet points but still good.

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 tool complexity (two modes, pagination, multiple parameters) and presence of an output schema, the description fully covers prerequisites, limitations, and output structure. It references sibling tools for necessary IDs and media, making it self-contained for agent 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?

Although schema coverage is 100%, the description adds significant meaning beyond field names: explains that 'id' comes from specific sibling tools, 'modo' behavior differences, 'tipo' distinguishes session vs meeting, 'orador' filters blocks, and sequenciaInicio/Fim control paging. This greatly aids agent 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 the tool obtains official shorthand transcriptions of plenary sessions or committee meetings. It details two output modes and distinguishes from sibling tools by referencing how to get the input ID (e.g., senado_agenda_plenario) and directing video needs to 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?

Provides explicit instructions on when to use this tool: obtain the session ID from senado_agenda_plenario/senado_resultado_plenario for sessions or senado_reuniao_comissao for meetings, filter by orador, and use senado_videos_taquigrafia for media. Clearly delineates from 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 indicate read-only, idempotent, and non-destructive behavior. The description adds valuable context: return field details, null for active blocs, and error handling. 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-loaded with the main purpose, and structured logically 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 annotations, output schema, and the description covering input sourcing and error cases, the tool definition is complete and sufficient for correct 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 description coverage is 100%. The description adds the crucial hint that 'codigo' should be obtained from senado_listar_blocos, which helps with correct invocation beyond the schema's basic 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 retrieves details of a specific parliamentary bloc by its code, listing the returned fields. This distinguishes it from siblings like senado_listar_blocos which lists all blocs.

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 the 'codigo' parameter via senado_listar_blocos and notes that an inexistent code returns an error, providing 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, idempotentHint, etc. The description adds valuable behavioral details: the internal resolution of sigla to numeric code, and the exact data returned for each secao value. 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 concise, well-structured, and front-loaded with the main purpose. It efficiently conveys the output shapes and important notes without 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 complexity (two output variants, internal resolution), the description is complete. It provides the output schema implicitly, explains parameter usage, and links to the discovery 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%, but the description adds significant meaning: it explains the effects of secao values (resumo vs membros), that sigla is resolved internally, and how to find valid siglas. This goes beyond the schema's basic type/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 that the tool retrieves committee data by sigla, with two distinct sections (resumo and membros). It specifies the output structure for each section and differentiates from the sibling tool senado_listar_comissoes by suggesting to use that tool to discover 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?

It explains when to use the tool (to get committee data) and how to obtain the sigla (via senado_listar_comissoes). While it does not explicitly list when not to use it, the context makes it clear it's for a single committee, and siblings cover other aspects.

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, openWorldHint=true, idempotentHint=true, and destructiveHint=false, indicating a safe, read-only operation. The description adds value by listing the specific fields returned (codigo, tipo, descricaoTipo, etc.) and mentioning the URL of the full text. 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 two sentences: the first states the purpose and output fields, the second provides a prerequisite. No unnecessary information. Front-loading the verb and resource makes the purpose immediately 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?

The tool has an output schema (not shown but referenced), and the description lists the output fields. Given the single parameter and simple retrieval nature, the description covers purpose, prerequisite, output, and safety. It 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 parameter 'codigo' is described in the schema as 'Código único da norma'. The description adds meaning by specifying that the codigo is obtained via 'senado_buscar_legislacao', providing context for how to get the required input. This extra guidance justifies 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 'Obtém os detalhes de uma norma jurídica federal específica pelo seu codigo', specifying a verb (obtém) and resource (norma jurídica federal). It also distinguishes from the sibling tool 'senado_buscar_legislacao' by indicating that the codigo must be obtained first via that tool.

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 gives explicit guidance on when to use the tool: after obtaining the codigo via 'senado_buscar_legislacao'. This provides clear context but does not include exclusions or alternative tools. However, given the sibling tools are mostly unrelated, this is sufficient.

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 goes beyond annotations by explaining truncation behavior (keeping most recent items, including an 'aviso'), default limits for 'tramitacao' and 'textos', and the chronological ordering for 'tramitacao'. This adds valuable context not covered by the readOnlyHint, idempotentHint, and other 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 detailed but well-structured with clear separation of sections. It could be slightly more concise, but every sentence serves a purpose and the overall length is justified by the complexity of the three sections.

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 is still highly complete: it covers all three section options, their return structures, default limits, truncation behavior, and the prerequisite to obtain 'codigoMateria' from another tool. No gaps are apparent.

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 adds significant meaning: it explains the outcome of each 'secao' value, provides default limits for 'limite' parameter (100 for tramitacao, 50 for textos), and describes the structure of the returned data for each option. This enriches the schema's bare 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 specifies the tool's function: retrieving data for a given 'codigoMateria' with different sections ('detalhe', 'tramitacao', 'textos'). It outlines the structure of each section's return object and distinguishes the tool by referencing how to obtain the required code via 'senado_buscar_materias'.

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 implicitly guides usage by detailing the available sections and their outputs, and explicitly advises obtaining the 'codigoMateria' from the sibling tool 'senado_buscar_materias'. However, it does not explicitly state when not to use this tool or mention alternative tools for similar purposes.

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, idempotentHint, and destructiveHint. The description adds the list of return fields but no contradictory behavioral info. While the description is accurate, it doesn't provide additional behavioral context beyond what annotations already 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?

Two sentences, front-loaded with purpose and return fields, followed by usage guidance. Every sentence adds value with zero 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 single parameter with full schema coverage, presence of output schema (implied by field list), and comprehensive annotations, the description completes the picture by also referencing sibling tools for related needs. No gaps remain.

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 a description for idProcesso. The description adds a usage hint about obtaining the ID beforehand, but does not enhance semantic understanding of the parameter beyond what the schema already provides. Baseline 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 it retrieves complete details of a specific legislative process by id, and distinguishes from sibling tools by specifying that senado_processo_detalhe should be used for emendas, relatorias, or prazos.

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 how to obtain the required idProcesso via senado_search_processos or senado_buscar_materias, and when to use an alternative tool (senado_processo_detalhe) for specific data, 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?

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds the return fields and parameter source but does not disclose additional behavioral traits beyond what annotations provide. 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 composed of two concise, front-loaded sentences. The first sentence states the purpose and lists return fields. The second sentence provides usage guidance and alternatives. 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?

For a simple retrieval tool with one parameter, the description covers purpose, return fields, parameter source, and alternatives for related queries. It is complete given the tool's complexity and the presence of an output schema.

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 codigoSenador, but the description adds value by instructing how to obtain it via senado_listar_senadores with a nome filter. This goes beyond the schema's basic 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 explicitly states 'Obtém o detalhe biográfico de um senador específico', clearly identifying the verb (obtém) and resource (detalhe biográfico de um senador). It also distinguishes from siblings by referencing senado_listar_senadores for obtaining the code and senado_senador_historico for other historical 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 provides explicit guidance: use this tool to get biographical details of a specific senator. It explains how to obtain the required codigoSenador via senado_listar_senadores with a nome filter, and directs users to senado_senador_historico (with tipo parameter) for other historical info like filiations and commissions.

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, idempotentHint, not destructive, and the description confirms a read operation. It adds details about the return structure (single object vs wrapped) and behavior for multiple votes, beyond what annotations provide.

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

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

The description is one sentence with two clauses, front-loading the purpose and parameter. Every part adds value, 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 the single parameter and the presence of an output schema, the description covers input, output variants, and prerequisite. It is fully self-contained for an agent to understand how to use the 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 covers 100% of the single parameter. The description adds the equivalence between codigoVotacao and codigoSessao, which clarifies the parameter 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 obtains voting details including nominal votes, and explains the return format. It distinguishes from the sibling tool senado_search_votacoes by referencing it as the source for the parameter.

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 a clear prerequisite. Does not explicitly exclude other use cases, but the context is sufficient.

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, idempotentHint=true, openWorldHint=true, destructiveHint=false. The description adds the response structure for each tipo, behavior when no records (count=0, empty list), and that it does not receive other parameters. 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 concise paragraph that front-loads the purpose and provides structured detail on responses. Every sentence adds value, 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 simple schema (1 enum param), rich annotations, and sibling differentiation, the description is fully complete. It explains output format, edge cases (empty results), and how this tool relates to others.

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% (1 parameter with enum). The description adds meaning beyond schema: it explains the two enum values (emendas/oficios), the response shape for each, and default value. It also clarifies that no other parameters are needed.

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 parliamentary amendments (emendas) or supporting offices (oficios) from senators to the federal budget. It specifies the default type and response structure, and distinguishes from sibling tool senado_execucao_orcamentaria.

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 says when to use (for amendments to federal budget) and when not (for internal budget, use senado_execucao_orcamentaria). It also explains the two types and default behavior.

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, non-destructive, idempotent. Description adds return structure details but not contradictory. Provides additional context on what data is returned.

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: purpose, return structure, usage, sibling reference. No unnecessary words, well 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?

For a simple query tool with 3 parameters, the description covers purpose, return fields, usage options, and sibling tool. 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%, but description adds usage nuance: data is for a single day, dataInicio/dataFim for a period, implying mutual exclusivity.

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 provides party leadership voting orientations with a scoreboard, and explicitly distinguishes itself from sibling senado_resultado_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 says when to use (single day or period) and when not to use (for session results, use senado_resultado_plenario), with clear alternative naming.

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 readOnly, idempotent, non-destructive. Description adds: empty results behavior ('count 0 e lista vazia'), pagination via 'limite' (default 100, max 2000), and filter matching against any field. 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?

Well-structured: first sentence states purpose, then enumerates tables, then return format, then behavior of parameters. Slightly verbose but every sentence adds value. Could be slightly tighter but remains 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 the tool has 3 parameters (all described), a full output schema description, and annotations covering safety, the description is comprehensive. It covers return shape, error conditions, and parameter details. No gaps for a read-only 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 covers 100% of parameters. Description adds value by detailing each enum option (e.g., 'pessoal: força de trabalho por classe/escolaridade') and explaining that 'filtro' matches against any field in the record ('casa contra qualquer campo do registro'), which is not fully specified 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 provides Senate personnel tables per the 'tabela' parameter. It enumerates all 8 table options with brief descriptions of content, and explicitly distinguishes from sibling tool 'senado_servidores' by directing users to that tool for nominal effective/commissioned servant records. This gives a specific resource and verb (implied 'consult'), with strong sibling differentiation.

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 when to use (e.g., for specific personnel tables) and when not to ('Para o cadastro nominal de servidores efetivos/comissionados use senado_servidores'). Also explains return structure, default/max limit, and filter behavior.

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 convey safe, read-only behavior. The description adds value by detailing the return structure, pagination limits (default 100, max 500), and the fact that 'prazos' returns raw API data. This context helps the agent understand behavior 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?

The description is dense but well-structured with clear sections and parenthetical details. It front-loads the main purpose. While somewhat long, the complexity of the tool justifies the length. Minor improvements could streamline wording.

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 (3 sections, 10 parameters), the description covers all necessary aspects: each section's purpose, accepted filters, return format, limits, and references to related tools. An output schema exists, so the description appropriately avoids redundant return value detail.

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 goes beyond by explaining the meaning of each 'secao' value, the associated return fields, and specific filter roles (e.g., 'codigoParlamentarAutor' for emendas). This adds significant 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 it details aspects of legislative processes based on 'secao' parameter, lists the three sections (emendas, relatorias, prazos) with their return fields, and distinguishes from sibling tools by mentioning how to obtain 'idProcesso' and types via 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?

Provides explicit guidance on when to use each section and which filters are accepted, including the requirement to provide at least one filter. It also references prerequisite tools for obtaining IDs and types. While it doesn't explicitly state when not to use, the instruction 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 indicate read-only, idempotent, and non-destructive behavior. The description adds output structure details, truncation warnings for limite, and field composition for detalhe mode, complementing annotations well.

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

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

The description is a single paragraph but well-organized: first general purpose, then mode details, then filtering advice, then sibling reference. It is concise yet informative; slight improvement could be bullet points.

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 complexity (6 params, 2 required, modes, limits, output schema), the description covers all essential aspects: purpose, mode behavior, filtering, truncation, and reference to related tool. It is complete for agent 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. The description adds context: explains modo enum meanings, default and max for limite, and that nome and tipoFolha support partial search. This adds 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 salary data for Senate employees for a given year/month. It specifies two modes (resumo and detalhe) with distinct output structures, and mentions a sibling tool for employee registration. The verb 'retorna' is explicit.

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 distinguishes when to use resumo vs detalhe, recommends filtering by nome or tipoFolha to avoid long lists, and references senado_servidores for cadastro. It provides clear context for optimal usage.

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

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

Annotations already indicate safe, read-only, idempotent behavior. Description adds return structure, pagination termination condition, and typical response fields, exceeding annotation basics.

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?

Concise, front-loaded with purpose, no wasted words. Every sentence adds necessary context for correct usage.

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 pagination complexity and need to discover siglas, description covers return structure, termination condition, and how to obtain valid siglas. Sufficient 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 covers 100% of parameters with descriptions. Description adds pagination behavior and example sigla values, enhancing understanding 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 requerimentos of a CPI by siglaCpi with pagination, and distinguishes from siblings by directing to use senado_listar_comissoes for CPI discovery.

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 find siglas via senado_listar_comissoes com tipo=cpi, explains pagination (0-based index, count=0 means end), and notes empty list for CPIs without requerimentos. Does not explicitly 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 indicate read-only, idempotent, open-world. Description adds crucial details: returns all sessions without pagination, items may have null fields if not yet deliberated, and empty result structure when no session exists. 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?

Well-structured with front-loaded purpose and alternative tools. Could be slightly more concise but every sentence adds value. No redundancy or 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 all relevant aspects: parameters, return structure, edge cases (null results, empty sessions), and relationships to sibling tools. Output schema exists but description goes beyond it by explaining the shape in natural language.

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 descriptions in schema are identical to those in the tool description. However, the description adds value by explaining the return structure that ties to parameters, e.g., escopo='mes' yields monthly summary. Slightly above baseline 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 tool returns session results for a given date, mentioning items, opinions, and outcomes. It distinguishes from sibling tools like senado_agenda_plenario and senado_orientacao_bancada, explicitly stating when to use them instead.

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 provides when-not guidance by naming alternative tools for pre-session agenda and bancada orientation. Also explains the escopo parameter variations for daily vs monthly scope, giving clear usage context.

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