Painel Sintético Concorde

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

With no annotations, the description fully carries behavioral disclosure. It explains that the tool does not receive the user question (no input), returns a rubric for local classification, and lists the bands with their meanings. It does not mention output format or side effects, but the behavior is well-articulated.

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

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

Description is a single concise paragraph with clear information: purpose, privacy, behavior, bands, and usage order. No unnecessary words, but could benefit from bullet-pointing the bands for faster parsing. Still 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 no output schema, the description adequately explains the return value (a rubric with specific bands). It tells the assistant to use the rubric to classify locally. However, it does not specify the exact format of the rubric (e.g., JSON or string), which might require agent inference. Nearly 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?

Input schema is empty (0 parameters). Baseline is 4 as per guidelines. The description adds context that the tool does not accept the question as input, which clarifies why there are no parameters. It explains the rubric's structure (bands) beyond what the schema conveys.

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: it provides a trust boundary rubric for classifying user questions locally, preserving privacy. It specifies the verb ('devolve a RUBRICA'), the resource ('classificação LOCAL'), and distinguishes itself from siblings like 'preparar_pesquisa' by being a prerequisite.

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 'Aplique antes de preparar_pesquisa', giving a direct when-to-use instruction. It also provides guidance on when not to use certain bands ('humano' band) and clarifies the local, private nature of the tool, helping the agent decide between this and tools that send data to a server.

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

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

No annotations are provided, so the description carries the full burden. It implies a read-only search operation but does not disclose behavioral traits like result ordering, pagination, or any side effects. This is adequate but not comprehensive.

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

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

The description is concise (one-sentence summary followed by modes) and front-loaded with the main purpose. However, the list of axes is lengthy and could potentially be moved to the schema enum for better 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?

Given the tool's simplicity (4 parameters, no output schema), the description covers the main functionality and modes. It lacks details on return format or limitations, but is sufficient for basic 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?

While schema coverage is 100%, the description adds value by enumerating the possible values for the 'eixo' parameter (e.g., por-classe, por-regiao), which is not present in the schema. This provides practical guidance beyond the schema's generic 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 searches 105 statistical facts and lists specific modes (free text, by axis, by persona_id). However, it does not explicitly differentiate from sibling tools like 'filtrar_personas' or 'get_personas', which could cause 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 clear context on when to use each mode (texto, eixo, persona_id), but lacks explicit guidance on when not to use this tool versus alternatives such as 'avaliar_pergunta' or 'get_personas'.

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

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

No annotations are provided, so the description must fully inform. It discloses that the tool returns count and mini-profiles up to a limit and is deterministic. Missing details include error handling for invalid DSL, rate limits, or authentication requirements.

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

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

Two sentences contain all necessary information: purpose, example, default behavior, and return format. No wasted words 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 no output schema, the description minimally states return values (count and mini-profiles). It is complete enough for a simple filter tool but could mention error behavior or DSL syntax 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 for both parameters. The description adds a concrete example for 'filtro', which enhances understanding beyond the schema definition. For 'limite', the description aligns with the schema, so no extra value, but the example compensates.

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 filters personas using a deterministic DSL, with an example. It distinguishes from siblings like 'get_personas' (which presumably retrieves unfiltered personas) but does not explicitly contrast with other sibling tools like 'sortear_amostra' or 'buscar_fatos'.

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 implies usage: when you need to filter personas by conditions. It provides an example and states that empty input returns all. However, it does not specify when not to use this tool or mention alternatives among 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?

No annotations are provided, so the description must disclose behavioral traits. It implies it lists files but does not state whether it is read-only, whether it requires authorization, or if there are side effects. The description is insufficient for safe agent behavior.

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 short and front-loads the key information. However, the use of Portuguese and fragmented phrasing reduces clarity. It is concise but could be more precise.

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

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

Given no output schema and no annotations, the description should explain the return format or behavior more thoroughly. It mentions listing files but not what the output looks like or how to interpret results. Adequate but incomplete.

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 parameter 'arquivo' with a description, but the description adds the critical hint that omitting the parameter will list all files ('Sem nome, lista os arquivos'). This adds 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 identifies the tool as relating to calibration tables of a panel, specifically distribution CSVs and fee records. It clearly states the resource types. However, the phrasing is fragmented and slightly confusing, missing a clear verb like 'get' or 'list'.

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 guidance on when to use this tool versus alternatives like get_instituicao or get_personas. The description does not specify context or prerequisites for invoking 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?

No annotations, so description carries full burden. It discloses return fields and behavior when no name is given. Does not mention side effects, authentication, or rate limits, but for a read-only query this is adequate.

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 main purpose. No wasted words. Efficient and informative.

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 1 parameter and no output schema, the description covers everything needed: what it does, what it returns, and behavior without input. 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% (1 parameter). Description adds value by clarifying that parameter is optional and what happens when omitted (lists available institutions). This goes beyond the schema's example values.

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

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

Description clearly states it returns a profile of a financial institution with specific attributes (cadastro, volumetria, reputação, reviews). It distinguishes from siblings by being specific to financial institutions and mentions the set of 12 banks. No sibling overlap.

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?

Implied usage: call with nome for a specific institution, without to list available ones. But no explicit when-to-use or when-not-to-use compared to sibling tools. Siblings are quite different, so context aids 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?

No annotations are provided, so the description carries full burden. It discloses crucial interpretation details about _composicao_ and _referencia_ facts, but does not mention non-destructive nature, rate limits, or authentication needs. The description adds value beyond annotations (which are absent) but is incomplete.

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 plus a critical note, all front-loaded. Every sentence adds value: main purpose, then interpretation guidance. No filler 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 a single parameter with full schema coverage, no output schema, and sibling context, the description adequately explains the tool's output (complete cards with attributes, grounding, history). However, lacking explicit return structure details keeps it from being 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% with the 'ids' parameter fully described in the schema (including example). The description does not add additional semantic meaning about the parameter beyond what the schema provides, hence 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 it retrieves complete persona cards by ID, listing attributes, grounding with facts/sources, and history. The verb 'get' and resource 'personas' are specific, and the mention of 'até 10 personas' distinguishes it from sibling tools like 'filtrar_personas' which filter lists.

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 implies use when full persona profiles are needed by ID, but lacks explicit when-not-to-use or alternative comparisons. The important note about interpreting facts provides context for correct usage, but no exclusions are stated.

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 no annotations, the description carries full burden. It discloses that data is real verbatim voices and non-population-representative, which is valuable. Lacks details on auth, rate limits, or data sources, but the core behavioral traits are well communicated.

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, highly efficient. First sentence states purpose and lists themes, second clarifies behavior and adds a caution. No fluff, 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?

No output schema, so description should indicate return format. It mentions 'vozes verbatim REAIS' and lists themes, but doesn't specify the structure of returned data (e.g., fields, pagination). Adequate for understanding purpose, but incomplete for full agent autonomy.

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: substring search for tema, default behavior listing all 17, and lists valid themes. This goes beyond the schema's descriptions, providing useful context for parameter usage.

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 verbatim voices (reviews, reports) by theme, with substring search on tema. It distinguishes from siblings by its specific focus on voice listing, and clarifies behavior without a tema.

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 (with or without tema) and gives a list of valid themes. It also warns about non-population representativeness, guiding appropriate use as illustration. However, no explicit guidance on when not to use or alternatives is given.

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 no annotations provided, the description fully discloses key behaviors: the user question is not sent to the server, aggregation is local, and the server does not store responses. It describes the workflow per persona. 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, dense paragraph of about 250 words, front-loaded with the core action. It is efficient with no wasted sentences, though a more structured format could improve scanability.

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 complex tool without an output schema, the description covers what is returned (packets per persona and protocol for host), privacy, format behaviors, and filtering. It is sufficient for an agent to understand the tool's purpose and invocation.

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

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

Schema coverage is 100%, so baseline is 3. The description adds high-level context but does not provide additional per-parameter details beyond the schema's own descriptions. It explains the overall workflow but not new semantic constraints.

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 prepares a fan-out research per persona, with strong privacy guarantees and specific format options. It distinguishes from siblings like 'sortear_amostra' by emphasizing the isolated, privacy-preserving workflow.

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 (privacy-sensitive fan-out research) and provides guidance on selecting formats (recommending 'pontuar' for robustness). It does not explicitly list exclusions or alternative tools, 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?

No annotations provided, so description carries full burden. It mentions the sample is random, uniform, and representative, which is behavioral. However, it does not state whether the tool is read-only, idempotent, or has side effects. For a sampling tool, mutability is unlikely, but not explicitly disclosed.

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 defines action, second adds representativeness context. No wasted words; front-loaded with core purpose. Very concise 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 no output schema, description could specify return format (e.g., list of persona IDs). It covers core purpose and representativeness. Missing: error handling (e.g., empty filter result). Otherwise complete for a simple sampling 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 has 100% coverage with descriptions for all 3 parameters. The description adds that the 'filtro' is optional and DSL-based, which matches schema. No additional parameter-specific insight beyond 'opcionalmente dentro de um filtro DSL.' Baseline of 3 is appropriate.

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

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

Description clearly states it draws a random sample of personas, optionally filtered by DSL. Verb 'sortear' and resource 'amostra de personas' are specific. Distinguishes from siblings like 'filtrar_personas' (filtering without sampling) and 'get_personas' (listing without randomness).

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

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

Description explains when to use: for a random sample that is representative due to uniform distribution. Does not explicitly state when not to use or compare to siblings, but sibling names imply alternatives. Clear context for 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?

No annotations are provided, so the description carries the full burden. It describes the tool as providing an overview and instructions, implying read-only behavior. However, it does not explicitly state safety (e.g., no side effects) or authentication requirements.

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

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

The description is a single, front-loaded sentence that conveys all necessary information without any wasted words. Every part is informative and earns its place.

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 and no output schema, the description fully covers the tool's purpose and content: what it is, what information it provides, and how to use other tools. It is complete for its role as an entry-point 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 tool has zero parameters and schema coverage is 100%. Since no parameters exist, the description does not need to add parameter details, and the baseline of 4 applies.

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's an overview of the dashboard, covering counts, fields, and tool usage. The phrase 'Chame primeiro' explicitly designates it as the entry point, distinguishing it from sibling tools that perform specific actions.

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 instruction 'Chame primeiro' provides clear guidance on when to use this tool (before any other). However, it does not specify when not to use it or what alternatives exist, but as an introductory tool, alternative usage is not expected.

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