Pharus MCP

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Tools are well-organized into distinct modules (catalog, grafo, kyt, rif_analytics, simba, telefonica, telematica), with clear separation of purposes within each module. Some minor overlap exists within modules (e.g., multiple list tools for telefonica files), but descriptions clarify specific contexts like 'by_case' vs 'by_file'.
Naming Consistency5/5
Tool names follow a highly consistent snake_case pattern with a clear module_action_resource structure (e.g., grafo_list_algorithms, telefonica_analytics_calls_by_case). This predictability makes it easy for agents to understand and navigate the toolset across all 63 tools.
Tool Count2/5
With 63 tools, the count is excessive for a single server, making it overwhelming for agents to manage. While the tools cover multiple investigative domains, such a large number suggests poor scoping and could lead to confusion or inefficiency in tool selection.
Completeness4/5
The toolset provides comprehensive coverage for investigative analysis across multiple data sources (e.g., graphs, telecom, financial), with CRUD-like operations for listing, describing, and analyzing. Minor gaps may exist in update/delete operations, but the surface supports core investigative workflows effectively.
Average 2.8/5 across 63 of 63 tools scored. Lowest: 1.7/5.
See the Tool Scores section below for per-tool breakdowns.
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only states what the tool does at a high level ('describes') without revealing any behavioral traits such as whether it's a read-only operation, what format the output takes, potential errors, or performance considerations. For a tool with no annotation coverage, this minimal description fails to provide necessary context for safe and effective use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Portuguese that directly states the tool's function without unnecessary words. It's appropriately front-loaded with the core action. However, while concise, it's under-specified—the brevity comes at the cost of missing important details that would help an agent use the tool correctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter with 0% schema coverage, no annotations, but does have an output schema, the description is incomplete. While the output schema may document return values, the description fails to address parameter semantics, usage context, or behavioral aspects. For a tool that presumably provides descriptive information about algorithm families, more guidance is needed to make it usable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'familia' with 0% description coverage (no schema description), and the tool description provides no information about parameters. The description doesn't explain what 'familia' represents, valid values, or how to specify it. With low schema coverage and no compensatory details in the description, parameter understanding is severely lacking.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Descreve uma familia de algoritmos do modulo de grafos' is a tautology that essentially restates the tool name 'grafo_describe_algorithm_family' in Portuguese. It specifies the verb 'descreve' (describes) and resource 'familia de algoritmos' (algorithm family) but lacks specificity about what information is provided or how it differs from siblings like 'grafo_describe_algorithm' or 'grafo_list_algorithm_families'. The purpose is clear but overly vague and doesn't distinguish from related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context, or comparisons to sibling tools such as 'grafo_list_algorithm_families' (which might list families) or 'grafo_describe_algorithm' (which might describe individual algorithms). Without any usage instructions, the agent has no basis for selecting this tool appropriately in different scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only mentions querying in 'full or lite' mode without explaining what these modes entail, what data is returned, whether this is a read-only operation, authentication requirements, rate limits, or error conditions. This leaves critical behavioral aspects undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Portuguese that directly states the tool's function. It's appropriately brief and front-loaded with the core action. However, it could be slightly more structured by separating the mode explanation for better clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters with 0% schema coverage, no annotations, and an output schema (which reduces the need to describe return values), the description is incomplete. It doesn't adequately explain parameter usage, behavioral traits, or differentiation from siblings. For a query tool with multiple parameters and sibling alternatives, this leaves significant gaps in understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate for the lack of parameter documentation. It mentions 'telefone' (phone) and 'modo' (mode) but doesn't explain the format expected for phone numbers (e.g., international format, array handling) or what 'full' and 'lite' modes mean. The description adds minimal semantic value beyond what's inferable from parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'Consulta a API KYT por telefone' (queries the KYT API by phone), which provides a basic verb+resource combination. However, it's vague about what 'KYT' represents and doesn't distinguish this tool from sibling tools like 'kyt_get_by_document' or 'kyt_get_by_email' beyond the phone parameter. The mention of 'full ou lite' modes adds some specificity but doesn't fully clarify the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'kyt_get_by_document' or 'kyt_get_by_email'. The description mentions 'full ou lite' modes but doesn't explain when to choose one over the other or what distinguishes them. There's no mention of prerequisites, limitations, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description provides no information about whether this is a read-only operation, what permissions are required, whether there are rate limits, what format the output takes, or any other behavioral characteristics. It's a bare minimum statement of function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single sentence that gets straight to the point. There's no wasted language or unnecessary elaboration. However, it could benefit from being slightly more informative while maintaining efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a tool with one required parameter, no annotations, and an output schema (which helps), the description is insufficient. It doesn't explain what kind of files are being listed, what the output contains, or provide any context about the Telefonica data source. For a tool in a complex environment with many sibling tools, more context would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate for the lack of parameter documentation. The description mentions 'por src_id' which indicates the parameter's purpose, but doesn't explain what src_id represents, what format it should be in, or provide any examples. This leaves significant ambiguity about the single required parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('Lista arquivos') and resource ('da Telefonica'), but it's vague about what 'arquivos' specifically means in this context (e.g., call records, messages, documents). It distinguishes from siblings by specifying 'por src_id', but doesn't clearly differentiate from other Telefonica list tools like telefonica_list_antennas or telefonica_list_messages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There's no mention of prerequisites, when this tool is appropriate, or what other tools might be better for different scenarios. The description only states what it does, not when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool lists data, implying a read-only operation, but doesn't clarify if it's paginated (though parameters suggest it), what the output format is (though an output schema exists), or any rate limits or authentication requirements. For a tool with 4 parameters and no annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Portuguese that directly states the tool's function. It's appropriately sized for a basic listing tool, with no redundant or verbose language. However, it could be more front-loaded with key details, but it's concise overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, 2 required, no annotations, but with an output schema), the description is incomplete. It doesn't explain parameter semantics, usage context, or behavioral traits beyond a vague listing action. The output schema helps with return values, but the description should add more context about the data source and tool behavior to be fully adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning parameter titles like 'Src Id' and 'Identificador' are not explained in the schema. The description adds no information about what these parameters mean (e.g., 'src_id' might refer to a file identifier, 'identificador' could be an antenna ID), their expected formats, or how pagination works. With 4 parameters and no schema descriptions, the description fails to compensate, leaving parameters largely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'Lista dados de antena de um arquivo da Telefonica' (Lists antenna data from a Telefonica file), which provides a basic verb+resource combination. However, it's vague about what 'dados de antena' specifically entails and doesn't distinguish this tool from sibling tools like 'telefonica_analytics_phones_by_antenna' or 'telefonica_list_connections', which also deal with Telefonica data. The purpose is understandable but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a specific file type), exclusions, or compare it to sibling tools like 'telefonica_list_files' or 'telefonica_analytics_phones_by_antenna'. Without such context, an agent must infer usage from the tool name and parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only states what the tool does at a high level ('Lista registros de voz') without any information about permissions needed, rate limits, pagination behavior (despite pagination parameters in the schema), response format, or any other behavioral characteristics. This is inadequate for a tool with multiple parameters and no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core purpose without unnecessary words. It's appropriately sized for a basic listing tool, though it could benefit from being more informative given the lack of other documentation. The structure is straightforward and front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While there is an output schema (which reduces the need to describe return values), the description is incomplete for a tool with 4 parameters, no annotations, and 0% schema description coverage. It doesn't explain what the tool actually returns (beyond 'voice records'), doesn't address behavioral aspects, and provides no parameter guidance. Given the complexity and lack of supporting documentation, this description is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 4 parameters have descriptions in the schema. The description provides no information about any parameters - it doesn't explain what 'src_id' or 'identificador' represent, nor does it mention the pagination parameters. With 0% schema coverage and no parameter information in the description, this fails to provide basic parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Lista' - list) and resource ('registros de voz de um arquivo da Telefonica' - voice records from a Telefonica file). It's specific about what's being listed (voice records) and from where (a Telefonica file). However, it doesn't explicitly differentiate from sibling tools like 'telefonica_list_messages' or 'telefonica_list_connections', which would be needed for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools (including other 'telefonica_list_' tools), there's no indication of what distinguishes this tool from others that list different types of Telefonica data. No prerequisites, exclusions, or alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states this is a list operation, implying read-only behavior, but doesn't mention pagination details (implied by parameters), rate limits, authentication requirements, or what the output contains. For a tool with 3 parameters and no annotations, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Portuguese that directly states the tool's purpose. It's appropriately concise and front-loaded, though it could benefit from additional context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters (1 required), 0% schema coverage, no annotations, and an output schema exists, the description is incomplete. It doesn't explain what 'contatos' or 'registros' mean, how pagination works, or provide any context beyond the basic action. The output schema helps, but the description should do more for a tool with undocumented parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The tool description doesn't mention any parameters, leaving all 3 (registro_ids, pagina, itens_por_pagina) completely undocumented. This fails to compensate for the schema gap, making parameter understanding difficult.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Lista contatos de registros da Telematica' clearly states the action (list) and resource (contacts from Telematica records), but it's vague about scope and doesn't differentiate from sibling tools like 'telematica_list_connections' or 'telematica_list_emails'. It doesn't specify what kind of contacts or what 'registros' means in this context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'telematica_list_connections' or 'telematica_list_emails'. The description doesn't mention prerequisites, context, or exclusions, leaving the agent to guess based on the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states this is a list operation, implying it's likely read-only and non-destructive, but it doesn't confirm this or describe other behaviors such as pagination handling (implied by parameters), rate limits, authentication needs, or error conditions. For a tool with no annotations, this leaves significant gaps in understanding how it behaves beyond basic listing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence in Portuguese that directly states the tool's purpose. It's front-loaded with no unnecessary words, making it efficient to parse. However, it could be slightly improved by adding more context without losing conciseness, but it's well-structured for its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which likely describes return values), the description doesn't need to explain outputs. However, with no annotations, 4 parameters at 0% schema coverage, and a list operation that may involve pagination and filtering, the description is incomplete—it lacks details on behavior, parameter usage, and differentiation from siblings. It's minimally adequate but has clear gaps for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no descriptions for the 4 parameters. The description adds minimal semantics by mentioning 'por caso ou criador,' which hints at the purpose of 'caso_id' and 'criado_por_id' parameters, but it doesn't explain 'pagina' or 'itens_por_pagina' (page and items per page) or provide details on parameter usage, formats, or constraints. This insufficiently compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Lista grafos do modulo de grafo por caso ou criador' clearly states the action (list) and resource (graphs from the graph module), but it's vague about what 'grafos' specifically refers to (e.g., graph objects, visualizations, data structures) and doesn't distinguish this tool from sibling tools like 'grafo_get_graph' or 'grafo_list_labels', which might have overlapping purposes. It provides a basic purpose but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions filtering 'por caso ou criador' (by case or creator), implying usage based on these parameters, but it doesn't provide explicit guidance on when to use this tool versus alternatives like 'grafo_get_graph' for retrieving a single graph or other list tools in the server. There's no mention of prerequisites, exclusions, or specific scenarios, leaving the agent with minimal context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions two modes ('full' and 'lite') but doesn't explain what these modes entail (e.g., different data detail levels, performance implications, or access restrictions). It doesn't address whether this is a read-only operation, potential rate limits, authentication requirements, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Portuguese. It's appropriately brief and front-loads the core functionality. However, it could be more structured by separating the purpose from the mode explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which reduces the need to describe return values) but zero schema description coverage and no annotations, the description is moderately incomplete. It covers the basic purpose and mentions two modes, but lacks details on parameter semantics, behavioral traits, and differentiation from siblings, making it adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description mentions 'documentos' and 'modo' but doesn't explain what constitutes valid documents (e.g., document types, formats) or what 'full' versus 'lite' modes mean in practice. It adds minimal semantic value beyond what's inferred from parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'consulta a API KYT por documentos' (queries the KYT API by documents), which provides a basic verb+resource combination. However, it's vague about what 'KYT' represents and what kind of data is returned. It doesn't clearly distinguish this tool from sibling tools like 'kyt_get_by_email' or 'kyt_get_by_phone' beyond the input type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'em modo full ou lite' (in full or lite mode), which provides some context about usage options, but offers no guidance on when to use this tool versus alternatives like 'kyt_get_by_email' or 'kyt_get_by_phone'. There's no mention of prerequisites, typical use cases, or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'full ou lite' modes, suggesting different levels of data detail, but doesn't explain what these modes entail (e.g., response format, data fields, performance implications). It lacks information on authentication needs, rate limits, error handling, or what the tool returns. The description adds some context but is insufficient for a mutation/query tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Portuguese that states the core action and key parameter options. It's appropriately sized and front-loaded with the main purpose, though it could be more structured by separating usage details. There's no wasted verbiage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which reduces the need to describe return values), but no annotations and low schema coverage, the description is incomplete. It covers the basic purpose and hints at modes, but lacks details on behavior, parameter meanings, and differentiation from siblings. For a query tool with 2 parameters and no annotations, this is a minimal viable description with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description mentions 'email' and 'modo full ou lite', which loosely maps to the 'emails' array and 'modo' string parameters, but it doesn't clarify parameter semantics (e.g., email format, what 'full'/'lite' mean, default behavior). It adds minimal value beyond the schema's structure, failing to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'consulta a API KYT por email' (queries the KYT API by email), which provides a basic verb+resource combination. However, it doesn't specify what KYT is or what kind of data is returned, and it doesn't clearly differentiate from sibling tools like 'kyt_get_by_document' or 'kyt_get_by_phone' beyond the input parameter difference. The purpose is vague but not tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'em modo full ou lite' (in full or lite mode), which implies there are two usage modes, but it provides no guidance on when to choose one mode over the other, when to use this tool versus alternatives like 'kyt_get_by_document', or any prerequisites. There's minimal context but no explicit usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool returns a summary, which suggests a read-only operation, but doesn't clarify aspects like authentication needs, rate limits, error handling, or what 'consolidado' entails (e.g., aggregated data, format). The description is too vague to fully inform an agent about behavioral traits beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's appropriately sized for a simple tool, though it could be more front-loaded with key details. There's no wasted text, making it concise, but it lacks structural elements like bullet points or examples that might enhance clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values), 3 parameters with 0% schema coverage, and no annotations, the description is minimally adequate. It covers the basic purpose but misses details on parameter usage, behavioral context, and differentiation from siblings. For a tool with undocumented inputs, it should do more to compensate, but the output schema reduces the burden slightly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It mentions 'uma origem' (a source), which loosely relates to 'src_id', but doesn't explain the meaning of 'src_id', 'data_inicio', or 'data_fim' (e.g., date formats, optionality, or how they affect the summary). With 3 parameters and no schema descriptions, the description adds minimal semantic value beyond implying a source is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Retorna um resumo consolidado dos indicadores analiticos de uma origem' clearly states it returns a consolidated summary of analytical indicators for a source, providing a specific verb ('retorna') and resource ('indicadores analiticos'). However, it doesn't distinguish this from sibling tools like 'rif_analytics_list_maiores_transacoes' or 'rif_analytics_list_funcoes_por_envolvido', which also appear to be analytics tools. The purpose is understandable but lacks differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, exclusions, or comparisons to sibling tools. While it implies usage for summary analytics, there's no explicit context to help an agent choose between this and other analytics tools in the list, such as those for listing transactions or functions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a listing operation, which implies read-only behavior, but doesn't address authentication requirements, rate limits, pagination, error conditions, or what format the output takes. The description is too minimal to provide adequate behavioral context for a tool with an output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single Portuguese sentence. While this is efficient, it may be too brief for a tool with 1 parameter and an output schema. There's no wasted language, but it might benefit from slightly more detail given the lack of annotations and schema descriptions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there's an output schema (which handles return values), no annotations, and only 1 parameter with 0% schema coverage, the description is minimally complete. It identifies the tool's basic purpose but leaves significant gaps in parameter understanding, usage context, and behavioral expectations that the agent would need to operate effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the undocumented parameter. The description mentions 'por pessoa' which relates to the 'cpf_cnpj' parameter, but doesn't explain what CPF/CNPJ is, what format it expects, or provide any examples. The description adds minimal semantic value beyond what's implied by the parameter name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Lista contas do SIMBA por pessoa' clearly states the action (list) and resource (SIMBA accounts), but it's vague about scope and doesn't differentiate from the sibling tool 'simba_list_accounts'. It doesn't specify what 'por pessoa' means in practice or how this differs from the general list tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. The description doesn't mention the sibling 'simba_list_accounts' tool or explain why someone would choose this person-specific listing over the general one. There's no context about prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a read operation ('retorna'), but doesn't describe what 'consolidated statistics' includes, potential rate limits, authentication requirements, error conditions, or response format. The description is insufficient for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point. There's no wasted language or unnecessary elaboration. However, it could be more front-loaded with critical information about what 'consolidated statistics' actually means.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description doesn't need to explain return values. However, for a tool with 2 required parameters, 0% schema description coverage, and no annotations, the description should provide more context about parameter usage and what 'consolidated statistics' entails. It's minimally adequate but leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter documentation. The description mentions both parameters ('src_id' and 'numero_telefone') but doesn't explain their meaning, format requirements, or how they interact. It adds minimal semantic value beyond what's already implied by the parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'retorna estatisticas consolidadas de ligacoes para um numero por src_id' (returns consolidated call statistics for a number by src_id), which provides a basic verb+resource combination. However, it's vague about what 'consolidated statistics' specifically means and doesn't clearly differentiate from sibling tools like 'telefonica_analytics_call_stats_by_file' or 'telefonica_analytics_calls_by_case'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, appropriate contexts, or compare it to similar sibling tools. The agent must infer usage solely from the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states it's a listing operation, implying read-only behavior, but doesn't disclose critical details like authentication needs, rate limits, pagination, or what the output contains. For a tool with no annotations, this is insufficient to guide safe and effective use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Portuguese that directly states the tool's function. It's front-loaded with the core action and resource, with no wasted words, making it appropriately concise for its purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 parameters with 0% schema coverage, no annotations, but an output schema exists, the description is minimally adequate. It covers the basic purpose but lacks details on parameters, behavioral traits, and usage context. The output schema mitigates some completeness gaps, but overall, it's borderline for a tool in this context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description mentions 'por src_id' and 'de um numero', hinting at the parameters 'src_id' and 'numero_telefone', but it doesn't explain their semantics, formats, or constraints. This adds minimal value beyond the schema's structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Lista conexoes de dados moveis de um numero por src_id' clearly states the action ('Lista') and resource ('conexoes de dados moveis'), but it's vague about scope and doesn't differentiate from sibling tools like 'telefonica_list_connections' or 'telematica_analytics_connections_by_device'. It specifies 'de um numero por src_id', which adds some context but remains general.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives is provided. The description implies usage for listing mobile data connections for a phone number by src_id, but it doesn't specify prerequisites, exclusions, or compare to similar tools in the sibling list, leaving the agent without clear selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions listing a timeline, implying a read-only operation, but doesn't disclose behavioral traits such as whether it requires specific permissions, rate limits, pagination, or what the output format looks like. The description is too brief to provide meaningful context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence in Portuguese that directly states the tool's function. It's front-loaded with the core action, though it could be more structured by including parameter hints or usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there's an output schema (which reduces the need to describe return values) but no annotations and 0% schema coverage for parameters, the description is incomplete. It covers the basic purpose but lacks details on parameters, usage, and behavioral context, making it only minimally adequate for a tool with two required parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The tool description doesn't mention any parameters or their semantics (e.g., what 'src_id' and 'numero_telefone' represent). This leaves both parameters undocumented, failing to compensate for the lack of schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool lists a timeline of locations by number for voice and connections, which provides a basic purpose. However, it's somewhat vague about what 'timeline of locations' means and doesn't differentiate from sibling tools like 'telefonica_analytics_connections_by_number' or 'telefonica_analytics_phones_by_antenna' that also deal with phone number analytics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description mentions 'voz + conexoes' (voice + connections), but it doesn't specify if this is for historical tracking, real-time data, or how it differs from other telefonica_analytics tools that also handle phone numbers and connections.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action (list) without detailing traits like whether it's read-only, paginated (implied by parameters but not described), rate limits, authentication needs, or output format. This leaves significant gaps for a tool with 4 parameters and potential data retrieval complexity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Portuguese that directly states the tool's function without unnecessary words. It's front-loaded with the core action, though it could be more structured by including key details. It earns its place but is slightly under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, no annotations, but with an output schema), the description is minimally adequate. The output schema may cover return values, reducing the need for output details in the description. However, it lacks crucial context like parameter explanations and behavioral traits, making it incomplete for effective use without additional documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter details. The description adds no information about parameters like 'src_id', 'identificador', 'pagina', or 'itens_por_pagina', failing to explain their meanings, formats, or how they interact. This leaves all 4 parameters undocumented, which is inadequate given the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Lista mensagens de um arquivo da Telefonica' clearly states the action (list) and resource (messages from a Telefonica file), but it's vague about what 'mensagens' specifically refers to (e.g., SMS, call logs, metadata) and doesn't differentiate from sibling tools like 'telefonica_list_voice' or 'telefonica_list_connections'. It provides a basic purpose but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, context, or exclusions, such as how it relates to other 'telefonica_list_' tools or when to choose it over analytics-focused siblings. Usage is implied by the name alone, with no explicit instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Lista' (List), implying a read-only operation, but doesn't disclose behavioral traits such as pagination behavior (hinted by 'pagina' and 'itens_por_pagina' parameters), rate limits, authentication needs, or what the output contains. The description is minimal and lacks essential operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Portuguese, front-loaded with the core action. There's no wasted verbiage, but it's overly terse, bordering on under-specification rather than optimal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters (2 required) with 0% schema coverage and no annotations, but an output schema exists, the description is incomplete. It doesn't compensate for the lack of parameter documentation or behavioral details, though the output schema may cover return values. For a list tool with pagination, more context is needed to be fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description doesn't add any meaning to parameters like 'src_id', 'identificador', 'pagina', or 'itens_por_pagina'. It fails to explain what these inputs represent (e.g., file identifier, page number), leaving parameters undocumented and unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Lista eventos de portabilidade de um arquivo da Telefonica' which translates to 'List portability events of a Telefonica file.' This provides a clear verb ('List') and resource ('portability events'), but it doesn't differentiate from sibling tools like 'telefonica_analytics_portability_by_number' or specify what 'portability events' entail (e.g., phone number transfers). It's adequate but vague on scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., needing a specific file type), exclusions, or comparisons to sibling tools like 'telefonica_analytics_portability_by_number' or 'telefonica_list_files.' This leaves the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states this is a listing operation, implying it's likely read-only, but doesn't disclose behavioral traits such as authentication requirements, rate limits, pagination behavior (implied by parameters but not described), or what happens if the file doesn't exist. The description is minimal and lacks crucial operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Portuguese that directly states the tool's function. It's front-loaded with the core action and target, with no unnecessary words. However, it could be slightly more specific without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which reduces the need to describe return values), 4 parameters with 0% schema coverage, and no annotations, the description is incomplete. It covers the basic purpose but fails to compensate for the lack of parameter documentation and behavioral context, making it inadequate for safe and effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 4 parameters have descriptions in the schema. The description doesn't add any meaning to parameters like 'src_id' or 'identificador'—it doesn't explain what these identifiers refer to, their format, or how they relate to the Telefonica file. It also doesn't clarify the purpose of pagination parameters, leaving them undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Lista dados suplementares de um arquivo da Telefonica' clearly states the action (list) and target (supplemental data from a Telefonica file), but it's somewhat vague about what 'supplemental data' specifically entails. It doesn't differentiate from sibling tools like 'telefonica_list_files' or 'telefonica_get_file', which might handle different aspects of Telefonica files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools related to Telefonica data (e.g., 'telefonica_list_files', 'telefonica_get_file', 'telefonica_list_connections'), there's no indication of how this tool fits into the workflow or what makes it distinct for accessing supplemental data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states what the tool returns, not how it behaves - no information about permissions required, rate limits, whether it's read-only or mutative, response format, or error conditions. For a tool with analytics functionality, this leaves significant gaps in understanding its operational characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently states the core function. There's no wasted verbiage or unnecessary elaboration. However, while concise, it's under-specified rather than optimally informative, which slightly reduces its effectiveness despite the clean structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which should document return values) and only one parameter, the description's minimalism is somewhat acceptable. However, for an analytics tool with no annotations and zero schema description coverage, the description should provide more context about what 'analytical metrics' encompasses and how the source_id parameter works to be truly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, providing only a parameter name 'source_id' with no explanation. The description mentions 'by source_id' but adds no semantic meaning - it doesn't explain what a source_id represents, valid formats, examples, or how it relates to the analytics being returned. With low schema coverage, the description fails to compensate adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'returns analytical metrics from Telematica by source_id', which provides a basic verb+resource combination. However, it's vague about what specific metrics are returned and doesn't differentiate from sibling tools like 'telematica_analytics_by_account' or 'telematica_analytics_connections_by_device' that also return Telematica analytics but with different parameters or scopes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. The description doesn't mention prerequisites, appropriate contexts, or compare it to sibling tools that might serve similar purposes with different parameters (e.g., 'telematica_analytics_by_account'). The agent must infer usage from the parameter name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions verification and symmetry checking, but doesn't describe what the tool actually does operationally—such as whether it performs read-only checks, requires specific permissions, has rate limits, or what 'simetria' entails. For a tool with no annotations, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence in Portuguese that directly states the tool's function. It is front-loaded with the main action ('Verifica'), and there is no wasted verbiage. However, it could be more structured by clarifying terms like 'simetria'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is an output schema (which should cover return values), the description's main gaps are in parameter semantics and behavioral transparency. The description is minimally adequate for understanding the tool's purpose but fails to compensate for the lack of annotations and 0% schema coverage, leaving key operational details unclear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the three parameters (source_id, identificador_conta, numeros) have descriptions in the schema. The tool description does not add any semantic information about these parameters—it doesn't explain what they represent, their formats, or how they relate to the verification process. This leaves all parameters undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose as verifying if provided numbers are account contacts and checking for symmetry, which is clear but somewhat vague. It uses specific verbs ('verifica') but doesn't fully distinguish from sibling tools like 'telematica_list_contacts' or 'telematica_analytics_contacts_by_city', which might have overlapping functionality. The purpose is understandable but lacks precision about what 'simetria' (symmetry) means in this context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools in the 'telematica' and related categories (e.g., 'telematica_list_contacts', 'telematica_analytics_contacts_by_city'), there is no indication of context, prerequisites, or exclusions. This leaves the agent without direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states this is a list operation, implying it's likely read-only and non-destructive, but doesn't confirm this or provide any additional behavioral context such as permissions needed, rate limits, pagination behavior (implied by parameters but not described), or what the output contains. This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, straightforward sentence in Portuguese that efficiently states the tool's purpose without unnecessary words. It's appropriately sized for a basic listing tool, though it could be more informative without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there's an output schema (which should document return values), the description's main job is to clarify purpose and usage. It minimally states what the tool does but lacks guidance on when to use it, parameter meanings, and behavioral context. For a tool with 3 parameters (one required) and no annotations, this leaves significant gaps, making it barely adequate but with clear room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the three parameters have descriptions in the schema. The tool description adds no information about what 'registro_ids', 'pagina', or 'itens_por_pagina' mean, their expected formats, or how they affect the listing. This leaves parameters completely undocumented, failing to compensate for the schema's lack of coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Lista conexoes de registros da Telematica' clearly states the action (list) and target (connections of Telematica records), which is adequate. However, it doesn't specify what 'conexoes' means in this context or differentiate from sibling tools like 'telematica_list_contacts' or 'telematica_list_devices', leaving some ambiguity about the exact resource being listed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools like 'telematica_list_contacts' and 'telematica_list_devices' that also list Telematica data, there's no indication of what makes this tool unique or when it's the appropriate choice, leaving the agent to guess based on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only states the listing action without mentioning pagination behavior (implied by parameters), rate limits, authentication requirements, or what constitutes a 'device' in this context. For a tool with parameters and no annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Portuguese that directly states the tool's function without unnecessary words. While it could be more informative, it's appropriately concise and front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which reduces need to describe return values) but no annotations and poor parameter documentation, the description is minimally adequate. It identifies the domain and action but lacks sufficient context about behavior, parameter usage, and differentiation from siblings to be fully helpful for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for all 3 parameters, the description provides no information about parameter meanings or usage. It doesn't explain what 'registro_ids' represents, how pagination works, or the relationship between parameters. The description fails to compensate for the complete lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Lista dispositivos de registros da Telematica' clearly states the action (list) and resource (devices from Telematica records), providing a basic purpose. However, it doesn't differentiate from sibling tools like 'telematica_list_connections' or 'telematica_list_contacts', leaving ambiguity about what specifically distinguishes this device listing from other list operations in the same domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With multiple sibling tools in the Telematica domain (e.g., telematica_list_connections, telematica_list_contacts), there's no indication of context, prerequisites, or exclusions to help an agent choose appropriately among similar listing functions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only states it lists groups, offering no information about permissions required, rate limits, pagination behavior (despite pagination parameters in the schema), or what the output contains. For a tool with 3 parameters and no annotation coverage, this is a significant gap in behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Portuguese that directly states the tool's purpose. It's appropriately sized for a basic listing tool, with no wasted words. However, it could be more front-loaded with additional context, but as-is, it's concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which reduces the need to describe return values in the description), but with no annotations, 3 parameters at 0% schema coverage, and multiple sibling tools, the description is minimally adequate. It states the basic purpose but lacks details on usage, parameters, and behavioral traits, making it incomplete for effective agent use without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 3 parameters have descriptions in the schema. The description adds no information about parameters, failing to explain what 'registro_ids' are, how pagination works, or the purpose of 'itens_por_pagina'. With low schema coverage, the description does not compensate, leaving parameters largely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Lista grupos de registros da Telematica' clearly states the action (list) and resource (groups of records from Telematica), but it's somewhat vague about what 'groups' specifically means and doesn't differentiate from sibling tools like telematica_list_records or telematica_list_connections. It provides basic purpose but lacks specificity about the nature of these groups.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools in the Telematica domain (e.g., telematica_list_records, telematica_list_contacts), there's no indication of how this tool differs or when it's appropriate. Usage is implied only by the name and description, with no explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'describe[s]' a service, which implies a read-only operation, but doesn't specify if it's safe, requires authentication, has rate limits, or what the output entails (e.g., structured data or text). The description lacks behavioral traits beyond the basic action, leaving significant gaps for an agent to understand how to invoke it effectively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Portuguese that directly states the tool's purpose without unnecessary words. It's appropriately sized for a simple tool, though it could be more front-loaded with key details (e.g., output type). There's no wasted text, making it concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter) and the presence of an output schema (which likely defines return values), the description is minimally complete. However, with no annotations and low schema coverage, it should do more to explain behavioral aspects and parameter usage. It's adequate for a basic read operation but lacks depth for full contextual understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter ('service') with 0% description coverage, meaning the schema provides no details about this parameter. The description adds minimal semantics by implying 'service' refers to a 'servico investigativo especifico' (specific investigative service), but doesn't clarify format (e.g., string ID, name), source (e.g., from 'catalog_list_services'), or examples. With low schema coverage, the description compensates slightly but inadequately, warranting a baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'Describe[s] um servico investigativo especifico do catalogo do Pharus' which translates to 'Describe a specific investigative service from the Pharus catalog.' This provides a clear verb ('describe') and resource ('service'), but it's somewhat vague about what 'describe' entails (e.g., returns metadata, details, or documentation) and doesn't explicitly differentiate from siblings like 'catalog_list_services' beyond the singular vs. plural focus. It avoids tautology but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing to know a service name from 'catalog_list_services'), exclusions, or comparisons to other tools. Usage is implied by the name and description alone, with no explicit context or alternatives provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only states what the tool does ('describes') but doesn't reveal any behavioral traits - whether this is a read-only operation, what format the description returns, whether it requires specific permissions, or any rate limits. For a tool with zero annotation coverage, this minimal description is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single sentence in Portuguese that directly states the tool's function. There's no wasted language or unnecessary elaboration. While it's under-specified in terms of content, what's present is efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema (which reduces the need to describe return values in the description), but with 2 undocumented parameters, no annotations, and multiple similar sibling tools, the description is incomplete. It provides the basic purpose but misses crucial context about parameter usage, behavioral characteristics, and differentiation from alternatives. The existence of an output schema prevents this from being a complete failure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning neither parameter has any description in the schema. The tool description provides no information about the 'familia' and 'algoritmo' parameters - what they represent, what values they accept, or their relationship. With 2 required parameters and zero schema documentation, the description fails to compensate for this significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'describes a specific algorithm from the graph module' which provides a basic purpose (verb+resource). However, it doesn't distinguish this tool from sibling tools like 'grafo_describe_algorithm_family' or 'grafo_get_algorithm_help' - it's unclear what differentiates 'describe' from 'get help' or 'describe family'. The purpose is clear but lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With multiple sibling tools in the 'grafo' family (describe_algorithm_family, get_algorithm_help, list_algorithms, suggest_algorithms_for_graph), there's no indication of when this specific describe_algorithm tool is appropriate versus those other options. No usage context or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that help is returned 'when available', hinting at conditional behavior, but fails to detail what happens if unavailable (e.g., error handling), permissions required, or rate limits. For a tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. It avoids unnecessary words, though it could be slightly more structured by explicitly stating the parameter or usage context. Overall, it's appropriately sized for its content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which likely covers return values), the description's main gap is in behavioral transparency and parameter guidance. With no annotations and low schema coverage, it partially compensates by stating the format ('markdown') and conditionality ('when available'), but falls short of being fully complete for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention the parameter 'enum_name', and schema description coverage is 0%, so it adds no meaning beyond the schema. However, with only one parameter, the baseline is 4, but the description's lack of parameter context reduces it to 3, as it doesn't clarify what 'enum_name' refers to or provide examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'returns help in markdown for an enum of algorithms from grafo-back, when available', which specifies the verb ('returns help'), resource ('enum of algorithms'), and format ('markdown'). However, it doesn't clearly differentiate from sibling tools like 'grafo_describe_algorithm' or 'grafo_list_algorithm_enums', leaving the exact scope ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives. The description mentions 'when available', which implies conditional availability but doesn't specify prerequisites, contexts, or comparisons to siblings like 'grafo_describe_algorithm'. This lack of direction leaves usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states it lists configured KYT layers. It doesn't disclose behavioral traits like whether this is a read-only operation (implied by 'list'), pagination behavior (though schema hints at it), rate limits, authentication needs, or what 'configured' entails. The description is minimal and lacks essential operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's appropriately sized for a simple list operation and front-loaded with the core purpose. Every word contributes directly to stating what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which should document return values), the description's minimalism is somewhat acceptable. However, for a tool with 3 parameters and no annotations, the description is too sparse—it doesn't explain parameter use, filtering logic, or behavioral context. It meets a bare minimum but leaves significant gaps in understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description adds no information about the three parameters (eh_ativo, pagina, itens_por_pagina), leaving their semantics completely undocumented. It fails to compensate for the schema's lack of coverage, making parameter understanding reliant on inference from titles alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Lista camadas KYT configuradas no modulo de grafo' clearly states the action (list) and resource (KYT layers in graph module), but it's somewhat vague about what 'KYT layers' specifically are and doesn't differentiate from sibling tools like 'grafo_list_kyt_relationships' or 'grafo_list_labels'. It provides basic purpose but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There's no mention of prerequisites, context for filtering, or comparison to sibling tools like 'grafo_list_kyt_relationships'. The description only states what it does, not when it's appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only states what the tool does ('Lista movimentacoes') without any information about permissions required, rate limits, pagination, what format the movements are returned in, or any other behavioral characteristics. This is inadequate for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Portuguese that directly states the tool's purpose. There's no wasted language or unnecessary elaboration. It's appropriately sized for what it communicates.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema (which reduces the need to describe return values in the description) and only 2 required parameters. However, with 0% schema description coverage and no annotations, the description should do more to compensate - particularly explaining parameter formats and behavioral characteristics. It's minimally adequate but leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning neither parameter has any description in the schema. The description mentions 'por pessoa e identificador de arquivo' which hints that parameters relate to person and file identifier, but doesn't specify which parameter corresponds to which concept, what format they expect (CPF/CNPJ format for person?), or provide any meaningful semantic context beyond the minimal hint.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Lista' - List) and resource ('movimentacoes do SIMBA' - SIMBA movements) with filtering criteria ('por pessoa e identificador de arquivo' - by person and file identifier). It's specific about what the tool does, though it doesn't explicitly distinguish from sibling tools like 'simba_list_movements_by_src' or 'simba_list_accounts_by_person'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are multiple sibling tools for listing SIMBA data (e.g., 'simba_list_movements_by_src', 'simba_list_accounts_by_person'), but the description doesn't explain when this specific person+file filtering approach is appropriate versus other filtering methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states this is a list operation, implying read-only behavior, but doesn't mention pagination details (implied by parameters), rate limits, authentication needs, or what the output contains (though an output schema exists). The description adds minimal behavioral context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's appropriately sized for a simple list tool, though this conciseness comes at the cost of detail. The structure is front-loaded with the core action, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, 1 required) and the presence of an output schema (which handles return values), the description is minimally complete but lacks depth. It covers the basic purpose but misses parameter explanations, usage context, and behavioral details. With no annotations and low schema coverage, it should do more to compensate, but the output schema reduces the burden slightly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description only mentions 'src_id' without explaining what it is (e.g., source ID, account ID) or the meaning of 'movimentacoes'. It doesn't address the pagination parameters 'pagina' and 'itens_por_pagina' at all, leaving them undocumented. The description adds very little semantic value beyond naming one parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Lista movimentacoes do SIMBA por src_id' clearly states the action (list) and resource (movements from SIMBA), but it's vague about what 'movimentacoes' specifically means (transactions, transfers, activities?) and doesn't differentiate from sibling tools like 'simba_list_accounts' or 'simba_list_movements_by_person_and_file'. The purpose is understandable but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, context, or exclusions, and it doesn't reference sibling tools like 'simba_list_movements_by_person_and_file' for comparison. Usage is implied only by the parameter 'src_id', but no explicit guidelines are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions listing events, which suggests a read-only operation, but doesn't specify permissions, rate limits, output format, or pagination. This leaves significant gaps in understanding how the tool behaves beyond its basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's front-loaded with the core action, making it easy to parse, though it could be slightly more informative without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (analytics with two required parameters), no annotations, and the presence of an output schema, the description is minimally complete. It covers the basic purpose but lacks details on behavior, usage context, and parameter specifics, making it adequate but with clear gaps for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal semantics by indicating that parameters are used to list events 'por src_id' and 'de um numero', but with 0% schema description coverage and two required parameters, it doesn't fully compensate. It hints at the purpose of 'src_id' and 'numero_telefone' but lacks details on formats or constraints, resulting in an adequate but incomplete explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('Lista eventos de portabilidade') and resource ('de um numero por src_id'), which clarifies the tool's purpose. However, it's somewhat vague about what 'eventos de portabilidade' entails (e.g., portability events like transfers or changes), and it doesn't differentiate from sibling tools like 'telefonica_list_portability_events', leaving room for confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as 'telefonica_list_portability_events' or other analytics tools. The description implies usage for listing events by number and src_id, but it lacks explicit context, prerequisites, or exclusions, offering minimal direction for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action ('busca') without detailing whether this is a read-only fetch, if it requires authentication, what happens on failure, or the format of the returned file. For a tool that likely retrieves data, this lack of context is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Portuguese that directly states the tool's action and parameters. It's front-loaded with the core purpose, though it could be more structured if it included additional context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which likely describes the returned file), the description doesn't need to explain return values. However, with 2 parameters at 0% schema coverage and no annotations, the description is minimal—it states the action and parameters but lacks details on behavior, usage, or parameter meaning, making it adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description mentions 'por src_id e identificador' (by src_id and identifier), adding minimal semantic context about what these parameters represent. However, it doesn't explain their purpose, format, or examples, leaving them largely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'busca um arquivo da Telefonica' (searches for a Telefonica file) which provides a basic verb+resource combination. However, it's vague about what 'busca' entails (retrieves, fetches, searches metadata?) and doesn't distinguish it from sibling tools like 'telefonica_get_file_status' or 'telefonica_list_files' that might handle related file operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, context, or compare it to sibling tools like 'telefonica_list_files' (for listing) or 'telefonica_get_file_status' (for status checks), leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. While 'Lista' implies a read operation, the description doesn't mention pagination behavior (despite pagination parameters in the schema), authentication requirements, rate limits, or what format the connections data will be returned in. It provides minimal behavioral context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Portuguese that directly states the tool's purpose without unnecessary words. It's appropriately sized for what it communicates, though it could benefit from additional context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there's an output schema (which handles return values), 4 parameters with no schema descriptions, and no annotations, the description is minimally complete but leaves significant gaps. It states what the tool does at a high level but doesn't provide enough context about parameters, usage scenarios, or behavioral characteristics for a tool with multiple undocumented parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for all 4 parameters, the description provides no information about what 'src_id' and 'identificador' represent, why they're required, or how the pagination parameters work. The description doesn't compensate for the complete lack of parameter documentation in the schema, leaving all parameters semantically undefined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Lista conexoes de um arquivo da Telefonica' clearly states the action (list) and resource (connections from a Telefonica file), but it's somewhat vague about what 'conexoes' specifically means in this context. It doesn't distinguish itself from sibling tools like 'telefonica_list_voice' or 'telefonica_list_messages' that also list items from Telefonica files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With multiple Telefonica listing tools available (e.g., telefonica_list_voice, telefonica_list_messages, telefonica_list_antennas), there's no indication of what makes this specific tool appropriate for listing 'conexoes' rather than other data types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions listing NATed IPs from a file, implying a read-only operation, but doesn't specify whether this is paginated (though parameters suggest it), what the output format is, or any constraints like rate limits or authentication needs. This leaves significant gaps for a tool with 4 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Portuguese that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to understand at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters with 0% schema coverage and no annotations, but an output schema exists, the description is minimally adequate. It specifies the resource (NATed IPs from a Telefonica file), but lacks details on parameters, behavioral traits, and usage context, making it incomplete for effective tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning parameters like 'src_id' and 'identificador' are undocumented in the schema. The description doesn't add any meaning to these parameters—it doesn't explain what 'src_id' or 'identificador' refer to, nor does it clarify the pagination parameters. This fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'Lista IPs nateados de um arquivo da Telefonica' (Lists NATed IPs from a Telefonica file), which provides a clear verb ('Lista') and resource ('IPs nateados'). However, it doesn't differentiate from sibling tools like 'telefonica_list_ips' or 'telematica_list_ips', making it somewhat vague about its specific scope within the Telefonica context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, such as needing a specific file type or context, nor does it reference sibling tools like 'telefonica_list_ips' for comparison, leaving usage entirely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions filtering but doesn't describe what the tool returns, whether it's paginated, what permissions are required, or any rate limits. The phrase 'com filtros explicitos' suggests parameter-based filtering but doesn't explain the behavior beyond that minimal hint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point. There's no wasted language or unnecessary elaboration. However, it could be slightly more structured by explicitly mentioning it's a listing/querying operation rather than just 'Lista'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there's an output schema (which reduces the need to describe return values) but 0% schema description coverage for 6 parameters and no annotations, the description is minimally adequate. It identifies the resource and hints at filtering, but doesn't provide enough context about parameter usage, behavioral characteristics, or differentiation from sibling tools for confident tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. The description mentions 'filtros explicitos' which hints at the filtering parameters, but doesn't explain what any of the 6 parameters mean, their relationships, or how they affect results. This leaves significant gaps in understanding the tool's inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Lista') and resource ('contas do SIMBA'), making the purpose understandable. It specifies 'com filtros explicitos' which adds useful context about filtering capabilities. However, it doesn't explicitly distinguish this from sibling tools like 'simba_list_accounts_by_person', which appears to be a more specific variant.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of the sibling tool 'simba_list_accounts_by_person' or any other filtering tools. The phrase 'com filtros explicitos' hints at filtering capability but doesn't specify when this general listing tool is preferable to more specific alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While it indicates this is a counting/analytics operation (implied read-only), it doesn't specify whether this requires specific permissions, what the output format looks like, whether there are rate limits, or how results are structured. The description is minimal and lacks important behavioral context for a tool with required parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single sentence in Portuguese that directly states the tool's purpose. There's no wasted language or unnecessary elaboration. While it may be too brief for complete understanding, it's structurally efficient and front-loaded with the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there's an output schema (which should document return values), the description's minimalism is somewhat acceptable. However, for a tool with two required parameters and no annotations, the description should provide more context about parameter meanings and usage scenarios. It's borderline adequate but leaves significant gaps in understanding how to properly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides zero information about the two required parameters (src_id and identificador). With 0% schema description coverage and no parameter explanation in the description, the agent has no semantic understanding of what these parameters represent, their expected formats, or how they relate to the counting operation. This is a significant gap for a tool with required parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Conta numeros distintos de origem e destino por arquivo da Telefonica' (Counts distinct origin and destination numbers per Telefonica file). It specifies the verb ('conta' - counts), resource ('numeros distintos' - distinct numbers), and scope ('por arquivo da Telefonica' - per Telefonica file). However, it doesn't explicitly differentiate from its sibling 'telefonica_analytics_distinct_numbers_by_case', which appears to serve a similar purpose but with a different grouping dimension.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, when this tool is appropriate versus other distinct number counting tools (like 'telefonica_analytics_distinct_numbers_by_case'), or any contextual limitations. The agent must infer usage from the tool name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but offers minimal information. It states it's a list operation, implying it's likely read-only and non-destructive, but doesn't specify pagination behavior, rate limits, authentication needs, or error conditions. The description lacks crucial behavioral context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, straightforward sentence that efficiently states the core action without unnecessary words. It's appropriately sized for a simple list tool, though it could be more informative without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values) and moderate complexity (3 parameters, 1 required), the description is minimally adequate but incomplete. It covers the basic purpose but lacks parameter explanations, usage context, and behavioral details, making it insufficient for optimal agent understanding without relying heavily on the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The tool description adds no information about the three parameters (registro_ids, pagina, itens_por_pagina), failing to explain what registro_ids are, how pagination works, or default values. This leaves parameters largely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Lista') and resource ('enderecos IP de registros da Telematica'), making the purpose understandable. However, it doesn't explicitly differentiate this tool from sibling tools like 'telematica_list_connections' or 'telematica_list_records', which also list Telematica data but for different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, context, or comparison to sibling tools like 'telematica_get_record' or 'telematica_analytics_by_account', leaving the agent to infer usage based on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a listing operation, which implies read-only behavior, but doesn't mention pagination behavior (though parameters suggest it), authentication requirements, rate limits, or what the output contains. The description is minimal and doesn't provide adequate behavioral context for a tool with parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single sentence in Portuguese that directly states the tool's purpose. There's no wasted language or unnecessary elaboration. It's front-loaded with the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a listing tool with 3 parameters, 0% schema coverage, no annotations, but with an output schema, the description is minimally adequate. The output schema existence means return values are documented elsewhere, but the description doesn't provide enough context about filtering, pagination, or behavioral characteristics to be considered complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 3 parameters, the description provides no information about any parameters. It doesn't mention filtering by active status ('eh_ativo'), pagination ('pagina'), or items per page ('itens_por_pagina'). The description fails to compensate for the complete lack of parameter documentation in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Lista' - list) and resource ('relacionamentos KYT configurados no modulo de grafo'), making the purpose understandable. It doesn't explicitly differentiate from sibling tools like 'grafo_list_kyt_layers' or 'grafo_list_graphs', but the specific mention of 'KYT relationships' provides some implicit distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are multiple 'grafo_list_' tools and 'kyt_' tools in the sibling list, but no indication of when this specific KYT relationships listing tool is appropriate versus other listing or KYT-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is a list operation, implying it's likely read-only and non-destructive, but doesn't confirm this or mention any constraints like rate limits, authentication needs, or pagination behavior. The inclusion of 'schema_propriedades' hints at output content but lacks detail on format or structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's appropriately sized and front-loaded, with every part contributing to the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, no annotations, but with an output schema), the description is minimally adequate. It clarifies the resource and included data, but lacks parameter details and behavioral context. The presence of an output schema reduces the need to explain return values, but overall completeness is limited due to missing usage and parameter guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It adds no information about the four parameters (label_type, label_code, pagina, itens_por_pagina), failing to explain their purposes, formats, or how they affect the listing. This leaves significant gaps in parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Lista') and resource ('labels do modulo de grafo'), making the purpose understandable. It adds specificity by mentioning 'schema_propriedades' as included content. However, it doesn't explicitly differentiate from sibling tools like 'grafo_list_graphs' or 'grafo_list_algorithms', which would require a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, exclusions, or comparisons to sibling tools such as 'grafo_list_graphs' or 'grafo_list_algorithms', leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates a read operation ('Lista') but lacks details on permissions, rate limits, data format, or pagination. The description doesn't contradict annotations, but it's insufficient for a tool with potential complexity in data retrieval.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Portuguese that directly states the tool's function. It's front-loaded with the core action and includes key details without unnecessary words, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 parameters with 0% schema coverage and no annotations, the description is incomplete—it doesn't fully explain parameter meanings or behavioral aspects. However, an output schema exists, so return values are documented elsewhere, raising the baseline. The description covers the basic purpose but leaves gaps in usage and parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter details. The description mentions 'CPF/CNPJ' and 'origem' (origin), hinting at 'cpf_cnpj' and possibly 'src_id', but doesn't explain what 'src_id' represents, expected formats, or constraints. It adds minimal value beyond the bare parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Lista' - lists) and resource ('funcoes exercidas por um CPF/CNPJ' - functions performed by a CPF/CNPJ), specifying it operates 'dentro dos indexadores da origem' (within the origin's indexers). It doesn't explicitly differentiate from sibling tools like 'rif_analytics_get_resumo' or 'rif_analytics_list_maiores_transacoes', but the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, context, or exclusions, such as when to choose this over other 'rif_analytics' tools like 'list_maiores_transacoes_por_pessoa'. Usage is implied by the parameters but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states this is a list operation, implying read-only behavior, but doesn't address critical aspects like pagination, sorting order (e.g., descending by transaction size), rate limits, authentication needs, or what constitutes a 'maior transacao' (e.g., by amount, frequency). The description is minimal and lacks operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Portuguese that directly states the tool's function. It's front-loaded with the core action and resource, with no redundant or verbose language, making it highly concise and well-structured for its limited content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which likely defines the return structure), the description doesn't need to explain return values. However, with 2 parameters (one required), 0% schema coverage, and no annotations, the description is too sparse—it lacks parameter details and behavioral context, making it incomplete for effective agent use despite the output schema's assistance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description only mentions 'src_id' as the origin, adding minimal context. It doesn't explain 'top' (likely the number of top transactions to return) or provide examples, formats, or constraints for either parameter, leaving them largely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Lista') and resource ('maiores transacoes') with a specific scope ('associadas a uma origem (src_id)'). It's specific about what it does, though it doesn't explicitly differentiate from sibling tools like 'rif_analytics_list_maiores_transacoes_por_pessoa' which suggests a similar function but with a different grouping parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, exclusions, or comparison to sibling tools (e.g., 'rif_analytics_list_maiores_transacoes_por_pessoa' or 'rif_analytics_get_resumo'), leaving the agent to infer usage context solely from the tool name and parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Lista' implies a read-only operation, it doesn't specify whether this is a query that might be slow, whether it requires specific permissions, what the output format is (though an output schema exists), or any rate limits. The description is minimal and lacks behavioral context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence in Portuguese that directly states the tool's purpose without unnecessary words. It's front-loaded with the main action and efficiently conveys the core functionality, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values), no annotations, and low schema coverage (0%), the description is incomplete. It lacks details on parameter semantics, behavioral traits like performance or permissions, and usage context. However, the output schema mitigates some gaps by documenting return values, and the purpose is clear, making it minimally adequate but with significant room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the three parameters (src_id, cpf_cnpj, top) have descriptions in the schema. The description only vaguely references 'um CPF/CNPJ' and 'uma origem', which partially maps to cpf_cnpj and src_id but doesn't explain their formats, constraints, or what 'origem' means. The 'top' parameter is not mentioned at all. The description adds minimal value beyond the schema's parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Lista as maiores transacoes' - lists the largest transactions) and the target resource ('vinculadas a um CPF/CNPJ em uma origem' - linked to a CPF/CNPJ in a source). It specifies the scope of listing largest transactions, though it doesn't explicitly differentiate from sibling tools like 'rif_analytics_list_maiores_transacoes' (which lacks the per-person filter) or 'rif_analytics_list_pessoas_transacoes_por_tipo' (which groups by transaction type).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'rif_analytics_list_maiores_transacoes' (which might list largest transactions without filtering by person) or 'rif_analytics_list_funcoes_por_envolvido' (which lists functions per involved party). There's no context about prerequisites, data availability, or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a read-only list operation but doesn't disclose behavioral traits like whether it's paginated, sorted, has rate limits, requires specific permissions, or what the output format is. The description is too vague to guide the agent on how the tool behaves beyond its basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Portuguese that directly states the tool's purpose. It's front-loaded with the key action and resource, with no wasted words. Every part of the sentence contributes to understanding what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which covers return values), 4 parameters with 0% schema coverage, and no annotations, the description is minimally adequate. It states the purpose but lacks details on parameter usage, behavioral context, or differentiation from siblings. It meets the bare minimum for a list tool but leaves significant gaps in guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'tipo de operacao' which maps to 'tipo_transacao', but doesn't explain the other three parameters ('src_id', 'cpf_cnpj', 'top'). The description adds minimal value beyond the schema, failing to clarify what these parameters mean or how they affect the listing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Lista') and resource ('pessoas relacionadas e valores de transacoes'), specifying it's by 'tipo de operacao'. It distinguishes from siblings like 'rif_analytics_list_maiores_transacoes' by focusing on people and transaction values per operation type rather than largest transactions. However, it doesn't explicitly contrast with 'rif_analytics_list_funcoes_por_envolvido' which also involves people.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context, or exclusions. For example, it doesn't clarify if this is for analytics vs. raw data retrieval or how it differs from other 'rif_analytics' tools that list transactions or people.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions pagination and ordering are optional, which is useful, but doesn't describe other important behaviors: whether this is a read-only operation, what permissions might be required, rate limits, error conditions, or what the output looks like. For a tool with 6 parameters and no annotations, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single sentence in Portuguese that efficiently communicates the core functionality. It's front-loaded with the main purpose and includes the key optional features. There's no wasted language or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema (which reduces the need to describe return values in the description), but with 6 parameters, 0% schema description coverage, and no annotations, the description is incomplete. It covers the basic purpose and mentions pagination/ordering, but doesn't provide enough context about parameter meanings, behavioral constraints, or differentiation from similar tools. It's minimally adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 6 parameters have descriptions in the schema. The description mentions 'src_id' and 'numero_telefone' (phone number) as required, and hints at pagination and ordering parameters, but doesn't explain what 'src_id' represents, what format the phone number should be in, what fields can be used for ordering, or what the ordering options are. It adds minimal value beyond what's implied by parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Lista ligacoes de um numero por src_id' (Lists calls of a number by src_id). It specifies the verb ('lista' - list) and resource ('ligacoes' - calls), and mentions optional pagination and ordering. However, it doesn't explicitly distinguish this tool from sibling tools like 'telefonica_analytics_calls_by_file' or 'telefonica_analytics_connections_by_number', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are multiple sibling tools for telefonica analytics (e.g., calls_by_file, call_stats_by_case, connections_by_number), but the description doesn't mention any of them or explain the specific use case for this tool. It only states what the tool does, not when it's appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions pagination and optional ordering, which are useful behavioral traits. However, it doesn't describe what 'ligacoes' (calls) includes, the response format, error conditions, rate limits, authentication requirements, or whether this is a read-only operation. For a tool with 7 parameters and no annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Portuguese that communicates the core functionality and key features (pagination, ordering) without unnecessary words. It's appropriately sized for the tool's complexity and gets straight to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values) but no annotations and 0% schema description coverage, the description is incomplete. It covers the basic purpose and mentions pagination/ordering, but doesn't address parameter meanings, behavioral constraints, or usage context. For a 7-parameter tool with no structured documentation beyond titles, the description should provide more semantic guidance to be truly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 7 parameters have descriptions in the schema. The tool description only mentions pagination and ordering generally, without explaining any specific parameters like 'src_id', 'identificador', or 'numero_telefone'. The description fails to compensate for the complete lack of parameter documentation in the schema, leaving the agent with minimal guidance on what each parameter means.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Lista ligacoes' - List calls) and specifies the resource scope ('de um numero por arquivo' - from a number by file). It distinguishes from some siblings like 'telefonica_analytics_calls_by_case' by specifying 'por arquivo' (by file) rather than 'por caso' (by case). However, it doesn't explicitly differentiate from other file-based call tools like 'telefonica_analytics_call_stats_by_file'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose this over 'telefonica_analytics_calls_by_case' or 'telefonica_analytics_call_stats_by_file', nor does it specify prerequisites or appropriate contexts for its use. The agent must infer usage from the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it returns statistics but doesn't specify what kind of statistics (e.g., call duration, frequency), whether it's a read-only operation, if there are rate limits, or authentication requirements. This leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's front-loaded with the core action and target, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which should cover return values), the description's main gaps are in parameter semantics and behavioral context. However, with no annotations and low schema coverage, the description is incomplete for a tool with 3 required parameters, as it doesn't fully explain inputs or operational traits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning parameters 'src_id', 'identificador', and 'numero_telefone' are undocumented in the schema. The description only implies 'numero_telefone' is a phone number and 'arquivo especifico' relates to a file, but doesn't explain what 'src_id' or 'identificador' represent or how they interact with the file, failing to compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Retorna estatisticas de ligacoes') and the target ('para um numero em arquivo especifico'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'telefonica_analytics_calls_by_file' or 'telefonica_analytics_call_stats_by_case', which appear to offer similar functionality with different scopes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description mentions 'arquivo especifico' but doesn't clarify prerequisites, such as whether the file must be pre-loaded or available in a system, nor does it compare to siblings like 'telefonica_analytics_call_stats_by_case' for case-based stats.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states this is a listing operation ('Lista'), implying it's likely read-only, but doesn't confirm safety aspects like whether it requires authentication, has rate limits, or what happens with invalid inputs. For a tool with zero annotation coverage, this leaves significant behavioral gaps, though it at least implies a non-destructive read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Portuguese that front-loads the core purpose. There's no wasted wording or unnecessary elaboration—it directly states what the tool does without redundancy. This is appropriately concise for a listing tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 parameters, 2 required), no annotations, and an output schema (which reduces the need to describe return values), the description is minimally adequate. It covers the basic purpose but lacks details on parameter semantics, usage context, and behavioral traits. The presence of an output schema helps, but the description doesn't fully compensate for the missing annotations and low schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 4 parameters have descriptions in the schema. The description mentions 'antenna' and 'periodo opcional', which loosely map to 'cgi_erb' (antenna identifier) and the date parameters ('data_inicio', 'data_fim'), but doesn't explain 'src_id' or provide any format details (e.g., date format, antenna ID syntax). It adds minimal value beyond the schema's titles, failing to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Lista telefones conectados a uma antena da Telefonica em um periodo opcional' (Lists phones connected to a Telefonica antenna during an optional period). It specifies the verb ('Lista'), resource ('telefones conectados a uma antena'), and scope ('periodo opcional'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'telefonica_list_connections' or 'telefonica_analytics_connections_by_number', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, constraints, or how it differs from related sibling tools (e.g., 'telefonica_list_connections' or 'telefonica_analytics_connections_by_number'). The agent must infer usage from the name and description alone, which is insufficient for optimal tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only states what the tool does ('returns status'), but doesn't disclose any behavioral traits such as whether it's a read-only operation, what authentication is required, rate limits, error conditions, or what 'status' entails (e.g., processing state, metadata). For a tool with no annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single sentence that directly states the tool's purpose. There's no wasted language or unnecessary elaboration. It's appropriately sized for a simple tool and front-loads the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there's an output schema (which should document return values), the description doesn't need to explain return values. However, for a tool with 2 required parameters and no annotations, the description is minimal. It states the basic purpose but lacks crucial context about parameter usage, behavioral characteristics, and differentiation from sibling tools. The existence of an output schema raises this from a lower score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 2 parameters (src_id and identificador) with 0% description coverage in the schema (titles only). The description provides no information about these parameters - it doesn't explain what they represent, their format, or how they identify the file. With low schema coverage (<50%), the description fails to compensate by adding any parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Retorna o status de um arquivo da Telefonica' (Returns the status of a Telefonica file). It specifies the verb ('retorna' - returns) and resource ('arquivo da Telefonica' - Telefonica file), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'telefonica_get_file' or 'telefonica_list_files', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when this tool is appropriate compared to similar tools like 'telefonica_get_file' (which presumably retrieves file content) or 'telefonica_list_files' (which lists files). There's no context about prerequisites, constraints, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it returns metrics but doesn't disclose behavioral traits like whether it's read-only, has rate limits, requires specific permissions, or what format/size the output might have. 'Retorna' suggests a query operation, but details are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose. It's front-loaded with the key action and parameters, with no wasted words, though it could be more structured with additional context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 required parameters, 0% schema coverage, no annotations, but an output schema exists, the description is minimally adequate. It covers the basic purpose and parameters but lacks behavioral details and usage guidance. The output schema mitigates the need to explain return values, but overall completeness is limited for an analytics tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description adds minimal semantics by naming the parameters ('source_id' and 'identificador_conta') and implying they filter metrics by account, but it doesn't explain what these IDs represent, their format, or examples. Baseline is 3 as it compensates slightly for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Retorna' - returns) and resource ('metricas analiticas da Telematica'), specifying it's by account. It distinguishes from sibling tools like 'telematica_analytics_by_source' by indicating account-level focus, though it doesn't explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'telematica_analytics_by_source' or other analytics tools. The description implies usage for account-specific metrics but lacks explicit context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool returns aggregated connection data but doesn't mention whether this is a read-only operation, if it requires specific permissions, what the output format looks like (though an output schema exists), or any rate limits or constraints. For an analytics tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's front-loaded with the core purpose, making it easy to parse. There's no redundancy or fluff, which is ideal for conciseness in a tool definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (analytics grouping with 2 required parameters), lack of annotations, and 0% schema coverage, the description is incomplete. It covers the basic purpose but misses parameter semantics, usage context, and behavioral details. The presence of an output schema helps by documenting return values, but overall, the description doesn't provide enough context for confident tool invocation without additional inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the input schema provides no descriptions for the two required parameters ('source_id' and 'identificador_conta'). The description doesn't add any semantic information about these parameters—it doesn't explain what they represent, their format, or how they affect the grouping. This fails to compensate for the lack of schema documentation, leaving parameters largely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Retorna total de conexoes da conta agrupado por dispositivo' (Returns total connections of the account grouped by device). It specifies the verb ('retorna'), resource ('conexoes'), and grouping criteria ('por dispositivo'), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'telematica_list_connections' or 'telefonica_analytics_connections_by_number', which would be needed for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling analytics tools (e.g., 'telematica_analytics_by_account', 'telefonica_analytics_connections_by_number'), there's no indication of context, prerequisites, or exclusions. The agent must infer usage from the name and parameters alone, which is insufficient for effective tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool returns a distribution, implying a read-only operation, but doesn't specify whether it's safe, requires authentication, has rate limits, or details the output format. With an output schema present, some behavioral aspects might be covered there, but the description itself lacks critical behavioral context for a tool with parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any fluff or redundancy. It's appropriately sized and front-loaded, making it easy to parse quickly. Every word contributes to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no annotations, but with an output schema), the description is minimally adequate. It states what the tool does but lacks details on usage, parameters, and behavioral traits. The presence of an output schema helps cover return values, but the description doesn't fully address the gaps in parameter documentation and behavioral transparency, making it incomplete for optimal agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'para a conta' (for the account), which loosely relates to the 'identificador_conta' parameter, but it doesn't explain the 'source_id' parameter or provide any details on parameter usage, formats, or constraints. With 0% schema description coverage and two required parameters, the description fails to compensate for the lack of schema documentation, leaving parameters largely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Retorna distribuicao de contatos por municipio para a conta' (Returns distribution of contacts by municipality for the account). It specifies the verb ('retorna'), resource ('contatos'), and scope ('por municipio para a conta'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'telematica_list_contacts' or 'telematica_analytics_by_account', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, context for usage, or comparisons to sibling tools such as 'telematica_list_contacts' or 'telematica_analytics_by_account'. This lack of usage context leaves the agent without clear direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It indicates a read-only operation ('retorna'), but doesn't specify data format, pagination, rate limits, authentication needs, or error handling. For a tool with 5 parameters and no annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Portuguese that directly states the tool's function without unnecessary words. It's front-loaded with the core purpose, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, 2 required), no annotations, and 0% schema description coverage, the description is incomplete. It lacks parameter details, behavioral context, and usage guidelines. However, the presence of an output schema reduces the need to describe return values, preventing a lower score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning parameter titles are generic (e.g., 'Source Id', 'Data Inicio'). The description adds no semantic information about parameters, such as what 'source_id' refers to, date format for 'data_inicio', or how 'top_n' affects results. It fails to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Retorna serie temporal de IPs distintos por dia da conta' (Returns time series of distinct IPs per day for the account). It specifies the verb ('retorna'), resource ('IPs distintos'), and scope ('por dia da conta'), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'telematica_list_ips', which might list IPs without temporal aggregation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, such as requiring 'source_id' and 'identificador_conta', or compare it to similar tools like 'telematica_list_ips' for non-temporal IP listings. Usage context is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It indicates this is a read operation ('retorna') and mentions optional period filters, but it doesn't cover critical aspects like authentication requirements, rate limits, pagination, error handling, or what 'recent' means (e.g., time threshold). For a tool with 5 parameters and no annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Portuguese that directly states the tool's purpose. It's front-loaded with the core functionality and includes the key detail about optional filters without unnecessary elaboration. Every word earns its place, making it highly concise and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the context: 5 parameters with 0% schema coverage, no annotations, but an output schema exists (which reduces the need to describe return values). The description covers the basic purpose and hints at period filters but misses details on parameter meanings, behavioral traits, and usage guidelines. It's minimally adequate for a read operation but incomplete for effective tool selection and invocation, especially with undocumented parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, meaning none of the 5 parameters have descriptions in the input schema. The description only vaguely references 'filtros opcionais de periodo' (optional period filters), which might relate to 'data_inicio' and 'data_fim', but it doesn't explain any parameters like 'source_id', 'identificador_conta', or 'top_n'. This fails to compensate for the lack of schema documentation, leaving most parameters semantically unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Retorna grupos recentes da conta com filtros opcionais de periodo' (Returns recent groups from the account with optional period filters). It specifies the verb ('retorna'), resource ('grupos recentes da conta'), and scope ('com filtros opcionais de periodo'). However, it doesn't explicitly distinguish this tool from sibling tools like 'telematica_list_groups' or 'telematica_analytics_relevant_groups', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions optional period filters but doesn't specify use cases, prerequisites, or comparisons to sibling tools such as 'telematica_list_groups' (which might list all groups without recency filters) or 'telematica_analytics_relevant_groups' (which might focus on relevance rather than recency). This lack of contextual guidance limits its utility for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description mentions that it returns groups ranked by participant count, which is useful, but it doesn't cover critical aspects like whether this is a read-only operation, potential rate limits, authentication requirements, or what 'relevance' entails beyond participant count. For a tool with no annotations, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence in Portuguese that efficiently conveys the core purpose. It's front-loaded with the main action and contains no unnecessary words or redundant information. Every part of the sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there's an output schema (which should cover return values), the description's main job is to explain purpose and usage. It does a decent job on purpose but lacks usage guidelines and parameter semantics. With no annotations and 0% schema description coverage, the description doesn't fully compensate for these gaps, making it minimally adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the parameters have descriptions in the schema. The tool description doesn't mention any parameters, so it adds no semantic value beyond what the schema provides. With 3 parameters (source_id, identificador_conta, top_n) and no explanation in either the schema or description, this is inadequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Retorna os grupos mais relevantes da conta por quantidade de participantes' (Returns the most relevant groups of the account by number of participants). It specifies the verb (returns), resource (groups), and ranking criteria (by number of participants). However, it doesn't explicitly differentiate from sibling tools like 'telematica_list_groups' or 'telematica_analytics_recent_groups', which would be needed for a score of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are multiple sibling tools related to groups (e.g., 'telematica_list_groups', 'telematica_analytics_recent_groups'), but the description doesn't mention any of them or specify contexts where this tool is preferred. It only states what the tool does, not when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a listing operation (implying read-only), but doesn't mention authentication requirements, rate limits, pagination behavior (though schema shows pagination parameters), or what the output contains. For a tool with 3 parameters and no annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core purpose without unnecessary words. It's appropriately sized for a listing operation and front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description states the basic purpose but lacks crucial context. With no annotations, 3 parameters (0% schema coverage), and an output schema (which helps), it should explain parameter meanings and behavioral constraints. It's minimally adequate but has clear gaps for a tool that likely returns structured email data from specific records.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning parameter titles provide minimal context. The description doesn't mention any parameters or their purposes. It doesn't explain what 'registro_ids' represents, how pagination works, or the relationship between parameters. With 3 parameters (1 required) and no schema descriptions, the description fails to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Lista emails') and target resource ('de registros da Telematica'), providing specific verb+resource information. However, it doesn't differentiate from sibling tools like 'telematica_list_contacts' or 'telematica_list_records' beyond mentioning emails specifically, which keeps it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'telematica_list_contacts' and 'telematica_list_records' available, there's no indication of when email listing is appropriate versus other listing operations, nor any mention of prerequisites or constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool searches for a graph by UUID, implying a read operation, but doesn't cover aspects like authentication needs, rate limits, error handling, or what the output contains (though an output schema exists). This leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence in Portuguese ('Busca um grafo especifico por UUID.') that is front-loaded and wastes no words. It efficiently conveys the core purpose without unnecessary elaboration, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter) and the presence of an output schema, the description is minimally adequate. It covers the basic action and parameter semantics but lacks behavioral context and usage guidelines. For a simple retrieval tool, it meets a baseline but could be more informative about when and how to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning by specifying that the parameter 'grafo_id' is a UUID, which clarifies the expected format beyond the schema's generic string type. With 0% schema description coverage and only one parameter, this compensates well, though it doesn't detail constraints like UUID version or validation rules.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Busca um grafo especifico por UUID' clearly states the action (busca/search) and resource (grafo/graph) with a specific identifier method (por UUID/by UUID). However, it doesn't differentiate from sibling tools like 'grafo_list_graphs' or 'grafo_describe_algorithm' beyond the UUID specificity, making it clear but not fully distinguishing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'grafo_list_graphs' for listing graphs or other retrieval tools. It lacks any context about prerequisites, exclusions, or comparisons with sibling tools, offering minimal usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the counting action without detailing output format, pagination, rate limits, authentication needs, or whether it's read-only or destructive. This is inadequate for a tool with an output schema but no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (analytics function with one parameter and an output schema), the description is minimally complete. It states the purpose but lacks behavioral details and usage guidelines. The presence of an output schema reduces the need to explain return values, but without annotations, more context on operation traits is warranted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning by specifying that 'src_id' is used to count distinct numbers by case, which clarifies the parameter's role beyond the schema's minimal title. With 0% schema description coverage and only one parameter, this compensates adequately, though it could provide more context on what 'src_id' represents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool counts distinct numbers of origin and destination by src_id, which clarifies the verb ('conta' - counts) and resource (distinct numbers). However, it's vague about what 'origem e destino' (origin and destination) specifically refers to in this context (e.g., phone calls, messages), and it doesn't differentiate from sibling tools like 'telefonica_analytics_distinct_numbers_by_file'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, exclusions, or compare it to similar tools such as 'telefonica_analytics_distinct_numbers_by_file', leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions suggesting algorithms based on graph metadata and an optional objective, but doesn't describe what the suggestion entails (e.g., ranking, filtering, explanations), whether it's a read-only operation, performance considerations, or error handling. For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Portuguese that directly states the tool's function. It's front-loaded with the core purpose and includes key details (metadata and optional objective) without unnecessary elaboration. Every word earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (suggesting algorithms based on graph context), no annotations, 0% schema coverage, but an output schema present, the description is minimally adequate. It covers the basic purpose but lacks details on behavior, parameter usage, and how suggestions are generated. The output schema may help with return values, but the description doesn't provide enough context for effective use without additional inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning parameters 'grafo_id' and 'objetivo' have no descriptions in the schema. The description adds minimal semantics: it implies 'grafo_id' identifies the graph and 'objetivo' is an optional investigative objective, but doesn't clarify formats, constraints, or examples. With 2 parameters and low schema coverage, the description doesn't adequately compensate for the lack of structured documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Sugere algoritmos para um grafo' (suggests algorithms for a graph) based on metadata and an optional investigative objective. It specifies the verb 'sugere' (suggests) and resource 'algoritmos para um grafo' (algorithms for a graph), making the intent unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'grafo_list_algorithms' or 'grafo_describe_algorithm', which list or describe algorithms rather than suggest them based on graph context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning 'com base em seus metadados e em um objetivo investigativo opcional' (based on its metadata and an optional investigative objective), suggesting it's for graph analysis tasks. However, it doesn't provide explicit guidance on when to use this tool versus alternatives like 'grafo_list_algorithms' (which might list all available algorithms without context) or other graph-related tools. No exclusions or prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Lista' implies a read-only operation, the description doesn't specify whether this requires authentication, returns paginated results, has rate limits, or what format the output takes. The existence of an output schema helps but doesn't excuse the lack of behavioral context in the description itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Portuguese that directly states the tool's purpose. There's no wasted verbiage or unnecessary elaboration. While it could be slightly more specific about what 'quadros e atributos' entails, it's appropriately concise for a listing tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a read-only listing tool with zero parameters and an output schema exists, the description provides the basic purpose. However, with no annotations and many similar sibling tools, it lacks important contextual information about when to use it versus alternatives and behavioral characteristics like authentication requirements or result format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is 100%. The description correctly indicates this is a parameterless listing operation ('Lista os quadros e atributos'), which aligns perfectly with the empty input schema. For a zero-parameter tool, this provides adequate semantic information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Lista os quadros e atributos') and the target resource ('conhecidos pela API KYT'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'grafo_list_kyt_layers' or 'grafo_list_kyt_relationships' that also list KYT-related items, so it doesn't reach the highest clarity level.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools that also list KYT-related data (e.g., 'grafo_list_kyt_layers', 'grafo_list_kyt_relationships'), there's no indication of what distinguishes this tool's purpose or when it should be selected over those options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states it retrieves a detailed record, implying a read-only operation, but doesn't disclose behavioral traits like authentication needs, rate limits, error handling, or what 'detalhado' (detailed) entails. The description is minimal and lacks crucial operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values), the description's minimalism is somewhat acceptable. However, with no annotations and incomplete parameter guidance, it leaves gaps in understanding the tool's behavior and usage context. It's adequate but not fully complete for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'por UUID' (by UUID), which adds meaning to the 'registro_id' parameter, indicating it should be a UUID. However, with 0% schema description coverage and only one parameter, this provides some value but doesn't fully compensate for the lack of schema details (e.g., UUID format). The baseline for 0 parameters would be 4, but here there is 1 parameter with partial clarification.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Busca' - searches/retrieves) and the resource ('um registro detalhado da Telematica' - a detailed Telematica record), specifying it's done by UUID. It's specific enough to understand the core function, though it doesn't explicitly differentiate from sibling tools like 'telematica_list_records'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'telematica_list_records' for listing multiple records or other Telematica analytics tools, nor does it specify prerequisites or contexts for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It states this is a list operation, implying it's likely read-only, but doesn't confirm this or describe other behaviors like pagination (though parameters suggest it), rate limits, authentication needs, or what happens with null parameters. The description adds minimal behavioral context beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Portuguese that directly states the tool's purpose and filtering options. It's appropriately sized with no wasted words, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters with 0% schema coverage and no annotations, the description provides basic purpose and some parameter hints but lacks details on behavior, full parameter semantics, and output (though an output schema exists). For a list tool with multiple filtering and pagination options, this leaves the agent with incomplete guidance, though the existence of an output schema mitigates some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It mentions filtering by 'origem/controle' (likely mapping to 'source_id' or 'identificador') and 'usuario' (likely mapping to 'criado_por_id'), adding some semantic meaning. However, it doesn't explain the two pagination parameters ('pagina', 'itens_por_pagina') or provide details on parameter interactions, leaving significant gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Lista' - List) and resource ('registros da Telematica' - Telematica records), making the purpose understandable. However, it doesn't specifically differentiate this tool from sibling tools like 'telematica_list_connections', 'telematica_list_contacts', etc., which all list different Telematica entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning filtering 'por origem/controle ou por usuario' (by source/control or by user), suggesting this tool is for listing records with those specific filters. However, it doesn't provide explicit guidance on when to use this versus other Telematica list tools or alternatives, nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Lista' implies a read-only operation, it doesn't specify whether this returns all services or a subset, what format the output takes, whether there are pagination considerations, or any rate limits. The description is minimal and lacks important behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Portuguese that directly states the tool's purpose without unnecessary words. It's appropriately sized for a simple listing tool with no parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, an output schema exists, and it's a simple listing operation, the description is reasonably complete for basic understanding. However, for a tool with investigative services in its name, more context about what constitutes 'serviços investigativos' or the scope of the catalog would be helpful, especially with no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema already fully documents the absence of parameters. The description appropriately doesn't discuss parameters, maintaining focus on the tool's purpose. Baseline for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Lista' - lists) and the resource ('serviços investigativos conhecidos pelo catálogo do Pharus'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from its sibling 'catalog_describe_service' which likely provides detailed descriptions rather than just listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of when this listing function is appropriate versus using other investigative tools in the sibling list, nor any prerequisites or constraints for its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states what the tool does but doesn't describe any behavioral traits: no indication of whether this is a read-only operation, what format the output takes, whether there are rate limits, authentication requirements, or error conditions. For a tool with zero annotation coverage, this is insufficient behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Portuguese that directly states the tool's purpose. There's no wasted language, repetition, or unnecessary elaboration. It's appropriately sized for a simple listing tool with no parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has zero parameters, 100% schema coverage, and an output schema exists, the description is minimally complete. However, for a tool with no annotations, it should ideally provide more behavioral context about what 'enums e valores relevantes' means and what format the output takes. The existence of an output schema helps, but the description doesn't leverage this to provide richer context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there are no parameter semantics to explain. With 100% schema description coverage (though empty) and no parameters, the baseline is 4. The description appropriately doesn't attempt to explain non-existent parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Lista' - lists) and resource ('enums e valores relevantes para o catalogo de algoritmos do modulo de grafos'), making the purpose understandable. It distinguishes itself from siblings like 'grafo_list_algorithms' by focusing specifically on enums/values rather than algorithms themselves. However, it doesn't specify what format the listing takes or what 'relevant' means in this context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, when this information would be needed, or how it relates to other algorithm-related tools like 'grafo_describe_algorithm' or 'grafo_list_algorithms'. The agent must infer usage from the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states it's a listing operation, implying read-only behavior, but doesn't disclose any behavioral traits such as pagination, rate limits, authentication needs, or what the output contains. For a tool with no annotations, this leaves significant gaps in understanding its operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that directly states the tool's purpose without any fluff. It's appropriately sized and front-loaded, with every word contributing to understanding what the tool does. No wasted words or complex structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, 100% schema coverage, and an output schema exists, the description is minimally adequate. However, with no annotations and multiple sibling tools, it lacks context on usage and behavioral details. For a simple list tool, it's passable but could be more informative about its role in the ecosystem.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, and it correctly doesn't mention any. Baseline for 0 parameters is 4, as it avoids unnecessary information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Lista' - lists) and the resource ('familias de algoritmos conhecidas para o modulo de grafos' - known algorithm families for the graph module). It's specific about what it retrieves, though it doesn't explicitly differentiate from sibling tools like 'grafo_list_algorithms' or 'grafo_list_algorithm_enums' beyond the resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'grafo_list_algorithms' and 'grafo_describe_algorithm_family', there's no indication of whether this lists high-level families while others list specific algorithms or provide details. No context or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool lists algorithms with optional filtering, but doesn't describe what the output looks like (though an output schema exists), whether it's paginated, rate-limited, or requires specific permissions. For a listing tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Portuguese that front-loads the core purpose and includes the optional filtering feature. Every word earns its place, with no redundancy or wasted space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one optional parameter) and the presence of an output schema (which handles return values), the description is reasonably complete. It covers the purpose and parameter usage adequately. However, without annotations, it could benefit from mentioning behavioral aspects like pagination or permissions, though the output schema mitigates some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context for the single parameter by explaining that 'familia' is used for optional filtering. With 0% schema description coverage (the schema only provides a title 'Familia'), this compensates well. However, it doesn't specify what values 'familia' accepts or provide examples, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Lista algoritmos do modulo de grafos' (List algorithms from the graph module). It specifies the verb (list) and resource (algorithms), and distinguishes it from siblings like 'grafo_describe_algorithm' or 'grafo_suggest_algorithms_for_graph'. However, it doesn't explicitly differentiate from 'grafo_list_algorithm_families', which is a related but distinct listing operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning optional filtering by family ('opcionalmente filtrando por familia'), which suggests when to use this tool for filtered vs. unfiltered listings. However, it doesn't provide explicit guidance on when to choose this over alternatives like 'grafo_list_algorithm_families' or 'grafo_describe_algorithm', nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![pharus-mcp MCP server](https://glama.ai/mcp/servers/rfalexandre/pharus-mcp/badges/card.svg)](https://glama.ai/mcp/servers/rfalexandre/pharus-mcp)

Score Badge

Copy to your README.md:

[![pharus-mcp MCP server](https://glama.ai/mcp/servers/rfalexandre/pharus-mcp/badges/score.svg)](https://glama.ai/mcp/servers/rfalexandre/pharus-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/rfalexandre/pharus-mcp'

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