Ploomes MCP Server

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools target distinct entities and actions, but a few (e.g., 'excluir_registro' and 'buscar_field_paths' vs 'resolver_field_path_checklist') introduce ambiguity. The clear descriptions largely mitigate confusion.
Naming Consistency4/5
The majority follow a consistent verb_noun pattern in Portuguese, but there are deviations like 'acoes_negocio' (noun phrase) and English-Portuguese mixes (e.g., 'salvar_pipeline'). Overall, the pattern is predictable.
Tool Count2/5
With 153 tools, the server is overloaded. While the domain is a full CRM, this volume significantly increases cognitive load for the agent, making efficient tool selection difficult.
Completeness4/5
The tool surface covers all major CRM entities (clients, deals, products, tasks, documents, users, automation) with full CRUD and additional utilities. Minor gaps exist (e.g., email templates), but core workflows are well-supported.
Average 3.4/5 across 153 of 153 tools scored. Lowest: 1.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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?
With no annotations provided, the description carries full behavioral disclosure burden, but it only mentions prerequisites. It does not describe the effect of finalizing a task (e.g., status change, irreversibility), side effects, or return values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but conciseness should not come at the cost of clarity. It is under-informative, providing only a prerequisite list without a clear purpose statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, output schema, and parameter descriptions, the description is severely incomplete. It fails to equip an agent with enough information to understand the tool's purpose, behavior, and return expectations.
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%, yet the description adds no meaning to the parameters 'id_tarefa' or 'comentarios'. The prerequisite hints at needing an ID, but no details on format or usage.
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 does not explicitly state what the tool does; it only lists a prerequisite. The name 'finalizar_tarefa' suggests finalizing a task, but the description fails to confirm this action, leaving the purpose unclear.
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?
No guidance is provided on when to use this tool versus alternatives like 'salvar_tarefa' or 'excluir_tarefa'. The description lacks any context for selection.
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 full burden. It fails to disclose any behavioral traits: it does not confirm the destructive nature, permissions needed, side effects, or reversibility. The description adds no behavioral context beyond the prerequisite.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one line), but it is underspecified rather than concise. It does not earn its place because it omits the core purpose and other essential information. A concise description should be both brief and complete.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one required parameter, no output schema, no annotations), the description is severely incomplete. It does not state the action, return value, or side effects. The prerequisite alone is insufficient for the agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not add any meaning to the parameter 'id_tarefa'. It only mentions that the ID should be obtained, without explaining its format or role. The description fails to compensate for the missing schema descriptions.
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 does not explicitly state that the tool deletes a task. It only gives a prerequisite ('Busque o ID da tarefa a ser excluída'), leaving the purpose implied by the name 'excluir_tarefa'. This is insufficient for a clear 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 on when or when not to use this tool. The description only instructs to fetch the ID first, which is a prerequisite, not usage context. No alternatives are mentioned, such as other exclusion tools or 'finalizar_tarefa'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It only mentions a pagination limit of 20 per page and that 'pagina' is an integer. No information about authentication, read-only nature, or return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but poorly structured, starting with '2.' indicating missing content. It is incomplete, lacking a first item or overall purpose. Conciseness is not achieved due to incompleteness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/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, no output schema, and no annotations, the description is severely incomplete. It fails to explain what the tool does, the purpose of parameters besides 'pagina', and return structure. Agent cannot confidently use this tool.
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%. The description adds limited meaning for 'pagina' (integer, page number) and a global limit of 20 results per page. No information for 'id', 'nome', or 'entidade'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not state what the tool does. The name 'buscar_marcadores' implies searching for markers, but the description only provides pagination details. It is missing a clear purpose statement.
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 'salvar_marcador' or 'excluir_marcador'. No exclusions or context provided about filtering or pagination 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?
With no annotations, the description must disclose behavioral traits. It mentions default ordering and pagination constraints but does not state whether the tool is read-only, destructive, requires authentication, or has rate limits. The side effects are unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (three bullet points) but loosely structured. It front-loads parameter notes but omits a general purpose statement. Every sentence adds value, but overall it could be more organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 13 parameters, no output schema, and no annotations, the description is severely incomplete. It fails to describe the tool's core function, return format, filtering behavior for most parameters, and any prerequisites. This is insufficient for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains only 2 of 13 parameters: 'pagina' (positive integer) and 'moeda_codigo' (ISO code). The remaining parameters (e.g., 'id', 'nome', 'grupo', 'ordenar_por') lack any semantic guidance.
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 does not explicitly state what the tool does (e.g., 'list products' or 'search products'). It only provides parameter constraints and a default ordering hint. The name 'buscar_produtos' suggests searching, but the lack of a clear verb+resource makes it ambiguous, especially among many sibling 'buscar_*' tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description does not indicate when to use this tool versus alternatives like 'buscar_produtos_contato' or 'buscar_grupos_produto'. There is no mention of prerequisites or context for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It reveals pagination behavior and a filter parameter, but omits other important traits such as read-only nature, authentication requirements, rate limits, or possible side effects. The partial disclosure is insufficient for safe agent use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two bullet points) but lacks a clear purpose statement. While concise, it is under-specified and does not front-load the core action. Every sentence should earn its place; here, the missing purpose sentence makes the structure inadequate.
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 9 parameters, no output schema, and no annotations, the description is highly incomplete. It fails to explain return values, other filters, sorting behavior, or the meaning of boolean flags. The agent would be unable to use the tool effectively with this minimal description.
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 only explains two parameters (cargo and indirectly pagina) out of nine. Parameters like nome, equipe_id, ordenar_por, booleans, and usuarios_ids are left undocumented. This leaves the agent without guidance on how to use most parameters.
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 lacks an explicit statement of the tool's purpose. It starts directly with observations about pagination and a filter, but does not clearly state that this tool searches for users. The name 'buscar_usuarios' implies searching, but the description should confirm the action and resource.
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 (e.g., other search or list tools). The description only gives internal behavior (pagination, filtering by cargo) but does not specify contexts, 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 provided. The description only mentions pagination and result limits, but lacks disclosure of other behaviors like read-only nature, authentication requirements, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence), which is concise, but it lacks substantive content. It is not overly verbose, but its brevity comes at the cost of 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?
With only two optional parameters and no output schema, the description should fully clarify the tool's functionality. It does not state what the tool searches for or returns, making it 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%. The description only implicitly covers 'pagina' through the pagination note, but fails to describe 'nome_cargo' or add meaning to the parameters beyond the schema.
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 does not explicitly state the tool's purpose. While the name suggests it searches for client roles, the description only discusses pagination behavior without confirming what the tool does.
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 among the many sibling tools. It does not provide 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 must disclose behavioral traits. It only says 'Buscar', implying a read operation, but does not confirm read-only nature, required permissions, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but overly minimal. It fits the tool's simplicity but sacrifices valuable information that could be added.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 0% parameter documentation, the description should compensate by explaining return format or pagination. It fails to do so, leaving the tool under-specified.
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%. The description does not mention or explain the two parameters (pagina, tarefa_id), leaving the agent with no additional meaning beyond the schema.
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 verb 'Buscar' (search) and the resource 'lembretes de email de tarefas no Ploomes CRM', but it is vague and does not distinguish from sibling tools like 'salvar_lembrete_email_tarefa'.
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 'salvar_lembrete_email_tarefa' for creating reminders. No usage 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 present, and the description does not disclose whether the tool is read-only, has side effects, or requires authentication. As a search tool, it is likely safe, but this is not stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but lacks structure. It does not front-load key information or use formatting to enhance readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, many sibling tools, and a single optional parameter, the description is insufficient. It does not explain return format, pagination behavior, or the nature of 'operacoes'.
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 (pagina) with 0% coverage in the description. The description does not mention the parameter, leaving its purpose and usage unexplained.
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 'Buscar operacoes disponiveis no Ploomes CRM', which identifies a verb (buscar) and resource (operacoes) but does not define what 'operacoes' means. Among siblings like buscar_negocio and buscar_vendas, the term is ambiguous and 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?
No guidance is provided on when to use this tool versus other search tools. Sibling tools include many similar search functions, but the description offers no context or exclusion 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. The description does not disclose any behavioral traits such as read-only nature, pagination behavior, or rate limits. The parameter 'pagina' suggests pagination but is not explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: a single sentence. However, it lacks necessary detail to be truly effective. Conciseness should not come at the expense of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and only one parameter with no description, the description is incomplete. It does not explain what relative dates are, how pagination works, or what the response looks like. More context is needed for an AI agent to use it correctly.
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 the parameter 'pagina' has no description. The tool description does not add any semantic information about this parameter. The title 'Pagina' and default value are insufficient.
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?
Description clearly states it searches for 'relative dates' in Ploomes CRM. The verb 'Buscar' (search) and resource 'datas relativas' are specific. However, it does not explain what 'relative dates' means in this context, and sibling tools do not have similar names, so uniqueness is fine but scope is vague.
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. No mention of prerequisites, context, or exclusions. The description provides no usage hints.
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 bears the full burden. It does not disclose any behavioral traits such as read-only nature, authorization requirements, rate limits, or potential side effects. The minimal description ('Search states available') implies a query but lacks transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, making it concise in length. However, it lacks essential details, so it is under-specified rather than efficiently structured. Every word adds some value, but not enough.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/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, no output schema, and no annotations, the description is severely incomplete. It does not cover pagination, filtering, or expected return format. An AI agent would have insufficient context to use this tool effectively.
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 no information about parameters. The input schema has 0% description coverage, and the description does not explain what nome, pagina, or pais_id do or how they affect the search. An AI agent would have to guess the meaning of these 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 uses a clear verb-resource structure: 'Buscar estados disponiveis no Ploomes CRM.' It specifies that it searches for states, which is distinct from sibling tools like buscar_cidades and buscar_paises. However, it does not explicitly differentiate itself from these siblings.
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. There is no mention of prerequisites, expected context, or when not to use it. The description only states the basic action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should convey behavioral traits. It does not mention read-only nature, result format, pagination behavior, or any constraints. The description adds no behavioral context beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence), which is concise, but it sacrifices necessary detail. It is front-loaded but lacks completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of output schema, annotations, and param descriptions, the description is highly incomplete. It does not explain return format, filtering logic, or pagination, leaving an AI agent with insufficient context.
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%, and the description does not explain the two parameters (nome, pagina) at all. It fails to add meaning beyond what the schema names provide.
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 states the verb 'Buscar' and resource 'paises disponiveis no Ploomes CRM', which clearly identifies the tool's purpose. The resource name distinguishes it from sibling tools like buscar_clientes or buscar_produtos, though it does not explicitly highlight the difference.
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, nor any prerequisites or context for filtering. The description is too minimal to inform usage decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides minimal behavior info: it searches for parts. It does not disclose whether it is read-only, how results are paginated (despite a pagina parameter), or any side effects. The agent cannot infer key behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one sentence), but it is underspecified for a tool with three parameters. While it has no fluff, it sacrifices completeness, requiring the agent to infer usage from parameter names alone.
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 three parameters and no output schema, the description is insufficient. It does not explain what the tool returns, how filtering works, or how to interpret the result. The agent cannot confidently use this tool without additional knowledge.
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 parameter descriptions are missing. The tool description does not explain the nome, pagina, or produto_id parameters, leaving the agent without guidance on their format or meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for parts/components of products in Ploomes CRM, distinguishing it from siblings like salvar_peca_produto and excluir_peca_produto. However, it could be more specific about the scope of what is searched (e.g., by name or product ID).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like buscar_produtos or buscar_familias_produto. The description does not mention any prerequisites or exclusions, leaving the AI agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits such as read-only nature or effects. It simply states 'search' without indicating that it is non-destructive, paginated, or what the response looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (a single sentence) but lacks structure. It front-loads purpose but does not earn its place by providing additional utility beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 optional parameters, no output schema, and no annotations, the description is incomplete. It does not explain what the tool returns, how parameters affect results, or any usage context.
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%, and the description does not explain the 'nome' or 'pagina' parameters. It adds no meaning beyond the schema, failing to compensate for the lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search contact relationship types in Ploomes CRM' clearly states the verb (search) and resource (contact relationship types), distinguishing it from sibling tools that target other entities like origins or statuses.
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 does not mention prerequisites, limitations, or why one would choose this over other search tools for contacts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose side effects, permissions, or reversibility. It only states the deletion action without behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence, which is concise, but it lacks structure and fails to provide necessary information beyond the basic 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?
The description does not mention return values, error conditions, or prerequisites. For a simple deletion tool with no output schema, more context is needed.
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% and the single parameter 'id_opcao' has no description. The tool description does not explain what the parameter identifies or how to obtain it.
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 (Excluir) and the resource (opcao de uma tabela de opcoes) within the Ploomes CRM. It is specific but does not differentiate from many sibling deletion tools with similar structure.
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, nor any prerequisites or context. The description lacks 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 exist, so the description carries full burden. It indicates a destructive action but fails to disclose details like irreversibility, permissions needed, or side effects. The agent cannot assess risk.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it is overly sparse. While front-loaded, it sacrifices necessary detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and only one parameter, the description is incomplete. It fails to provide enough context for the agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description does not explain the 'id_origem' parameter. The agent has no clue what value to provide or how to obtain it.
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 deletes a contact origin from Ploomes CRM, using a specific verb and resource. It distinguishes itself from sibling tools like 'excluir_cliente' or 'excluir_produto'.
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 when to delete versus search or save origins. No context about prerequisites or exclusions is 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 must fully disclose behavioral traits. It only states 'delete', implying a destructive operation, but fails to mention side effects, permanence, or required permissions. The description is insufficient for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise—one sentence—but at the cost of essential information. While front-loaded and efficient, it is overly terse, lacking context that would not significantly lengthen it.
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 simplicity of the tool (one parameter, no output schema), the description should provide minimal context like irreversible deletion or prerequisite existence of the association. It does not, leaving gaps in completeness.
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 single parameter 'id_associacao' has no description in the schema (0% coverage), and the tool description does not explain what this ID represents or how to obtain it. The description adds no semantic value beyond the parameter name.
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 (delete) and the resource (product-contact association). The name reinforces this. However, it does not explicitly distinguish from sibling tools like 'excluir_produto' or 'excluir_peca_produto', though the specific phrasing implies it's a unique association deletion.
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 usage guidelines are provided. The description does not indicate when to use this tool versus other delete tools, nor does it mention prerequisites or consequences of deletion. This leaves the agent without guidance on appropriate scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description does not disclose any behavioral traits such as destructiveness, permission requirements, or side effects. The name implies deletion, but the description adds no behavioral context beyond the prerequisite.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one line), which is efficient, but it front-loads a prerequisite rather than the tool's primary action. It is not verbose but sacrifices substance for brevity.
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 number of sibling tools and the simplicity of the operation, the description should state that it deletes a record and clarify what 'registro' refers to. It omits these key details, making it 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?
The input schema has one parameter with no description (0% coverage). The description only mentions finding the ID but does not explain the parameter's format or constraints, failing to compensate for the schema's lack of detail.
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 tool name 'excluir_registro' clearly means 'delete record' in Portuguese, indicating the action. The description only lists a prerequisite but does not explicitly state the tool's purpose, which is adequate but not fully helpful.
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 gives a prerequisite (find the ID first) but provides no guidance on when to use this tool versus other deletion tools like 'excluir_cliente' or when not to use it. No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but fails to disclose any behavioral traits. It does not indicate irreversibility, required permissions, side effects, or success/error responses, which is critical for a deletion tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but severely underspecified for a deletion tool. It lacks essential details, making conciseness a drawback rather than a strength.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature, no annotations, no output schema, and a bare minimum description, the information provided is grossly incomplete. The agent has insufficient context to safely invoke this 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 input schema has 0% description coverage and the tool description adds no information about the sole parameter 'id_tabela'. The agent is left without guidance on format, source, or example values for the ID.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Excluir' (delete) and the resource 'tabela de opcoes' (options table) from Ploomes CRM, distinguishing it from sibling tools like 'salvar_tabela_opcoes' which creates or updates the same resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not specify prerequisites, conditions, or mention when not to use it, such as when the table is in use or has dependencies.
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 provided, and the description only says 'criar' (create). It does not disclose whether this is an insert-or-update, idempotent, or if it requires specific permissions. Minimal behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, concise but not structured. Could be improved by front-loading key info. Not overly long, but lacks organization.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 2 required parameters and no output schema, the description is minimal. Lacks parameter explanations and usage guidelines, making it insufficient for an agent to use correctly without guessing. Incomplete given no annotations.
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%, and the description adds no meaning to parameters 'nome' and 'tabela_id'. It does not explain that nome is the option name and tabela_id identifies the table. Relies solely on minimal schema titles.
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 'criar uma opção em uma tabela de opções' (create an option in an options table), specifying the action and resource. It differentiates from listing or deleting options, but there is a similar sibling 'salvar_opcao_tabela' which is not distinguished.
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 guidelines on when to use this tool vs alternatives like 'garantir_opcoes_tabela_opcoes' or 'salvar_opcao_tabela'. Missing context on prerequisites or conditions for 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?
The description says 'Buscar' (search) implying read-only, but no annotations confirm this. It does not disclose authentication needs, side effects, or limitations. For a tool with no annotations, the description should provide more 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no extra words, but it is too brief for a tool with three parameters and no output schema. It is concise but lacks necessary detail, making it borderline average.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and 0% parameter description coverage, the description is severely incomplete. It does not explain return values, pagination behavior, or filter logic, leaving the agent with insufficient information to use the tool 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 coverage is 0%, and the description adds no explanations for parameters. While parameter names (nome, pagina, contato_id) are somewhat self-explanatory, the description fails to clarify their usage, format, or optionality beyond the schema defaults.
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 searches for products associated with contacts in Ploomes CRM. It distinguishes from siblings like 'buscar_produtos' (general product search) by specifying the association context. However, it could be more detailed about the scope of the search.
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 siblings like 'buscar_produtos' or 'salvar_produto_contato'. The description implies it's for searching associations, but does not provide when/when-not criteria or 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 must disclose behavioral traits. It lacks information about pagination (pagina parameter), optional filtering (nome), side effects, and return format. The description does not clarify that the tool is read-only or how results are paginated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise but too brief. It is front-loaded with the purpose but omits important details about parameters and usage, making it less helpful despite its brevity.
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, no output schema, and no annotations, the description is incomplete. It should explain all parameters and expected output. The current version only covers the required parameter.
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 should compensate. It only mentions tabela_id, leaving the nome and pagina parameters completely unexplained. The agent has no guidance on how to use these optional 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 'buscar' and the resource 'opcoes de uma tabela de opcoes' in the context of Ploomes CRM. It identifies the required filter (tabela_id). However, it does not differentiate from the similarly named sibling 'buscar_opcoes_tabela_opcoes', which could cause 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 usage guidance is provided. The description only states a requirement (inform tabela_id) but does not indicate when to use this tool over alternatives like 'buscar_opcoes_tabela_opcoes' or 'buscar_tabelas_opcoes'.
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 must convey behavioral traits. The verb 'buscar' implies a read-only operation, but this is not explicitly stated. The description does not mention safety, idempotency, or any side effects. For a tool that likely retrieves static status options, the description leaves the agent unsure about mutability or permissions.
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, which is concise and front-loaded. However, it is slightly too brief given the lack of other documentation. It could be expanded to include parameter info or usage context without being 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?
Considering no output schema, no annotations, and one undocumented parameter, the description is incomplete. It does not explain the return format (likely a list of status options), whether pagination is supported, or how to handle the 'pagina' parameter. The agent is left guessing about the tool's full behavior.
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 schema has 0% description coverage, and the description does not mention the parameter 'pagina'. The parameter name suggests it is a page number for pagination, but no explanation is given about its purpose, default behavior (default 1), or how to use it. The agent receives no additional meaning beyond the schema's property name.
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 (buscar) and the resource (status de contato) in the context of Ploomes CRM. It is specific enough to indicate a read operation for status options, but does not explicitly distinguish from sibling tools like 'buscar_tipos_contato' or 'buscar_origens_contato' which also fetch reference data for contacts. The name itself provides differentiation, so purpose is clear.
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 vs. other contact-related tools. There are no examples, prerequisites, or exclusions mentioned. An agent would have to infer usage from the name alone without context on alternatives or conditions.
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?
The description states it deletes a stage, implying irreversibility, but lacks details on side effects, prerequisites (e.g., if the stage can be deleted when linked to sales), or required permissions. No annotations are present to compensate.
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 that conveys the core function. However, it is too brief for a deletion tool, lacking necessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation, the description fails to explain return values, error conditions, or any confirmation. The tool is underspecified given the lack of output schema and annotations.
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 single parameter id_etapa is not described in the schema or the description; schema coverage is 0%. The agent has no information on what value is expected or how to obtain it.
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 (excluir) and the resource (etapa de pedido/venda), distinguishing it from sibling delete tools like excluir_venda. However, it could be more explicit about the scope (e.g., within a pipeline).
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 such as excluir_venda or excluir_negocio. The description does not provide context for appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states the tool deletes an option, implying destructive behavior, but does not disclose consequences such as whether deletion is permanent, cascading effects, or authorization requirements. This is minimal disclosure for a mutation operation.
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 of 7 words, achieving conciseness. However, it may be too minimal, lacking any context beyond the basic action. It is structured well for quick reading.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 param, no output schema), the description should at least explain the parameter's meaning and return behavior. It fails to do so, making it incomplete for an agent to use correctly without external knowledge.
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 schema has one parameter 'id_opcao' with 0% description coverage. The description adds no information about this parameter, leaving the agent to guess what kind of ID is needed or how to obtain it.
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 'Excluir uma opcao de numero de funcionarios do Ploomes CRM' clearly states the verb (excluir), resource (opcao de numero de funcionarios), and system (Ploomes CRM). It differentiates from sibling delete tools like excluir_cliente or excluir_peca_produto by specifying the resource type, but could be more precise about what exactly an 'option of number of employees' is.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like salvar_numero_funcionarios or buscar_numero_funcionarios. There is no mention of when not to use it or any prerequisites.
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 must convey behavioral traits. It only states the action but does not disclose irreversibility, permissions, side effects, or any constraints, which is insufficient for a deletion tool.
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 very short (one sentence, 10 words) with no unnecessary information. It is concise but at the cost of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no parameter descriptions, and no annotations, the description is insufficient for an agent to correctly invoke the tool. It does not clarify the input or behavior, and sibling tools create ambiguity.
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%, and the description does not explain the parameter id_segmento or its purpose. The parameter name is somewhat self-explanatory, but the description should explicitly link it to the segment identifier.
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 'Excluir' (delete) and the resource 'segmento/ramo de atividade' within Ploomes CRM. However, it does not differentiate from sibling tools like excluir_cliente or excluir_produto, which have similar delete actions.
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. Given many sibling delete tools, the description lacks context for selection, such as prerequisites or when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses pagination behavior ('resultado da busca eh limitado a resultados por pagina'), which is important. However, with no annotations, it fails to mention that this is a read-only operation, default page size, or any authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short with no extraneous text, but it lacks necessary details. It is concise but under-specified, earning a neutral score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 0% schema coverage, no output schema, and no annotations, the description is insufficient. It does not explain return values, filtering options beyond pagination, or error conditions. An agent would struggle to invoke this tool correctly without additional context.
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%, but the description does not explain the purpose of parameters 'id', 'nome', or 'pagina'. It only indirectly hints at pagination via the note. The agent has no information on how to use these parameters for filtering.
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 searches for webhooks in Ploomes CRM, but it does not differentiate from the sibling tool 'buscar_acoes_webhook' which might refer to actions of a webhook. The plural 'webhooks' implies listing all, but explicit distinction is missing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'buscar_acoes_webhook' or 'buscar_webhook' (singular). No prerequisite conditions or exclusion criteria 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 provided, so description bears full burden. Only states deletion, but lacks details on side effects, required permissions, reversibility, or error handling. Agent has no insight into safety or consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, no wasted words. However, conciseness does not compensate for missing crucial details. It is appropriately short but under-specified for safe invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple deletion tool with no output schema and no annotations, the description should at least mention typical outcomes or prerequisites. Lacks context on success/error responses, associated data, or integration with other sibling tools.
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?
Single parameter 'id_departamento' has no description in schema or tool description. With 0% schema coverage, description should add meaning (e.g., format, example), but it doesn't. Agent has no guidance on how to obtain or format the ID.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Excluir um departamento do Ploomes CRM', specifying the action (delete) and resource (department). This distinguishes it from sibling tools like 'salvar_departamento' or 'buscar_departamentos'.
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. No mention of prerequisites, potential restrictions, or cases where deletion might be disallowed (e.g., department with active records).
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 disclosing behavioral traits. It does not specify if deletion is permanent, whether there are cascade effects on child entities, or the authorization level required. The description only states the action without any context on implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is efficient in length. However, it severely under-specifies the tool's behavior and parameters. It earns a 3 because while it is short, it does not waste words, but it fails to provide necessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one required parameter, no output schema), the description is incomplete. It provides the basic purpose but lacks usage context, behavioral disclosure, and parameter elaboration. For a delete operation, the agent would need to know if the operation is reversible or has side effects.
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 schema has 0% description coverage for the single parameter 'id_familia'. The parameter is required but the description offers no additional meaning about its format, source, or constraints. The agent has to infer from the parameter name and title alone, which is insufficient for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Excluir' = delete) and the resource ('familia de produto' = product family) within the context of 'Ploomes CRM'. It is specific and distinguishes from sibling tools like excluir_peca_produto (delete product part) and excluir_cliente (delete client).
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 vs alternatives, nor any prerequisites or constraints. For example, it does not mention whether a product family can be deleted if it has associated products, nor what the required input format for the family ID is.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavioral traits. While it indicates a destructive action (deletion), it does not elaborate on irreversibility, authorization needs, or potential side effects like cascading deletes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence and easy to read, but it is overly brief. While concise, it sacrifices valuable detail that could improve usability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a delete operation with no output schema, the description should at least mention success/failure behavior or prerequisites (e.g., group must exist). Lacking these, it feels incomplete.
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 adds no meaning to the sole parameter 'id_grupo'. Since schema description coverage is 0%, the description should explain what the parameter represents, but it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Excluir' meaning delete) and the resource ('grupo de produto' product group) with context ('do Ploomes CRM'). It is specific and distinguishes from sibling tools like excluir_cliente or excluir_familia_produto.
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 other delete tools, nor does it mention prerequisites or consequences. Users are left 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 present, so the description must disclose behavior. It only states it is a search (read operation) but lacks details on permissions, rate limits, or response 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 concise (two sentences) and front-loaded with the core purpose. However, it is too brief given the lack of parameter explanations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 optional parameters, no output schema, and no annotations, the description is incomplete. It does not clarify search behavior, parameter usage, or return format.
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%, and the description does not explain any of the three parameters (id, nome, pagina). It adds no meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Buscar departamentos no Ploomes CRM' and specifies a use case for obtaining DepartmentId. It is specific to departments but does not explicitly differentiate from other search tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a specific use case (obtaining DepartmentId for client creation/update) but does not mention alternatives or when not to use the tool.
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 present, so the description carries full burden. It only states 'buscar' (search), implying a read operation, but fails to disclose potential side effects, access requirements, or any other 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded with the key action and resource. No redundant information is present, making it efficient.
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?
The description omits any mention of the return value, which is critical since no output schema exists. It states 'buscar o FieldKey' but does not specify whether the result is a string, object, or how it is structured, leaving the agent uncertain about what to expect.
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 provides only the parameter name and type (integer) with no descriptions (coverage 0%). The description mentions 'field_id' but adds no extra meaning, such as expected format, range, or examples, forcing the agent to infer its purpose from the tool name alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to search for the FieldKey of a field given its field_id. The verb 'buscar' (search) and the resource 'FieldKey' are specific, and it distinguishes itself from siblings like 'buscar_campos' and 'buscar_field_paths' by its unique focus on FieldKey retrieval.
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 does not mention prerequisites, typical use cases, or exclusions, leaving the agent without context for appropriate 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 provided; description does not mention that this is a read-only operation, nor does it explain pagination (though 'pagina' parameter exists) or response format. Behavioral disclosure is minimal.
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?
Description is very short (two sentences plus note), front-loads the main purpose. Efficient, but missing essential parameter details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 3 parameters, no output schema, and 0% coverage, the description is insufficient. It explains neither input parameters nor output format, leaving the agent underinformed.
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 coverage is 0% (no parameter descriptions), and the description adds no information about the parameters ('id', 'nome', 'pagina') or how to use them. The note implies 'id' might be used for filtering but is not explicit.
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?
Description clearly states the tool searches for product groups in Ploomes CRM and provides a use case (getting GroupId). However, it does not differentiate from sibling tools like 'buscar_familias_produto'.
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 note gives a specific context: use when creating or updating a product to get the GroupId. But no mention of when not to use or alternatives among siblings.
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 is responsible for behavioral disclosure. It mentions pagination and ordering but does not state whether the tool is read-only, if it modifies data, or any side effects. There is no indication of authentication requirements, rate limits, or safety profile. For a search tool, read-only behavior is likely but not confirmed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise but front-loads lengthy prerequisite steps (6 items) with emojis. While the structure is clear, the prerequisites could be condensed, and the observations add useful information. Some sentences are redundant (e.g., item 6 repeats item 4). Overall it is adequate but not streamlined.
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?
The description lacks essential context: no explanation of what data is returned, how results are structured, or how to interpret the output. With 14 parameters and no output schema, the agent needs information about search criteria, filtering behavior, and result format. The prerequisites cover preparatory steps but not the tool's actual output.
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 only indirectly references parameters like 'pagina' and 'ordenar_por' in the observations, but does not explain the purpose or allowed values of the 14 parameters. The prerequisite instructions mention that certain IDs are required, but the description does not link those to specific parameters (e.g., 'contato_id', 'negocio_id'). Most parameters remain 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 tool name implies searching records, but the description lacks an explicit statement of purpose such as 'search for records' or 'find registros'. The prerequisites and observations suggest it's used for searching, but the purpose is implied rather than clearly stated. No differentiation from sibling tools like 'buscar_tarefas' is provided.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit prerequisites instructing the agent to call other tools (buscar_contato, buscar_usuario, etc.) before using this tool, which gives clear guidance on required preparatory steps. It also explains pagination and ordering usage. However, it does not compare this tool to alternatives like 'buscar_tarefas' or specify when to use this tool versus others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions returning statuses but does not state that it is read-only, lacks behavior details like pagination or side effects, and does not disclose any risks.
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?
Two concise sentences that front-load the purpose. No unnecessary words, though it could be more structured with parameter details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is incomplete for a simple tool with one parameter. It does not explain pagination, output format, or that it returns a catalog of statuses, leaving the agent without crucial information.
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%, yet description provides no explanation of the 'pagina' parameter, its purpose, or how to use it. The description adds no value beyond the schema definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves possible approval statuses for proposals in Ploomes CRM, distinguishing it from siblings like 'buscar_proposta' which fetches actual proposals.
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, or when not to use it. The description is purely declarative without context on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions pagination and result limits, and notes when to pass the user ID. However, it does not explicitly state that the tool is read-only or disclose side effects. Without annotations, more behavioral context would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description uses bullet points and emojis for structure, making it scannable, but the prerequisite list is lengthy and could be more concise. Some information is duplicated in observations.
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 (18 parameters, no output schema, no annotations), the description lacks parameter explanations and return value details. It covers prerequisites and pagination but is incomplete for fully autonomous use.
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 18 parameters with 0% description coverage. The description only hints at a few parameters (e.g., pagina, contato_id, usuario_id via prerequisites) but fails to explain most parameters like conteudo, data_fim, localidade, etc.
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 implies the tool searches tasks but does not explicitly state its purpose. It focuses on prerequisites and observations, leaving the primary function inferred.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear prerequisites (must call other tools to get IDs) and usage observations (pagination, personal queries, type disambiguation). This helps the agent know when and how to use the tool, though it does not mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only states the purpose and that a TemplateId is obtained, but it does not mention whether the operation is read-only, the response format, pagination limits, or any safety details. This is insufficient for a tool with no annotation support.
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 very concise: a one-line purpose and a brief note. It is front-loaded and contains no fluff, though the note could be integrated into the main sentence. The structure is acceptable for a simple search tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, annotations, and parameter descriptions, the description is incomplete. It provides minimal context for an agent to understand the full behavior, response structure, or how to apply filters. Sibling tools are listed but no differentiation is offered.
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 three parameters (id, nome, pagina) with zero description coverage in the schema. The tool description does not explain what these parameters do, how they affect the search, or their expected formats. This leaves the agent unable to use the parameters correctly without prior knowledge.
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 searches for document templates in Ploomes CRM, and the note specifies its use to obtain a TemplateId when creating proposals or documents. While the name distinguishes it from the sibling 'buscar_templates_proposta' for proposal templates, the description could make this differentiation more explicit.
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 includes a note on when to use the tool ('to obtain TemplateId when creating proposals or documents'), but it lacks guidance on when not to use it or how it compares to alternatives like 'buscar_templates_proposta'. This leaves the agent with incomplete decision-making information.
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 provided, so description bears full burden. It mentions mutability but lacks details on side effects, permissions, reversibility, or what happens with missing optional fields. The relationship between 'id' and 'peca_produto_id' is confusing.
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?
Two concise sentences that directly state the function and a key usage note. No unnecessary words, but structure could be improved by front-loading the core 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?
No output schema and no annotations; description does not cover return behavior, validation rules, or relationships to sibling tools. The tool has four parameters, but only one is partially mentioned.
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 coverage is 0% and description adds no explanation for the four parameters. The text does not clarify the meaning of 'id', 'produto_id', 'quantidade', or 'peca_produto_id', leaving the agent to infer from schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it creates or updates a product part/component in Ploomes CRM, and the sibling tool 'excluir_peca_produto' indicates the delete counterpart, so purpose is well-defined.
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 vs other tools (e.g., excluir_peca_produto for deletion). The instruction 'Passe o ID para atualizar uma peca existente' is vague and does not clarify when to provide an ID versus not.
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 does not disclose whether the tool is read-only, requires authentication, has rate limits, or any side effects. It omits pagination behavior and return format, leaving significant gaps 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose with redundant instructions, an objective section, and detailed observations. It could be trimmed to a few crisp sentences. The structure is not front-loaded enough for quick parsing.
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?
With 27 parameters, no output schema, and no annotations, the description should cover output format, pagination, defaults, and error states. It lacks these, making it incomplete for an agent to fully understand the tool's behavior.
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?
Only 4% of parameters have descriptions in the schema (estado_uf). The description adds meaning for a few parameters (status, tipo, id_da_empresa_pai, id) but does not explain the many date filters, booleans, or other fields. Given the large schema, this insufficiently compensates for 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 tool searches for clients (companies or contacts) and can also search for contacts of a company. It specifies the verb and resource, but the procedural instructions muddy the clarity slightly, earning a 4 instead 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit instructions on when to use certain parameters (e.g., status only when explicit, id_da_empresa_pai for company contacts) and outlines a two-step process for finding contacts of a company. However, it does not differentiate from other search tools or provide alternatives, capping the score at 4.
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 provided, so description must cover behavioral traits. It only says 'Buscar' (retrieve), implying a read operation, but lacks details on pagination, authentication, rate limits, or side effects.
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?
Description is very concise with two sentences. No unnecessary text, but lacks structured formatting like bullet points. Could be expanded slightly for completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and lack of output schema, the description is minimally complete. It explains what the tool does and a use case, but does not describe return values or parameter behavior. Additional context would improve agent decision-making.
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 does not mention the 'pagina' parameter at all. Since schema coverage is 0%, the description fails to add meaning beyond the schema, leaving the agent unaware of pagination support.
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?
Description clearly states it retrieves repeat interval units for tasks in Ploomes CRM, with a specific use case (configuring repetition). However, it does not differentiate itself from sibling tools like buscar_tipos_tarefa or buscar_tarefas.
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?
Provides a clear usage context: 'Use para configurar a repeticao de tarefas'. But no guidance on when not to use this tool or 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?
No annotations are provided, so the description must cover behavioral aspects. It does not mention whether the search returns all results at once or paginates, what the default behavior is with empty parameters, or any rate limits. Only a basic search functionality is implied.
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: two sentences, no fluff. The key information is front-loaded. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 parameters, no output schema, and no annotations. The description only provides a minimal hint (use for OriginId). It does not explain the output format or how to interpret results; thus, it's incomplete for effective use without prior knowledge.
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 three parameters (id, nome, pagina) with no descriptions. The tool description does not explain what these parameters mean or how they affect the search. With 0% schema coverage, the description fails to compensate.
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 that the tool searches for contact origins in Ploomes CRM. It provides a specific use case: obtaining the OriginId for creating or updating a customer. This distinguishes it from sibling tools that deal with other entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a note on when to use the tool (to get OriginId), but does not specify when not to use it or mention alternative tools for other lookup needs. Some guidance is present, but it's limited.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description indicates a destructive action (delete) but does not elaborate on side effects, reversibility, or required permissions. With no annotations, the description carries full burden, yet it remains minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is very short (one sentence), making it concise but lacking structure or front-loading of key info. It is not verbose, but it is also not particularly well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with one parameter and no output schema, the description is minimally adequate but does not explain return behavior, prerequisites, or post-conditions. Could be more complete.
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 single parameter 'id_secao' has no description in the schema, and the tool description does not explain what the ID refers to, how to obtain it, or any constraints. Schema coverage is 0%, so the description should compensate but fails to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action 'Excluir' (delete) and the resource 'secao de campos personalizados do Ploomes CRM' (section of custom fields). It distinguishes from sibling tools like 'excluir_secao_formulario_pipeline' which targets pipeline form sections.
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 provided on when to use this tool versus alternatives like 'salvar_secao_campo' or 'excluir_campo'. Lacks explicit when/when-not or context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool creates only non-existing options (idempotent). No annotations exist, but it misses details like side effects, error handling, or permissions. The core behavior is stated.
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 short (two lines plus bullet points) and to the point. It could be more structured but avoids unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 0% schema description coverage, no output schema, and only a brief note about checklists, the description leaves gaps: what is a table ID? How are options formatted? Is there any limit? Incomplete for a mutating 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?
Schema description coverage is 0%, and the description provides no explanation of 'tabela_id' or 'opcoes' beyond their types. It adds no meaning to the 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 states the tool ensures a table has desired options, creating only those that don't exist. This clearly differentiates it from siblings like 'buscar_opcoes_tabela_opcoes' and 'salvar_opcao_tabela_opcoes'. The verb 'garantir' is a bit vague but context clarifies.
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 notes indicate it's useful for pre-registered options in checklists and only creates missing options. However, it lacks explicit when-not-to-use or comparisons to siblings like 'salvar_opcao_tabela_opcoes' for single option addition.
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 must fully disclose behavioral traits. It mentions the operation is a write (create/update) and that Key is returned and used for OtherProperties. However, it fails to specify if updates are destructive, required permissions, rate limits, or side effects like overwriting existing data.
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 concise, consisting of two clear paragraphs: a brief statement of purpose and numbered observations. It front-loads the main action. However, the observations could be integrated more seamlessly, and the structure is adequate but not exceptional.
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 (9 parameters, no annotations, no output schema) and many sibling tools, the description is incomplete. It covers basic operation and prerequisites but lacks parameter definitions, behavioral details, and differentiation from similar tools like 'salvar_campo_formulario_pipeline'. An agent would struggle to use it correctly without external knowledge.
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 explains only three parameters (Key, EntityId, TypeId, OptionsTableId) but leaves out others like 'ordem', 'secao_id', 'obrigatorio', and 'desabilitado' without any explanation, making it incomplete for an agent to understand all 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 tool creates or updates a custom field in Ploomes CRM, with a specific verb and resource. It differentiates from sibling tools like 'excluir_campo' and 'buscar_campos' by focusing on creation/update, but could be more explicit about its scope relative to pipeline field tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides essential prerequisites by listing tools to obtain EntityId, TypeId, and OptionsTableId. It also explains when to use the Key for updates. However, it lacks guidance on when not to use this tool (e.g., for pipeline fields) and does not mention alternatives or context of 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?
No annotations are provided, so the description carries the full burden of disclosing behavioral traits. It only states that the tool creates or updates a stage, but does not mention whether it is destructive, idempotent, requires authentication, or what the response looks like. This is insufficient for a mutation tool.
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 very concise (two sentences) with no unnecessary words. It front-loads the main purpose. However, it sacrifices detail for brevity, leaving important aspects unexplained.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, no output schema, and 0% parameter description coverage, the description is incomplete. It does not explain return values, side effects, or parameter semantics. For a tool with 3 parameters and moderate complexity, more context is needed.
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, meaning no parameter descriptions are provided. The description adds minimal meaning: it explains that 'id' is used for updates, but does not explain 'nome' (name) or 'ordem' (order). For a string parameter and an integer parameter, the description should clarify expected format or constraints.
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 'criar ou atualizar' (create or update) and the resource 'etapa de pedido/venda' (sale stage). It mentions that passing an ID updates an existing stage, which adds nuance. However, it does not explicitly differentiate from sibling tools like 'buscar_etapas_venda' or 'excluir_etapa_venda', so it lacks full distinctiveness.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a hint about when to use the tool: 'Passe o ID para atualizar uma etapa existente' implies that without an ID it creates. However, it offers no explicit guidance on when to prefer this tool over alternatives or any context about prerequisites or typical usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It states the action (create) but does not disclose behavioral traits such as whether it can overwrite existing reminders, whether it requires the task to exist, or any authentication or rate limit considerations. The observation about minutes adds minimal 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 concise with two sentences. The first sentence clearly states the purpose, and the second provides a key usage note. It is well-structured and front-loaded, with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description does not mention return values (no output schema), error conditions, or side effects. For a tool with two required parameters and no annotations, it lacks important contextual details like what the user gets back (e.g., the created reminder object) and how to handle failures.
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 only partially explains 'minutos_antes' (minutes before) but does not describe 'tarefa_id'. This leaves a parameter unaddressed, and the explanation for the other is minimal.
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 it creates an email reminder for a task ('Criar um lembrete de email para uma tarefa'). This is a specific verb+resource pairing that distinguishes it from sibling tools like 'buscar_lembretes_email_tarefa' (search) and 'salvar_tarefa' (save task). However, it could be more explicit about the uniqueness of creation versus update.
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 'Observações' note instructs the user to provide the number of minutes before the task, which gives some usage context. However, it lacks guidance on when not to use this tool (e.g., if a reminder already exists) or alternatives like 'buscar_lembretes_email_tarefa' for checking existing reminders. No prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states that the tool updates information, but does not disclose side effects, authorization requirements, error handling, or any behavioral traits beyond the obvious mutation.
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 concise with two sentences and a bullet list. It is well-structured, front-loading the purpose. No wasted words, though it could be slightly more organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update tool with 3 parameters and no output schema or annotations, the description provides basic context. It covers prerequisite and parameter format but lacks return value, error cases, and behavioral details. Adequate but not comprehensive.
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%. The description adds meaning only to the 'dados' parameter, calling it a dictionary of fields to update. The 'id_conta' and 'nome' parameters are not explained beyond their types and names, leaving their semantics partially 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 updates account information in Ploomes CRM. The verb 'Atualizar' and resource 'conta' are explicit. However, it does not distinguish from sibling tools like 'buscar_conta' or 'excluir_cliente' beyond the natural action difference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a prerequisite instruction to use 'buscar_conta' to get the ID, and explains that 'dados' is a dictionary of fields to update. However, it lacks explicit when-to-use guidance, exclusions, or alternatives beyond the single prerequisite.
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 behavioral disclosure burden. It only says 'Excluir' (delete) without mentioning whether the action is reversible, what constraints exist (e.g., cannot delete if proposal is associated with a sale), or any side effects. This lack of transparency is significant for a destructive 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 extremely concise: two sentences that front-load the purpose and the prerequisite. Every sentence adds value. There is no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with one parameter, the description covers the basic purpose and a prerequisite. However, it lacks critical behavioral context (e.g., permanence, dependencies) that would make the definition complete. The presence of related sibling tools is acknowledged, but the description does not address all information an agent might need.
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 'id_proposta' with no description (0% coverage). The tool description does not explain the parameter's format, expected values, or constraints. Since there is only one parameter and no schema descriptions, the description fails to add any meaningful semantics beyond the parameter name.
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 it deletes a proposal/quote from the Ploomes CRM. The verb 'excluir' (delete) and the resource 'proposta' are explicit. However, it does not add any unique scope or nuance that fully distinguishes it from other delete tools 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a prerequisite: first get the proposal ID using 'buscar_proposta'. This gives clear context for when to use the tool. However, it does not specify when not to use it or mention alternatives. The guidance is minimal but sufficient for a straightforward delete operation.
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 responsibility. It fails to disclose behavioral traits like read-only nature, authentication requirements, or potential errors. The description is minimal and does not add beyond the basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using two sentences plus bullet points. It is front-loaded with the main action and efficiently conveys the use case without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and minimal annotation context, the description should clarify what the tool returns (e.g., list of actions, fields). It only mentions the use case but omits output details, pagination behavior, and error handling.
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 schema has 0% description coverage for the only parameter 'pagina', and the description does not mention this parameter at all. It adds no meaning beyond the schema, leaving the parameter's purpose and format 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 searches for available actions for webhooks, specifying the verb 'buscar' and resource 'acoes para webhooks'. It also notes the use case of obtaining ActionId for creating/updating webhooks, distinguishing it from sibling tools like 'buscar_webhooks'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to use this tool to obtain the ActionId when creating or updating webhooks, providing clear context. However, it lacks guidance on when not to use it or mentions of alternatives among siblings.
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 shoulders full responsibility for behavioral transparency. It lacks details on whether the tool is read-only, destructive, or its side effects. There is no mention of pagination, return format, or error behavior, leaving significant gaps for an agent.
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 short (three sentences) with a clear title-like first sentence and two bullet points that are directly informative. Every sentence adds value, though more structured formatting could improve scanability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is insufficient. It lacks details on output structure, pagination handling via 'pagina', and the role of 'nome' parameter. A more complete description would clarify expected results and usage nuances.
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%; the description adds little beyond the schema. Only 'entidade_id' is briefly mentioned in observation 2 as a filter, but 'nome' and 'pagina' are not explained. This provide marginal additional meaning over the bare 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 states 'Buscar secoes de campos personalizados no Ploomes CRM,' which clearly identifies the action (search) and resource (sections of custom fields). However, it does not explicitly differentiate from sibling tools like 'buscar_campos' or 'salvar_secao_campo,' though the purpose is distinct enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes two observations: using it to obtain SectionId when creating custom fields, and filtering by entidade_id for specific entity sections. This provides clear context and a primary use case, but does not mention when to avoid using the tool or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It discloses pagination behavior, but does not mention read-only status, search semantics (e.g., exact match vs partial), or response structure. The pagination detail is valuable, but other behavioral aspects 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 short and structured with headers (🎯 Objetivo, 🔍 Observações) and bullet points. It is concise and front-loads the purpose. The emojis add visual separation but are not essential.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and 3 parameters with 0% schema coverage, the description should provide comprehensive guidance. It only covers pagination and the basic purpose, leaving the use of 'id' and 'nome' parameters and the output format unspecified. This creates significant gaps 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?
Schema description coverage is 0% (no descriptions in schema). The description only explains the 'pagina' parameter for pagination. It fails to describe the 'id' and 'nome' parameters, which are likely filters. For a tool with 3 parameters, the description adds minimal semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's goal: 'Buscar opções de segmentos de empresas' (search for company segment options). It uses the verb 'buscar' and identifies the resource, distinguishing it from siblings like 'salvar_segmento' (save) and 'excluir_segmento' (delete). However, it could be more explicit about the output format (e.g., returns list of segments with id and nome).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides pagination guidance: results are limited per page and the 'pagina' parameter can be used to access next pages. However, it does not give when-to-use comparisons with siblings or any prerequisites. The guidance is helpful but limited.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool returns possible statuses and lists examples, but does not mention pagination behavior, authentication needs, or response structure. The behavior is simple but not fully transparent.
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 brief (two sentences) and clearly structured: first sentence states the general purpose, second sentence lists example results. No unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one parameter, no output schema, no annotations), the description is adequate for a simple lookup but lacks details about pagination, response format, or edge cases. It meets minimum viability.
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 single parameter 'pagina' is not explained in the description despite 0% schema coverage. The description provides no context about its purpose (likely pagination), leaving the agent to infer from the name and default value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Buscar' (search) and the resource 'status de negocio' in the Ploomes CRM, and provides concrete examples of return values (Aberto, Ganho, Perdido, etc.), making the purpose immediately obvious even among many sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like buscar_razao_perda or buscar_etapas_negocio. The description does not specify appropriate contexts 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. It only states the purpose without disclosing behavioral traits such as read-only nature, potential side effects, rate limits, or authentication requirements. For a tool with 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and to the point, with no extraneous content. However, it is overly minimal and omits critical details about parameters and behavior. Conciseness is good, but at the cost of completeness.
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 presence of 3 parameters, no output schema, and no annotations, the description is insufficiently complete. It only states a single use case (obtaining TemplateId) but does not explain how to use the parameters for filtering or pagination. A more detailed description is needed to fully inform the agent.
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 makes no mention of any of the three parameters (id, nome, pagina). With 0% schema description coverage, the description adds no meaning beyond the schema. A baseline of 1 is appropriate as it fails to compensate for the lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'buscar' and resource 'templates de propostas' in the context of Ploomes CRM. The second sentence specifies the use case: obtaining TemplateId when creating proposals. This distinguishes it from other tools by being specific to proposal templates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use this tool to get TemplateId when creating proposals. While it provides clear context, it does not mention when not to use it or differentiate from similar sibling tools like buscar_templates_documentos. However, the instruction is sufficiently directive.
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 must fully convey behavioral traits. It mentions returning data and occurrence count, but does not clarify if the operation is read-only, authentication needs, rate limits, or side effects. The instruction to minimize calls is a behavioral hint but insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with bullet points and front-loaded with purpose. However, the 'Prerequisitos' section contains a guideline rather than a prerequisite, and some information could be more concise.
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 high complexity (43 parameters, no output schema, no annotations), the description is incomplete. It does not explain return format, pagination, or many filter parameters. It only covers basic usage hints.
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 only explains a few parameters indirectly (id_dono, id_produto, date format, ordering). With 43 parameters, the description provides minimal semantic help, leaving most parameters undefined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Busca vendas (orders) ativos' and returns data and occurrence count. It explicitly names the resource (vendas) and uses a specific verb (busca), distinguishing it from sibling tools that create, update, or delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context, like date format and ordering hints, and a prerequisite to minimize calls. However, it does not differentiate this tool from other 'buscar' siblings (e.g., buscar_negocio, buscar_clientes) or specify when to use this over 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, the description should disclose behavioral traits. It only indicates deletion (destructive), but lacks details on irreversibility, required permissions, or side effects.
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. It is efficient but could add more value in the same 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?
For a simple delete operation with one parameter and no output schema, the description is adequate but misses usage context and parameter details that would help 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?
The only parameter 'id_peca' has no description in the schema or the tool description. The parameter name suggests an ID, but no guidance on format or how to obtain it is given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Excluir' (delete) and the resource 'peca/componente de produto' (product part/component), distinguishing it from sibling tools like 'excluir_produto' and 'salvar_peca_produto'.
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, nor any prerequisites or context. The description simply states what it does.
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 discloses that the tool creates or updates, implying mutation, but lacks details on side effects, authorization requirements, rate limits, or what happens on conflict. The format note for custom fields helps, but overall transparency is low.
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 fairly concise, with main purpose in the first sentence and bullet-pointed observations. It front-loads the essential info. Could be slightly more structured, but overall efficient.
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 11 parameters, no output schema, and no annotations, the description is incomplete. It lacks information on return value, error handling, pagination, or any post-invocation behavior. For a complex tool with many siblings, more context is needed.
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 coverage is 0%, meaning no parameter descriptions are in the schema. The description only explains the 'id' parameter (for update) and the 'campos_customizados' format. None of the other 9 parameters are explained, leaving the agent to guess their meanings.
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 creates or updates a product in Ploomes CRM, using specific verbs and resource. It distinguishes from sibling tools like 'salvar_produto_contato' by focusing on product entity, but does not explicitly differentiate from 'buscar_produtos' or 'excluir_produto'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage guidance: pass ID for updates, and lists prerequisite tools for GroupId, FamilyId, and CurrencyId. It also specifies format for custom fields. However, it does not mention when not to use this tool or alternatives for other operations.
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 bears full responsibility for behavioral disclosure. It indicates the tool performs writes (create/update) but does not reveal important nuances: whether partial updates merge or replace fields, if the operation is idempotent, what the return value is, or any authorization requirements. The description is vague on side effects and success/failure 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 concise, using bullet points for objectives and observations. It front-loads the key actions and prerequisites. Each sentence serves a purpose, though the structure could be improved by separating create and update instructions more clearly. Overall, it is efficient and easy to scan.
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 (16 parameters, no output schema), the description is incomplete. It does not explain the return value (e.g., the ID of the created/updated task), error handling, or validation rules beyond the required parameters. The observations help with ID retrieval but omit how to handle the response or what fields are mandatory versus optional in an update 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 low (31%). The description adds some context by referencing other tools to obtain IDs for contato_id, lembrete_email_id, etc., but does not explain the meaning of each parameter beyond what the schema already provides. For example, it does not clarify the use of 'sem_horario_definido' or 'conectar_com_google_calendar'. The description does not compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the two main actions: create a new task and update an existing task. It uses specific verbs and resources ('Criar uma nova tarefa', 'Atualizar os dados de uma tarefa existente'). While it does not explicitly distinguish from siblings like excluir_tarefa or buscar_tarefas, the purpose is unambiguous and matches the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides practical guidance: use buscar_clientes to get contact IDs, buscar_usuarios for user IDs, and buscar_tarefas_extras for email reminder and repetition unit IDs. It also instructs to pass the task ID for updates. This helps the agent prepare the required IDs. However, it does not specify when NOT to use this tool (e.g., for deletion) or mention any prerequisites beyond ID lookup.
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 provided, so description carries full burden. Only states it is a 'buscar' (search) operation, implying read-only, but lacks details on pagination, filtering, or behavior beyond that.
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?
Description is short and includes a useful note about usage. However, it could be more concise by omitting the redundant 'Observações' header.
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?
Lacks details on return format, pagination, or filtering. Without an output schema, the description should explain what the tool returns.
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%, and the description does not mention any parameter. It adds no meaning beyond the parameter names (id, nome, pagina).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it searches for stages of orders/sales in Ploomes CRM, with a specific use case of obtaining StageId. It distinguishes from siblings like 'salvar_etapa_venda' and 'excluir_etapa_venda'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions using it to get StageId when creating/updating an order, providing clear context. Does not list alternative tools or when not to use, but the sibling names imply differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses default ordering behavior and revision handling. However, it does not mention permissions, rate limits, pagination behavior, error handling, or whether query is read-only. Adds some context but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is structured as bullet points, making it moderately easy to scan. However, it is verbose and includes redundant details. Could be more concise by grouping related information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (35 parameters, no output schema, no annotations), the description is incomplete. It explains revision details but does not cover pagination, output format, or how to combine multiple filters. Leaves significant gaps for an agent to use effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 35 parameters with 0% description coverage. Description explains a few parameters (descricao_entrega, Approver, sorting fields, revision fields) but many remain unexplained (e.g., localidade_cliente, metodo_pagamento, etc.). Fails to compensate adequately for 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 name 'buscar_proposta' clearly indicates search for proposals. Description explains sorting default and revision identification, distinguishing from tools like 'salvar_proposta' or 'excluir_proposta'. However, it doesn't explicitly differentiate from other 'buscar_*' tools like 'buscar_clientes'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description provides usage context: default ordering, when to use 'buscar_equipes_de_usuarios' for team filtering, and explains fields like 'descricao_entrega' and 'Approver'. It gives explicit guidance on prerequisites for team filtering.
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 must convey behavioral traits. It does not disclose whether the operation is read-only, what the return format is, or how pagination works through the 'pagina' parameter. The description only states the purpose, leaving key behavioral aspects unaddressed.
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 short and well-structured with a main line and two bullet points. It is concise, but could be improved by including the parameter information 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 existence of a pagination parameter and no output schema, the description should explain the return format and parameter behavior. It only mentions the primary usage, leaving the tool's full context incomplete for effective agent invocation.
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 contains one integer parameter 'pagina' with default 1, but the description does not mention it at all. With 0% schema description coverage, the description fails to add any meaning to this parameter, such as explaining it controls pagination.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'buscar' (search) and the resource 'tipos de campo personalizados' (custom field types). It also provides context of use: obtaining the TypeId when creating custom fields, which distinguishes it from sibling tools like 'buscar_campos' that deal with actual fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool: 'Use para obter o TypeId ao criar campos personalizados.' It provides clear context but does not mention when not to use it or list alternative tools, though the sibling list contains related tools like 'buscar_campos'.
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 must bear the full burden of behavioral disclosure. It does not mention that this is a read-only operation, nor does it address potential side effects, rate limits, or what happens if no data matches. The description only states the action and common types, lacking transparency on behavior beyond the basic fetch.
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 concise, with a clear main sentence and two bullet-point observations. It is front-loaded and wastes no words. However, it could be even more concise by integrating the observations into a single sentence, but current length is acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and 0% parameter coverage, the description is incomplete. It does not specify the structure of the returned task types, which would be necessary for an agent to use the result. Considering the tool's simplicity, more details on return format and parameter usage would improve completeness.
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 no parameter descriptions were provided in the schema. The tool description does not explain the meaning or usage of parameters (id, nome, pagina). It does not clarify how these parameters filter results or what values are expected. This is a critical gap for an AI agent to correctly invoke the tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: fetching task types from Ploomes CRM. It explicitly mentions that it is used to obtain the TypeId when creating or updating a task, and provides a list of common types. This differentiates it from sibling tools like buscar_tarefas (search tasks) and salvar_tarefa (create task).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes explicit usage guidance: 'Use para obter o TypeId ao criar/atualizar uma tarefa.' While it doesn't list alternatives or when not to use, the context is clear that this tool is specifically for getting TypeId before task creation/update. This is adequate for a simple lookup tool.
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 only says 'send for review' without detailing the effects on the proposal status, whether it triggers notifications, or if the action is reversible. More behavioral context is needed.
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 very concise (two sentences) with a clear prerequisite breakdown. It is front-loaded and efficient, though slightly too brief for full clarity. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description should provide more context about the action's impact, error conditions, and response. It only covers the prerequisite but not the complete picture.
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%, and the description only implicitly mentions the parameter by stating the prerequisite. It does not explain the format, allowed values, or additional constraints of 'id_proposta'. The meaning is partly conveyed but insufficiently.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Enviar uma proposta para revisao' (send a proposal for review) in Ploomes CRM. It uses a specific verb and resource, and distinguishes this tool from siblings like excluir_proposta and salvar_proposta.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear prerequisite: get the proposal ID using buscar_proposta. However, it does not explicitly state when to use this tool versus alternatives, nor does it specify when not to use it. The guidance is minimal but helpful.
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, and the description only states it creates a role without disclosing behavioral traits like idempotency, error behavior, or side effects. Since annotations are absent, the description should provide more context on behavior.
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 very short and to the point, with a single sentence and a note. It is concise and front-loaded with the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one required parameter and no output schema or annotations, the description is minimal. It omits explanation of the parameter and return value, making it slightly incomplete for an agent to use effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention the 'nome' parameter or explain its meaning. With 0% schema description coverage, the description should compensate, but it fails to add any semantics beyond the schema's field name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a client role in Ploomes CRM, using a specific verb and resource. It distinguishes from the sibling tool 'buscar_cargos_de_clientes' which is for searching.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a note recommending to use 'buscar_cargos_de_clientes' to check for existing roles before creating, providing explicit guidance on when to use this tool versus 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?
No annotations provided, so the description must fully disclose behavior. It describes a search operation but does not indicate whether it is read-only, pagination behavior (the 'pagina' parameter is present but unexplained), required permissions, or side effects. This is insufficient for a tool with 3 parameters and no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two short paragraphs. The main purpose is front-loaded, and the 'Observacoes' section is structured. No unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should convey what the tool returns (e.g., list of checklists). It does not mention return structure, pagination details, or how it integrates with sibling tools like 'salvar_checklist_etapa'. The context is minimal for a tool with 3 parameters and significant sibling overlap.
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?
With 0% schema description coverage, the description must add meaning. It explains 'etapa_id' and 'id' usage in the notes, but the 'pagina' parameter is not explained at all. The added information is helpful but incomplete.
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 is for searching stage checklists in Ploomes CRM using 'buscar checklists de etapas de pipeline'. It distinguishes itself from siblings like 'buscar_etapas_negocio' by mentioning it as a prerequisite, but does not explicitly contrast with all other lookup tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: use 'buscar_etapas_negocio' to get etapa_id, filter by etapa_id for stage-specific checklists, or by id for a specific checklist. However, it lacks instructions on when not to use this tool or alternatives beyond the prerequisite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It mentions pagination (results limited per page, use pagina parameter) but does not disclose whether the tool is read-only, authentication requirements, rate limits, or any potential side effects. The pagination detail is useful but insufficient for a comprehensive behavioral understanding.
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 concise with clear sections (objective, prerequisites, observations) using emojis for scannability. Every sentence serves a purpose, and there is no redundant information. It is appropriately front-loaded with the core objective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (23 parameters, no output schema, no annotations), the description is grossly incomplete. It does not describe what the tool returns (output fields), how to interpret the results, or the full range of filtering capabilities. Only pagination and prerequisites are covered, leaving the agent to guess about response structure and most filter options.
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 schema coverage is 0%, meaning the description is the only source for parameter semantics. However, the description only mentions the 'pagina' parameter, which is already present in the schema. For 23 parameters, it adds no additional meaning or context about how to use filters like contato_id, valor_acima_de, etc. This severely limits the agent's ability to use the tool correctly.
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 objective is to search for documents/contracts. It distinguishes itself from siblings by mentioning 'documentos/contratos', which is a specific category. However, it could more explicitly differentiate from similar search tools like buscar_proposta or buscar_vendas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit prerequisites: call buscar_contato for contact IDs and buscar_usuario for user IDs if provided. It also gives an observation about interpreting possessive pronouns as the responsible user. However, it does not specify when not to use this tool or suggest 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?
No annotations provided, so description carries full burden. It does not disclose behavioral traits such as read-only, pagination details, or what happens with missing parameters. Only states the basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise with two sentences, front-loaded with purpose and practical use case. No wasted words.
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?
Missing critical information: no output schema description, no explanation of parameter behavior, no pagination details, and no mention of sorting or default responses. Significant gaps for a search 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?
Schema coverage is 0% and description does not explain any of the three parameters (id, nome, pagina). The agent gets no guidance on how to use filters or pagination.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it searches product families and specifies the use case (obtain FamilyId for product creation/update). It distinguishes from sibling tools like buscar_produtos and buscar_grupos_produto.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explicitly says to use it for obtaining FamilyId when creating/updating a product, providing clear context. No exclusions or comparisons to alternatives, but the specific use case is helpful.
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?
The description does not explicitly state that this is a read-only operation, though the tool name suggests a search. With no annotations to indicate read-only or destructive behavior, the description should have disclosed that this operation does not modify data. It only says 'use to verify', which implies read-only but is not explicit.
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: one line for purpose and two short observations. Every sentence adds value: clarification of usage and parameter. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with one parameter, the description is mostly adequate. However, it lacks information about the output format (e.g., returns a list of options). Also, with sibling tools like 'buscar_opcoes_tabela', the description does not clarify the difference, leaving the agent potentially confused. The absence of an output schema means the description should at least hint at the return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only provides the parameter name and type ('Tabela Id'). The description adds that 'tabela_id é o Id da OptionsTable', clarifying the entity it refers to. This adds some meaning beyond the schema, but it's minimal and does not cover format or constraints.
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 retrieves options from a pre-registered options table, with a specific verb 'buscar'. It also provides usage context in the notes. However, it does not differentiate from the similar sibling tool 'buscar_opcoes_tabela', which may cause confusion.
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 gives explicit usage guidance: 'Use para verificar quais opções já existem antes de criar novas.' This tells the agent when to use it. However, it does not mention when not to use it or provide alternatives, such as when to use other sibling tools like 'garantir_opcoes_tabela_opcoes'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only operation with 'buscar'. No annotations are provided, so the description carries full burden. It does not detail side effects, required permissions, or response structure. It minimally indicates no destructive behavior but lacks depth.
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: one line plus a short observation. It is front-loaded and every word is useful. No unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter and no output schema, the description should at least cover the parameter's function and hint at the response format. It does neither, leaving the agent uninformed about pagination and return values.
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?
There is one parameter (pagina) with default 1, but the description does not mention it at all. Schema description coverage is 0%, so the description must compensate. It fails to explain the pagination parameter's purpose or behavior.
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 it searches for phone types available in Ploomes CRM. The observation about obtaining TypeId when adding phones adds specificity. It distinguishes from sibling tools like buscar_status_contato or buscar_origens_contato by focusing on phone types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: use this to get the TypeId when adding phones to a client. It does not mention when to avoid it or alternatives, but given the sibling tools, this is the only tool for phone types, so the guidance is sufficient.
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 must convey behavioral traits. It only states 'Excluir' (delete), which implies destruction but does not warn about irreversibility, permission requirements, or side effects. For a deletion tool, this is insufficient 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 two sentences with no wasted words. The purpose is front-loaded, followed by a prerequisite. Every sentence is necessary and concise.
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?
The tool has only one required parameter and no output schema, but the description is minimal. It lacks details about error handling, return values, or behavioral traits like irreversibility. Given the simplicity of the operation, the description is still incomplete for a safe deletion.
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%, but the description adds no meaning to the 'id' parameter beyond the schema's type 'integer'. It does not explain that the ID represents the checklist identifier or how to obtain it, though the prerequisite hints at it. The description fails to compensate for the lack of schema explanations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Excluir', to delete), the resource ('checklist de etapa de pipeline'), and the system ('Ploomes CRM'). It distinguishes from sibling tools like 'salvar_checklist_etapa' and 'buscar_checklists_etapa' by specifying deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit prerequisite guidance: 'Use buscar_checklists_etapa para obter o ID do checklist a ser excluido.' This tells the agent when to use this tool (after fetching the ID) and gives a clear context. No exclusions or alternatives are mentioned, which is acceptable for a simple delete operation.
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 deletion but offers no further behavioral details such as required permissions, side effects, irreversibility, or error handling. This is minimal disclosure.
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 short: one sentence plus a prerequisite. It avoids unnecessary fluff but could be better structured with bullet points. Overall, it is concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description provides the core purpose and a prerequisite. However, it lacks details on what happens after deletion (return value, success/failure signals) and potential errors.
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 coverage is 0%, yet the description adds no information about the id_webhook parameter beyond the prerequisite. It fails to explain the purpose, format, or constraints of the parameter, which the agent needs to know.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool deletes a webhook from Ploomes CRM. The verb 'Excluir' and resource 'webhook' are specific, and it distinguishes from other excluir_* sibling tools for different entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists a prerequisite: obtaining the webhook ID using buscar_webhooks. This gives clear context for when and how to use this tool. However, it does not mention when not to use or discuss 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?
No annotations are provided, so the description carries full burden. It discloses a create/update operation but lacks details on side effects, permissions, rate limits, or return behavior. The agent has little insight 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 concise: two sentences with no extraneous information. The first sentence states the purpose, the second adds a key usage hint. Every word 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 only 2 parameters and no output schema, the description is somewhat complete but lacks details on the 'nome' parameter, behavior when id is null, and what the tool returns. It could be more helpful for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning. It explains the 'id' parameter's role (used for updates). The 'nome' parameter remains unexplained beyond being required. This adds some value but is minimal.
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 creates or updates a contact origin in Ploomes CRM (verb and resource). It distinguishes from siblings by the specific resource, though it does not explicitly differentiate from other 'salvar' tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides basic usage guidance: 'Passe o ID para atualizar uma origem existente' implies when to use ID. However, no exclusions or alternatives are mentioned, such as when to fetch existing origins via buscar_origens_contato.
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?
Sem anotações, a descrição carrega todo o peso de transparência. Apenas menciona que é uma operação de gravação, sem detalhar efeitos colaterais, autorização ou limites. Insuficiente para garantir comportamento seguro.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
É concisa, mas sem estrutura (lista, parágrafos). A informação é curta, mas poderia ser mais clara com separação entre criação e atualização.
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?
Para uma ferramenta de mutação com 3 parâmetros, sem schema de saída e sem anotações, a descrição é insuficiente. Falta explicar valores de retorno, pré-requisitos e comportamento em caso de erro.
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?
Cobertura de descrição do schema é 0%. A descrição apenas menciona 'Passe o ID', sem explicar contato_id ou produto_id. Não adiciona significado além dos títulos do schema, que já são autoexplicativos.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Descreve claramente a ação 'associar ou atualizar' o recurso 'produto a um contato', distinguindo entre criação e atualização. Difere do sibling 'excluir_produto_contato' que é exclusão.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Indica explicitamente quando usar o ID ('Passe o ID para atualizar uma associação existente'), orientando o agente sobre o comportamento para criação vs. atualização. Não menciona alternativas, mas o contexto é claro.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose all behavioral traits. It mentions automatic handling of dynamic fields, FieldKey, FieldPathId, and DealFilterId, and notes that checklist_id is optional for updates. However, it does not state whether the tool is destructive, the return value, or error handling, leaving gaps 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 concise (about 9 lines) and well-structured: it starts with a clear purpose, then provides examples, and ends with numbered observations. Every sentence adds value, and there is no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, no output schema), the description explains the core functionality and provides parameter examples. However, it omits the return value (e.g., the created/updated checklist ID) and does not address error handling or integration with sibling tools, leaving the agent with incomplete contextual information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description adds significant meaning: it provides detailed examples for the 'itens' parameter (normal and options variants) and clarifies that 'checklist_id' is optional for updates. The other parameters ('nome', 'etapa_id') are not further explained, but the description compensates well for the most complex parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates or updates a stage checklist compatible with the Ploomes CRM front-end, which is a specific verb-resource pair. However, it does not explicitly distinguish from the sibling tool 'salvar_checklist_etapa', leaving the agent to infer the difference based on the 'completo' suffix and additional features mentioned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'salvar_checklist_etapa'. It does not specify prerequisites, context, or when not to use it, leaving the agent to rely solely on the tool name and implicit differences.
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 present. Description does not disclose side effects, required permissions, or whether the operation is idempotent. For a mutation tool, this is insufficient behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no fluff. Front-loaded with the purpose. Every word 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 the tool's simplicity (2 params, no output schema), the description covers basic create/update logic. Missing return value description and error handling, but adequate for a straightforward operation.
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 has 0% description coverage. Description explains that id is for updating an existing family, but nome is not described. Only partial value added for one of two parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'create or update a product family in Ploomes CRM', specifying the action and resource. Differentiates from sibling tools like buscar_familias_produto (search) and excluir_familia_produto (delete).
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?
Provides basic guidance: pass ID to update, omit to create. However, lacks explicit when-not-to-use or alternatives (e.g., for products, use salvar_produto instead). No mention of prerequisites or typical workflow.
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 must carry the burden. It indicates the tool is mutating (create/update) but does not disclose side effects, authorization requirements, error states, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a main sentence followed by a numbered list. It is reasonably concise, though some parameter details could be more succinct.
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?
With 16 parameters and no output schema, the description is incomplete. It addresses how to get key IDs but neglects many parameter purposes and does not describe return values.
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 coverage is 0% and the description only explains a few parameters (e.g., data_inicio format, campos_customizados format). Many parameters like valor, moeda_id, descricao, etc. lack explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates or updates a negocio (business) in Ploomes CRM. It distinguishes from sibling tools like excluir_negocio and buscar_negocio by focusing on create/update.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit prerequisites and references to other tools for obtaining required IDs (e.g., buscar_clientes, buscar_pipeline, buscar_usuarios). It also explains the update mechanism by passing an ID.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions sections organize fields visually but does not disclose behavioral traits like permissions, idempotency, or side effects beyond the basic create/update 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 short and front-loaded with purpose, followed by key observations. It is efficient but could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters and no output schema or annotations, the description lacks completeness. It does not explain entity context, order meaning, or return value, leaving significant gaps 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?
Schema coverage is 0%, so description must compensate. It only explains that 'id' is used for updating, but does not describe 'nome', 'entidade_id', or 'ordem' in detail, leaving their meaning and usage unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates or updates a custom field section in Ploomes CRM, with specific verb and resource. It distinguishes from sibling tools like 'excluir_secao_campo' (delete) and 'buscar_secoes_campo' (search).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on when to use create (no ID) vs update (with ID). It implies the context but does not explicitly exclude alternatives or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals only that the tool creates or updates, implying mutation, but gives no details on idempotency, error behavior, destructive potential, or authentication requirements. With no annotations, this lack of behavioral context is a significant gap for a mutation tool.
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 concise, with a front-loaded purpose statement followed by a bulleted list of observations. It packs useful information without unnecessary verbosity, though the list could be better organized by grouping prerequisites vs. parameter formats.
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 (18 parameters, no output schema, no annotations), the description provides decent coverage for input usage but omits return value details, error handling, and behavioral traits like idempotency. It is moderately complete but leaves several contextual 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 coverage is 0%, so the description partially compensates by explaining the format for produtos and campos_customizados, and the meaning of agente_id, comissao_percentual, and negocio_id. However, many parameters (e.g., valor, titulo, desconto, etapa_id) are left without additional semantics beyond their 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 it creates or updates a sale/order in Ploomes CRM and specifies that passing an ID triggers an update. This distinguishes it from general CRUD tools, but it does not explicitly differentiate from siblings like 'salvar_negocio' or 'salvar_proposta'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes seven explicit observations detailing prerequisite lookups for Deald, Contact, Stage, Template, etc. This provides strong context for when to use the parameters. However, it does not mention when not to use this tool or contrast it with alternative tools among siblings.
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 must disclose behavioral traits. It mentions create/update semantics but omits details like default values for optional fields, what happens on conflicting updates, permission requirements, or side effects. The agent lacks insight into destructive potential or rate limits.
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?
Description is short with bullet points for observations, making it easy to scan. However, it could be more concise by removing the redundant 'Observacoes' heading and integrating hints more tightly. Still, it is well-structured and front-loaded.
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 6 parameters, no output schema, and no annotations, the description is incomplete. It covers basic create/update logic and hints for two parameters but neglects explaining url, nome, ativo, return values, and validation rules. The agent may not understand how to fully leverage the tool.
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%, yet the description only adds meaning for id (via update usage) and action_id (via reference to another tool). It fails to explain url, nome, and ativo parameters. The entidade hint is useful but insufficient to cover the 6 parameters adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool creates or updates a webhook in Ploomes CRM, specifying the resource (webhook) and the action (create/update). It distinguishes from siblings like buscar_webhooks (list) and excluir_webhook (delete).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description provides helpful pointers: use buscar_webhooks to get existing IDs for updates, use buscar_acoes_webhook for ActionId, and clarifies that entidade is the entity name with examples. However, it does not explicitly state when not to use this tool or list alternatives beyond the ones mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it's local, non-API, non-LLM, and matches by index. It does not disclose error handling, side effects, or limitations beyond the index matching. Adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively long and includes explanations in Portuguese. While informative, it could be more concise (e.g., the last line about 'pelo mesmo motivo' adds little value). It is front-loaded with the main action.
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 no output schema, the description specifies the return 'html_final' and its usage. It covers inputs, outputs, and the matching mechanism. It lacks details on error cases, but overall provides sufficient context for correct use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains that 'html' is the agent-written HTML with <newfield> tags, and 'campos_criados' is the list from criar_campos_novos_llm with index and key. This adds practical context not present 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 defines the tool's purpose: replacing <newfield> tags with <field key> tags using keys from another tool. It specifies the source of keys (criar_campos_novos_llm) and the action (reconciliation). However, it does not differentiate from the sibling tool 'aplicar_campos_no_html_ia' beyond mentioning the same reason.
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 after criar_campos_novos_llm and notes it is local reconciliation (no API/LLM). It lists parameters but lacks explicit when-to-use or when-not-to-use guidance compared to alternatives like aplicar_campos_no_html_ia.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It implies a read-only retrieval of account data (safe operation), but does not explicitly state side effects, authentication needs, or rate limits. Behavior is implicitly clear from the action, but lacks explicit disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no wasted words. Front-loaded with the action and resource. Excellent conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval with no parameters and no output schema, the description gives a good overview of the return content. Could be improved by mentioning that it requires no inputs and is a straightforward fetch.
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?
No parameters in schema (0 params, 100% coverage trivially). Description adds value by listing the kind of data returned (nome, plano, limites, etc.), which is beyond the empty 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 it searches for Ploomes CRM account information and lists returned fields (name, plan, limits). It is specific but does not explicitly differentiate from other 'buscar_*' siblings like 'buscar_clientes' or 'buscar_negocio'.
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. It only describes what it does without any context on prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 does not explicitly state that the tool is read-only, has no side effects, or specify any behavioral traits. The description implies a lookup operation but lacks explicit disclosure of safety or consequences.
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 concise: two sentences with one bullet point. It front-loads the main purpose and provides a key usage note. Every sentence is relevant and there is no unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple lookup tool with no output schema, the description covers the essential purpose and a primary use case. However, it does not describe what the tool returns (a list of options) or any limitations. It is minimally adequate but could be more 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% (no parameter descriptions in the schema). The description does not explain the meaning or usage of the parameters (id, nome, pagina). Although parameter names are somewhat intuitive, the description should compensate for the lack of schema documentation, but it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Buscar opcoes de numero de funcionarios no Ploomes CRM' (search for number of employees options). It specifies the resource ('opcoes de numero de funcionarios') and the action ('buscar'). The note about using it to obtain NumberOfEmployeesId distinguishes it from other lookup tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a usage note: 'Use para obter o NumberOfEmployeesId ao criar/atualizar um cliente.' This provides clear context on when to use the tool (during client creation/update). It does not explicitly mention when not to use it or alternatives, but the single-use case is well-defined.
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 provided, so description carries full burden. It describes the search and pagination parameters but fails to mention side effects (expected none), default page size, or result count. Read-only nature is implied but not stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description includes unnecessary emoji and formatting (e.g., '🎯 Objetivo:', 'Args:'). While the core information is present, it could be more concise without these adornments.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no output schema, no annotations), the description covers the purpose, parameter details, and context. Missing pagination details (e.g., items per page) but adequate for a basic search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite schema description coverage being 0%, the description explicitly explains both parameters: 'palavras_chave' (list of keywords) and 'pagina' (page number). This fully compensates for lack of schema 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 that the tool returns a list of loss reasons based on keyword search, using specific verb and resource. However, it does not explicitly differentiate from sibling search tools, but the resource is unique.
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?
Provides context about CRM Ploomes and loss reasons, but no explicit guidance on when to use this tool versus alternatives, nor when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It states it deletes an automation but lacks details on irreversibility, required permissions, or cascading effects. This is insufficient for a deletion operation.
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 concise and well-structured, with a clear main sentence and a prerequisites section. Every sentence serves a purpose, and it is appropriately sized for a simple 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?
For a simple tool with one required parameter and no output schema, the description covers the basic purpose and prerequisite but lacks behavioral transparency. It is minimally 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%, and the description adds no meaning beyond the parameter name 'id_automacao'. Given the low coverage, the description should compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (excluir) and the resource (automação do Ploomes CRM), distinguishing it from sibling tools that also delete other entities. The verb and resource are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Includes a prerequisites section directing the agent to use buscar_automacoes first to obtain the automation ID. This provides clear context for when to use the tool. However, it does not explicitly state when not to use it or mention potential 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?
No annotations are provided, so the description must disclose behavioral traits. It only states 'Excluir' (delete), implying destruction, but does not mention permanence, side effects, permissions required, or cascading deletions. For a deletion tool, this lack of detail is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences stating purpose and prerequisite. It is front-loaded with the key action and avoids any unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations or output schema, the description should cover behavioral aspects and parameter details. It only covers purpose and a prerequisite, leaving out critical information like side effects, reversibility, and parameter semantics, which is insufficient for a deletion tool.
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%. The description does not explain the 'id_equipe' parameter beyond referencing how to obtain it. It does not specify format, constraints, or additional context, leaving the agent with minimal guidance for constructing valid input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Excluir uma equipe do Ploomes CRM', specifying the verb (excluir/delete) and resource (equipe/team). It is distinct from sibling tools like 'excluir_cliente' or 'excluir_produto'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a prerequisite: 'Busque o ID da equipe a ser excluida usando buscar_equipes_de_usuarios', guiding the agent to first retrieve the team ID. However, it does not provide guidance on when not to use this tool or alternatives for different deletion scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the deletion action and a prerequisite, but fails to mention potential side effects, permission requirements, or whether the operation is reversible. This is insufficient for a destructive operation.
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 concise (two sentences) and front-loaded with the purpose. However, it omits necessary details, making it slightly under-specified rather than optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description is minimally adequate but lacks behavioral transparency and parameter details. The prerequisite is helpful, but overall completeness is average.
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%, but the description adds minimal value: it implies the ID comes from 'buscar_negocio' but does not explain format, constraints, or behavior. The parameter's meaning is entirely derived from the schema's name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (excluir) and resource (negocio do Ploomes CRM), distinguishing it from sibling tools like 'excluir_cliente' or 'excluir_produto'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a prerequisite: 'Busque o ID do negocio a ser excluido usando buscar_negocio', guiding the agent on when to use this tool (after fetching the ID). It does not include explicit exclusions or alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description bears full burden of behavioral disclosure. It mentions inference behavior when destination_entity_id is absent and a default for source_entity_id, but does not state if the operation is read-only, required permissions, error handling, or output format. Lacks key transparency for a resolver tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is very concise: one purpose sentence plus two numbered observations. Front-loaded with the main action, no unnecessary words. Every 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 3 parameters, no output schema, and no annotations, the description covers purpose and parameter behavior but omits return value details and error conditions. It is somewhat complete for a simple resolver but lacks output specification needed for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must add meaning. It explains that omitting destination_entity_id triggers inference from field_key prefix, and notes the typical source_entity_id value for business checklists. This adds useful context beyond schema properties.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool's purpose: resolving the correct FieldPathId for business checklist items. The specific mention of 'checklist de negócio' distinguishes it from sibling tools like 'buscar_field_paths' which likely handle general field path retrieval.
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. Observations provide parameter hints (inference, default source_entity_id) but no when-not-to-use or conditions for selecting this tool over similar ones.
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?
Describes basic upsert behavior but lacks details on side effects, idempotency, or what happens if ID does not exist. With no annotations, more behavioral context is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two front-loaded sentences with no wasted words. Directly states purpose and usage condition for ID.
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?
Covers basic create/update distinction but omits return values, error conditions, or field constraints. For a simple tool with no output schema, additional context on behavior would improve completeness.
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?
Adds meaning for 'id' (optional for create, required for update) beyond schema. 'nome' is implied as the group name but not explicitly described. Schema coverage is 0%, so description partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool creates or updates a product group ('criar ou atualizar um grupo de produto'), distinguishing it from sibling tools like 'buscar_grupos_produto' (search) and 'excluir_grupo_produto' (delete).
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?
Implies when to use: pass ID for update, omit for create. However, no explicit mention of when not to use or comparison with sibling tools like 'buscar_grupos_produto' for retrieval.
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 bears full responsibility for behavioral disclosure. It only states the basic create/update functionality without details on idempotency, partial vs full updates, side effects, permissions, or response format. This lack of transparency leaves the agent uncertain about the tool's runtime behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with emoji-headed sections (🎯 Objetivos, 🔍 Observações), making it easy to parse. It front-loads the core purpose. However, the objectives could be combined into one line, and some observations (e.g., formatting of 'marcadores_ids') could be integrated into parameter descriptions. Overall, it is concise but not maximally efficient.
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 (9 parameters, 2 required, no output schema), the description lacks crucial information: no explanation of the 'tipo' enum values, no details on what 'descricao' does, no indication of return values. An agent would need additional context to use this tool correctly, leaving it incomplete.
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 coverage is low (11%), but the description adds meaning for 'id' (pass for update) and 'marcadores_ids' (must be a list of integers, fetched via other tools). It also implies that other IDs should be obtained from lookup tools. However, many parameters like 'data', 'tipo', 'descricao' lack explanation beyond schema types, so the description only partially compensates for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates and updates interaction records ('Criar um novo registro de interação' and 'Atualizar os dados de um registro de interação existente'). This distinguishes it from sibling tools like 'excluir_registro' (delete) and 'buscar_registros' (search), making its purpose specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on prerequisites: using 'buscar_clientes' to get contact ID, 'buscar_usuarios' for user IDs, and 'buscar_marcadores' for tag IDs. It also specifies that passing an ID updates an existing record. However, it does not explicitly state when not to use this tool or mention alternatives for similar actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool creates or updates, which implies mutation, but discloses no other behavioral traits such as required permissions, idempotency, side effects, or rate limits. The brief text leaves significant gaps for an AI agent.
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: two sentences with no wasted words. The purpose is front-loaded, and the usage guidance is efficiently delivered. Every sentence is necessary and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and low schema coverage, the description should provide richer context. It covers the basic create/update logic but omits return values, error handling, and any caveats about required permissions or data formats. For a tool in a complex CRM, this is insufficient for an AI agent to invoke it correctly without additional knowledge.
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 lacks descriptions for both parameters. The description adds partial meaning: 'id' is for update and 'nome' is required, but it does not explain constraints (e.g., character limits), relationships, or formatting. It fails to adequately compensate for the missing schema metadata.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates or updates a 'segmento/ramo de atividade' in Ploomes CRM. It uses specific verbs ('Criar ou atualizar') and identifies the resource, distinguishing it from sibling tools like 'excluir_segmento' (delete) and 'buscar_segmentos' (search).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'Passe o ID para atualizar um segmento existente' indicates that providing the ID triggers an update; otherwise, a new segment is created. However, it lacks context on when to prefer this over other tools (e.g., for simple lookups) and does not mention prerequisites like authentication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It reveals that the tool returns Id and Key, explains the Key format, and notes the default entity_id=2 for deals. However, it omits pagination behavior, rate limits, and any potential side effects, leaving 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 concise with a clear opening statement followed by four bullet points. While efficient, the bullet point structure slightly reduces fluidity; still, every sentence adds value.
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?
The tool lacks an output schema, so the description should detail return structure beyond mentioning Id and Key. It also does not cover how multiple results are handled, pagination details, or field filtering behaviors, leaving the agent underinformed for correct usage.
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?
Parameter schema coverage is 0%, so the description must compensate. It provides meaningful information for 'entidade_id' (default=2 for deals) and 'chave' (UUID format), but does not explain 'nome' or 'pagina', leaving users to infer their purpose from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches custom fields in Ploomes CRM, uses a specific verb ('buscar'), and provides distinct purpose scenarios like checking existence before creating. It implicitly distinguishes from sibling tools that create or delete fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using this tool to verify field existence before creation, establishing a clear when-to-use. It also notes the default entity_id for deals, but does not explicitly state when not to use or suggest specific alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions pagination behavior (results limited per page), which is a key behavioral trait. Since no annotations are provided, the description partially covers transparency. However, it does not state whether the operation is read-only or if it has destructive side effects, nor does it disclose any authorization requirements.
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 concise, with three bullet points covering key aspects. It is front-loaded with the pagination note. Each sentence serves a purpose, though it could be slightly more formal and directly state the tool's primary action in a single sentence.
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?
Despite moderate complexity and no output schema, the description fails to indicate what the tool returns or its structure. It also omits any prerequisites, required permissions, or error handling. This leaves the agent with incomplete information to fully understand the tool's effect and results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description carries the full burden. It explains the purpose of each parameter: 'pagina' for pagination, 'nome_da_equipe' to search by team name, and 'id_usuario_membro' to search by user ID. It also clarifies that only one of the two filters may be used. This adds significant meaning beyond the raw 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 that the tool searches teams of users, and provides filtering options by team name or user ID. It distinguishes itself from sibling tools like 'salvar_equipe' and 'excluir_equipe' which handle creation/deletion. However, it does not explicitly mention the output structure (e.g., list of teams).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives practical guidance: pagination with the 'pagina' parameter, search by team name or user ID, and a specific instruction for 'minha equipe' queries to use the logged user's ID. It does not, however, explicitly state when not to use this tool compared to other team-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It only states that the tool performs a search, implying read-only behavior, but it does not explicitly mention that it is safe, what side effects it might have, or any authentication or rate-limiting considerations. The description lacks depth in disclosing behavior 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 extremely concise: two main sentences plus two observation points. It is front-loaded with the primary purpose and immediately useful usage context, with no redundant or filler content.
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 simplicity of the tool (3 optional parameters, no output schema, no annotations), the description is incomplete. It lacks details about return format, pagination behavior (despite a 'pagina' parameter), and what happens when no filters are applied. The observations only partially address the pipeline filter.
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?
With 0% schema description coverage, the description adds some meaning for the 'pipeline_id' parameter ('Filtre por pipeline_id para ver as etapas de um funil especifico'), but it does not explain the 'nome' or 'pagina' parameters. This partial coverage provides some value but leaves gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Buscar etapas de negocios no Ploomes CRM' (search business stages). It also specifies a concrete use case: to obtain StageId when creating/updating a business, which effectively distinguishes it from sibling tools like 'buscar_etapas_venda' and 'buscar_status_negocio'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use para obter o StageId ao criar/atualizar um negocio' (Use to obtain StageId when creating/updating a business), providing clear guidance for when to apply the tool. It also mentions filtering by pipeline_id. However, it does not explicitly state when not to use or compare with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description holds the full burden. It implies read-only behavior (returns data) but does not explicitly state non-destructive nature. It mentions default ordering by last update and date format, providing some behavioral context, but lacks details on side effects, rate limits, or data freshness. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose with emojis and multiple sections (goal, useful info, prerequisites). While it is structured, it could be more concise. Every sentence adds value, but the length is not excessive. Average conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 33 parameters, no output schema, and no annotations, the description leaves many gaps. It does not explain the return structure, pagination behavior beyond a default page, or maximum results. For a search tool with many filters, more contextual completeness is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 6% (only cidade_cliente and estado_cliente have descriptions). The main description adds context for calcular_valor_total and date format, and mentions pagination with pagina default. However, most parameters remain unexplained. The description adds some value but does not fully compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Busca negócios (deals) no sistema Ploomes CRM e retorna os dados do negócio e o número de ocorrências conforme os filtros especificados.' This distinguishes it from siblings like salvar_negocio (create) and excluir_negocio (delete). The verb 'buscar' (search) and resource 'negócio' are explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides concrete prerequisites, telling the agent to use other tools (buscar_contato, buscar_pipeline, etc.) to obtain necessary IDs and to minimize calls. However, it does not explicitly state when not to use this tool or when alternatives are better, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Não há anotações fornecidas. A descrição apenas afirma que exclui um campo, mas não revela efeitos colaterais, permissões necessárias, reversibilidade ou comportamento em caso de dependências. Sem anotações, a descrição deveria fornecer mais transparência comportamental.
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?
A descrição é concisa: duas frases curtas e um pré-requisito em lista. Não há excesso de informações e a informação essencial está presente. A estrutura é direta e facilmente compreensível.
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?
Considerando a simplicidade da ferramenta (exclusão de campo customizado com um parâmetro) e a ausência de schema de saída, a descrição cobre o essencial: ação, recurso e pré-requisito. Detalhes comportamentais adicionais poderiam melhorar, mas não são críticos para uma operação simples.
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?
O schema tem um parâmetro 'chave_campo' sem descrição (cobertura 0%). A descrição menciona 'chave (Key)' no pré-requisito, sugerindo que o parâmetro é essa chave, mas não define explicitamente seu significado ou formato. Isso compensa parcialmente a falta de descrição no schema, mas poderia ser mais claro.
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?
O nome 'excluir_campo' e a descrição 'Excluir um campo customizado do Ploomes CRM' indicam claramente a ação e o recurso. Especifica que são campos customizados, diferenciando de outras ferramentas de exclusão de campos (como excluir_campo_formulario_pipeline) e de outras entidades. A descrição poderia ser mais explícita sobre que tipo de campo, mas é suficiente.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
A descrição fornece um pré-requisito explícito: usar buscar_schema para obter a chave do campo. Isso orienta o agente sobre como preparar o parâmetro. No entanto, não menciona quando não usar ou alternativas, o que reduziria o escore para 5.
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 must fully disclose behavior. It only states that the tool excludes (deletes) a document, but fails to mention irreversibility, required permissions, or any side effects of deletion.
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: two sentences with no wasted words. The purpose is front-loaded, and the prerequisite is clearly stated in a separate line.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter destructive tool, the description covers the basic purpose and a prerequisite. However, it lacks behavioral details like irreversibility and does not explain the return value (no output schema). It is minimally adequate but not comprehensive.
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 one parameter (id_documento) with no description (0% coverage). The description adds context by instructing to obtain the ID from buscar_documentos, but does not explain the parameter's format, constraints, or expected usage beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Excluir um documento/contrato do Ploomes CRM' (Delete a document/contract from Ploomes CRM). It uses a specific verb and resource, differentiating it from sibling deletion tools like excluir_cliente or excluir_negocio.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a prerequisite: first get the document ID using buscar_documentos. This guides the agent on the correct usage workflow. However, it does not specify when not to use this tool or mention alternative approaches.
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 must fully disclose behavioral traits. It states the delete action but does not mention that it is destructive, irreversible, or any specific authorization needs. For a delete tool, this lack of transparency 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 concise, consisting of two short sentences. It front-loads the main action and then lists prerequisites. No unnecessary information is present, though a bit more structure could help readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description covers the basic purpose and a prerequisite. However, it lacks important behavioral context such as irreversibility and potential effects, which are critical for a delete operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions that the ID comes from 'buscar_pipeline', which adds some context beyond the schema, but it does not explain the format or constraints of the 'id_pipeline' parameter. The added value is minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Excluir um pipeline/funil de negocios do Ploomes CRM.' It uses a specific verb ('Excluir') and resource ('pipeline/funil'), distinguishing it from sibling tools like 'salvar_pipeline' or 'buscar_pipeline'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear prerequisite: 'Busque o ID do pipeline a ser excluido usando buscar_pipeline.' This tells the agent when to use the tool (after obtaining the ID). It implicitly sets a usage condition but does not explicitly mention when not to use it or 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?
No annotations are provided, so the description must fully disclose behavioral traits. It only states 'Excluir' (delete), but lacks critical details such as whether this is a soft or hard delete, if there are cascading effects on related data, permission requirements, or undo options. The absence of such information leaves the agent uncertain about the operation's impact.
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: two sentences plus a bullet-point prerequisite. Every word adds value, with the main action stated in the first sentence and the prerequisite in the second. There is no redundancy or unnecessary detail, making it easy to scan quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema) and the absence of annotations, the description provides the minimal information needed: what it does and a prerequisite. However, the lack of behavioral transparency (e.g., irreversibility) and parameter details leaves the description incomplete for an agent to invoke it confidently without guessing about side effects.
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 has one required parameter (id_venda) with 0% description coverage. The description does not add meaning beyond the parameter name; it only mentions 'ID do pedido' in the prerequisite but does not specify format, constraints, or how to construct it. The tool's sole parameter is self-explanatory from context, but the description fails to provide additional clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool deletes an order/sale from Ploomes CRM ('Excluir um pedido/venda do Ploomes CRM.'). It uses a specific verb and resource, and while there are sibling tools for deleting other entities (e.g., excluir_negocio, excluir_proposta), the description uniquely identifies its target as 'venda' (sale), making it well-differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit prerequisite: 'Busque o ID do pedido a ser excluido usando buscar_vendas.' This tells the agent to first retrieve the ID using a specific sibling tool, which is helpful for correct tool selection. However, it does not include when not to use this tool or mention any alternative deletion pathways.
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?
Não há anotações, então a descrição deve informar o comportamento. Ela afirma que a ferramenta resume um cliente, mas não revela se é somente leitura, se há efeitos colaterais ou quais dados são processados. A filtragem por assunto é mencionada, mas o escopo do resumo é vago.
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?
A descrição é concisa, com uso de marcadores e emojis para estrutura. A informação principal vem primeiro (propósito), seguida por diretrizes e pré-requisitos. Cada frase é necessária.
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?
A ferramenta não possui esquema de saída, e a descrição não especifica o que é retornado pelo resumo (ex: texto, estrutura de dados). O pré-requisito é mencionado, mas o formato do resultado está ausente, deixando o agente sem informação sobre o que esperar.
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?
Com cobertura de esquema de 0%, a descrição adiciona significado ao explicar que o parâmetro 'assunto' filtra interações do cliente por palavra-chave e que deve ser usado apenas sob solicitação explícita. No entanto, o parâmetro 'id' não é explicado, apenas implícito como o ID do cliente da buscar_clientes.
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?
A descrição define claramente o propósito: resumir um cliente quando solicitado explicitamente. O verbo 'resumir' e o recurso 'cliente' são específicos. Embora não discrimine exatamente entre os irmãos, a menção de buscar_clientes como pré-requisito indica diferenciação.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Fornece orientação explícita sobre quando usar a ferramenta (pedido explícito de resumo), quando usar o parâmetro assunto (apenas se solicitado para assunto específico) e um pré-requisito claro (chamar buscar_clientes primeiro).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully inform behavior. It discloses that the tool is a mutating operation (create or update) and explains the condition for update (presence of ID). However, it does not detail side effects, required permissions, idempotency, or error scenarios.
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 concise with two short sentences that front-load the purpose. No superfluous words or repetition.
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 no output schema and no annotations, the description covers the basic create/update functionality. However, it lacks details on return values (e.g., the created object), error conditions, and uniqueness constraints, leaving some gaps 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?
Schema description coverage is 0%, so the description should compensate. It adds minimal meaning: 'id' is for update, and 'nome' is the name of the option. It does not explain what 'nome' represents (e.g., employee count range label) or any format constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Criar ou atualizar' (create or update) and the resource 'opcao de numero de funcionarios' (option for number of employees). It distinguishes from sibling tools like buscar_numero_funcionarios (search) and excluir_numero_funcionarios (delete) by specifying the create/update action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a basic guideline: 'Passe o ID para atualizar uma opcao existente' (pass ID to update), implying that omitting ID creates a new option. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention any prerequisites or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It discloses format requirements (ISO 8601 for data_validade, array formats for produtos and campos_customizados) but lacks details on side effects, permissions, or whether updates are full replacements.
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 concise and uses a bulleted list for observations, making it scannable. However, it could better separate main purpose from detailed prerequisites.
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 high complexity (21 parameters, no output schema, no annotations), the description is incomplete. It does not explain return values or behavior of many parameters, leaving significant gaps for the 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 coverage, the description must compensate. It explains only a few parameters (id, negocio_id, data_validade, produtos, campos_customizados) but ignores 16 others (e.g., notas, valor, titulo, desconto, moeda_id). Most parameters lack any explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates or updates a proposal/quote in Ploomes CRM. It distinguishes from sibling tools like buscar_proposta (search) and excluir_proposta (delete).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to provide an ID for updates and lists prerequisites (buscar_negocio, buscar_clientes, buscar_templates_documentos). It provides context but no explicit 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 must convey behavioral traits. It only mentions 'create or update' but omits details on side effects (e.g., what happens to omitted fields), required permissions, or rate limits. This is insufficient for a write operation.
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 concise and well-structured: main purpose, update condition, and a list of observações. Each sentence serves a purpose, though a brief note on optional fields could improve it without adding much length.
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?
With 8 parameters, no output schema, and no annotations, the description should provide more context on parameter behavior, return values, and error scenarios. The current description only covers the basic workflow and prerequisites, leaving significant gaps for an AI agent to invoke correctly.
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%. The description only references three parameters (id, perfil_id, cargo_id) through observações but does not explain the meaning or constraints of other parameters like nome, email, facebook, linkedin, or telefone. The schema alone does not provide enough context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates or updates a user in Ploomes CRM, with a specific instruction on using ID for updates. This distinguishes it from siblings like salvar_cliente or salvar_produto, which target different entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists three sibling tools (buscar_usuarios, buscar_perfis_usuario, buscar_cargos_de_clientes) needed to obtain required IDs, providing clear guidance on prerequisites and when to use alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It states what is returned (automation with trigger and actions) but does not disclose pagination behavior, rate limits, or whether the operation is read-only. The description is straightforward but lacks depth for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is structured with a main line followed by numbered observations. It is relatively concise for the information provided, though could be slightly shorter. The main purpose is front-loaded.
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?
No output schema exists, so description should explain return value; it does so minimally ('Retorna a automação com o gatilho e as ações configuradas'). For a search tool with 6 parameters, more detail on filtering behavior, defaults, or sorting would improve completeness. Sibling tools exist for translation, but the description references them adequately.
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 description must compensate. It explains entidade_id and etapa_id in observations, but does not add meaning for id, nome, pagina, or habilitada. With 6 parameters, only 2 are partially explained, leaving gaps for the other 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool searches for automations (funnel or general) in Ploomes CRM and returns them with trigger and actions. It distinguishes from sibling tools like buscar_gatilhos_acoes_automacao by focusing on retrieving automations rather than translating IDs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides specific guidance on how to use parameters: entidade_id mapping to entity types, etapa_id for funnel stage filtering, and references to other tools for translation (buscar_schema, buscar_pipeline, buscar_gatilhos_acoes_automacao). However, it does not explicitly state when not to use this tool or compare with 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?
No annotations are provided, so the description carries full burden. It does not disclose behavioral traits such as read-only nature, required permissions, or any side effects, which is insufficient for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: one sentence plus two bullet-point notes. It is front-loaded with the main purpose and includes only essential information with no wasted words.
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 explains the primary use case (obtaining CityId for client creation/update) but lacks details on response format, pagination via 'pagina', and the 'id' parameter. For a tool with 5 parameters and no output schema, more completeness is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage. The description adds meaning for three parameters (nome, estado_nome, pais_nome) as filters, but does not clarify the 'id' parameter for direct lookup or 'pagina' for pagination, leaving some semantics unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches cities in Ploomes CRM and specifically notes it is used to obtain CityId when creating/updating clients, distinguishing it from sibling tools like buscar_paises and buscar_estados.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use this tool to get the CityId when creating/updating a client and suggests filtering by city name, state, or country. It provides clear context but does not mention when not to use it or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It states the tool is a search operation returning entities supporting custom fields, but lacks details on pagination, authentication, or what exactly is returned beyond examples. It is adequate but not rich.
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 concise (two sentences plus notes) and front-loads the main purpose. Minor formatting improvement could integrate notes, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list retrieval tool with one optional parameter and no output schema, the description covers main purpose and usage. However, it does not explain pagination behavior or return format, leaving 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?
Input schema has one parameter 'pagina' with 0% description coverage. The tool description does not mention this parameter or its purpose, failing to add value beyond the schema's default and type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's verb ('buscar' - search) and resource ('entidades disponiveis para campos personalizados') with specific purpose: obtain EntityId for custom fields. It distinguishes from sibling tools like 'buscar_campos' and 'salvar_campo' by focusing on entity retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use: 'Use para obter o EntityId ao criar campos personalizados.' It provides context but does not explicitly mention when not to use or compare with alternatives, though the purpose is sufficiently specific.
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 must disclose all behavioral traits. It only states the purpose and a note about entity_id, but omits whether the operation is read-only, requires authentication, or has side effects. The lack of behavioral details 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 brief and well-structured: a primary sentence, followed by bullet-pointed observations. Every sentence adds value, and the most important information is front-loaded.
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 1 parameter, no output schema, and no annotations. The description covers the purpose, parameter meaning, and a use case, but does not explain the output format or error scenarios. Given its simplicity, it meets minimum viability but lacks completeness.
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 description must compensate. It adds meaning by noting that entity_id=2 corresponds to Deal, but does not explain other possible values or format. This provides partial clarity, enough to lift from baseline 1 to 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for available FieldPaths from an entity in Ploomes CRM, and clarifies that entity_id=2 represents Deal. This distinguishes it from siblings like buscar_field_key_por_field_id, which targets a specific field key.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using this tool to investigate possible paths before building checklist items, providing a clear use case. It does not explicitly mention when not to use it or list alternatives, but the given scenario offers sufficient guidance for a focused tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It implies read-only operation ('buscar'), but does not explicitly state safety, idempotency, or authentication requirements. Adequate but not thorough.
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?
Description is concise, with main purpose upfront and bullet-pointed observations. No fluff, but could benefit from structured sections.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 param, no output schema), explanation of trigger/action IDs and RestrictedEntityId is good. However, missing parameter description and output format details reduce completeness.
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 has one parameter 'pagina' (integer, default 1) with 0% schema description coverage. The tool description does not explain this parameter, leaving users unaware of pagination behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it fetches available triggers (TriggerId) and action types (ActionId) for automations in Ploomes CRM. It specifies the returned elements and distinguishes from sibling tools like 'buscar_automacoes' which list automations themselves.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage tips: how to use the returned TriggerId and ActionId with 'salvar_automacao', and explains the meaning of RestrictedEntityId. Lacks explicit when-not-to-use instructions, but sufficient for a lookup tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It mentions the 7-day range constraint but lacks details on whether the tool is read-only, required permissions, error handling, or return format. The description adds some useful context but is insufficient for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, using three short sections with emoji headers. Each sentence serves a purpose: objective, prerequisites, and observations. No unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters, no output schema, and no annotations, the description is incomplete. It covers the purpose and one constraint but omits parameter details, return values, error cases, and the meaning of 'available times' in the context of the system.
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 coverage is 0%, yet the description only indirectly clarifies 'usuarios_ids' and 'equipe_id' via prerequisites. Other parameters like 'duracao_em_minutos' and 'incluir_usuario_logado' are not explained. The description fails to compensate for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Buscar horários disponíveis em um período de tempo' (search for available times in a period). The verb 'buscar' and resource 'horários disponíveis' are specific and distinct from siblings, which focus on CRUD operations on other entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides prerequisites, instructing the agent to call 'buscar_usuario' and 'buscar_equipes_de_usuarios' when user or team IDs are needed. It also notes the maximum 7-day range. However, it does not explicitly state when not to use this tool or mention alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not explicitly state that the tool is read-only or safe. While 'buscar' implies a search, the description lacks disclosure of side effects, authentication needs, or pagination behavior beyond the parameter name.
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 concise, front-loads the purpose, and uses bullet-pointed observations. Every sentence adds value without unnecessary fluff.
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 is simple, but the description lacks details about return format (e.g., list of objects with id, name, code) and pagination handling. While annotations are absent, the description could be more complete given the absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It adds meaning for 'nome' and 'codigo' by mentioning filters by name or ISO code, but does not explain the 'pagina' parameter (page). Partial coverage leaves room for improvement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches available currencies in Ploomes CRM and specifies the use case of obtaining CurrencyId. The tool is unique among siblings (no similar currency lookup tools), making its purpose distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using this tool to get CurrencyId when creating/updating entities, and mentions filtering by name or ISO code. It does not provide alternatives or when-not-to-use, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description discloses filtering behavior (when nome_pipeline is omitted, all pipelines are returned; similarly for nome_etapa). However, it does not explicitly state that the operation is read-only (though implied by 'busca'), and the 'id' parameter present in the schema is missing from the description. No mention of authentication, rate limits, or response format.
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?
Description is concise with a clear objective and bullet-like argument list. No unnecessary text, and the emoji adds visual clarity without bloat.
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 no output schema and no annotations, the description should compensate. It explains the purpose and most parameters but omits the 'id' parameter and does not describe return structure, pagination behavior beyond page number, or output format. This is adequate but incomplete for a listing tool with 4 parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description carries full burden. It covers 3 of 4 parameters (pagina, nome_pipeline, nome_etapa) with clear explanations of purpose and default behavior. The missing 'id' parameter is a gap, but the provided descriptions add significant meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool searches for a list of pipelines/funnels in Ploomes CRM, with a specific verb ('busca') and resource ('lista de pipelines / funis'). It is distinguishable from sibling tools like 'salvar_pipeline' (save) and 'excluir_pipeline' (delete).
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 (e.g., salvar_pipeline for creation, excluir_pipeline for deletion). The description only explains functionality but does not provide context for selection among siblings.
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 exist, so the description carries full burden. It only states the parameter and possible values, but does not disclose whether the operation is read-only, requires authentication, has rate limits, or describes the response format. Minimal disclosure.
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 very concise with two clear sections (objective and parameters), no filler, and the objective is front-loaded. Every sentence adds value.
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 covers the parameter well but omits what the response contains (e.g., field definitions, types). Given no output schema, this is a gap. It is adequate for basic usage but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for the 'entidade' parameter. The description adds concrete possible values (Contacts, Users, Deals, Tasks, InteractionRecords, Tags), which significantly aids understanding beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Buscar o schema de uma entidade' (search the schema of an entity) and specifies the system (Ploomes CRM). It distinguishes from sibling tools that search actual records (e.g., buscar_clientes) by focusing on schema retrieval.
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 when needing entity structure, but does not explicitly state when to use or avoid, nor mention alternatives. No exclusions or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must cover behavioral traits. It only says 'Excluir', indicating a destructive action, but does not disclose whether deletion is permanent, if cascading effects occur, or if special permissions are required. This is a significant gap for a deletion tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences with no redundant information. It front-loads the purpose and immediately provides the prerequisite, achieving high efficiency.
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 it is a simple destructive tool with one parameter and no output schema, the description covers the essential context: what it does and the prerequisite step. However, it lacks behavioral details such as irreversibility, which would be helpful for an agent. It is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no descriptions in the input schema). The description does not explicitly add meaning to the parameter 'id_cliente', but the prerequisite step ('Busque o ID do cliente') provides implicit context that this ID comes from a prior search. With a single, self-explanatory parameter, the lack of explicit detail is marginally acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function as 'Excluir um cliente/contato do Ploomes CRM', using a specific verb (Excluir) and resource (cliente/contato). It distinguishes from siblings like 'buscar_clientes' and 'salvar_cliente', which are search and save operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit prerequisites: 'Busque o ID do cliente a ser excluido usando buscar_clientes.' This guides the agent on when to use the tool (when the correct ID is obtained) and implies that it should not be used without a valid ID. However, it does not mention when not to use it (e.g., if deletion is irreversible) or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behaviors: idempotency (reuse existing field), conditional creation of table/options for tipo_id=7, and return of field_id and field_key. This adds useful context beyond what annotations could provide, though it omits permissions or rate limits.
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 concise (3 lines in observations) and front-loaded with the main purpose. The bullet-point format enhances readability. It earns its place without unnecessary verbosity, though slightly more structure (e.g., parameter details) would improve it.
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 explains return values (field_id, field_key) in lieu of an output schema, and addresses the key scenario for tipo_id=7. However, it lacks details on validation, prerequisites (e.g., permissions), or how parameters like 'obrigatorio' affect behavior. Given the tool's complexity (7 params, no output schema), the description is 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?
The input schema has 7 parameters with 0% description coverage, so the description must compensate. It only adds value for 'tipo_id=7' (explaining pre-creation of table/options), and mentions required parameters (nome, entidade_id, tipo_id). However, it fails to explain optional parameters like 'obrigatorio', 'tabela_opcoes', 'tabela_opcoes_id', and their relationships, leaving significant ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: ensuring a dynamic field ready for use in a checklist in Ploomes CRM. It uses a specific verb ('garantir') and resource ('campo dinâmico para checklist'), and distinguishes itself from siblings by targeting checklist-specific fields, as evidenced by the observations about reuse and type_id=7 handling.
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 does not provide explicit guidance on when to use this tool versus alternatives like 'salvar_campo' or 'buscar_campo_dinamico_existente'. It mentions reuse if the field already exists, but lacks exclusions or when-not-to-use information. The context signals show many sibling tools with similar field operations, making this gap significant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies mutation ('Criar ou atualizar') but lacks details on side effects, required permissions, error handling (e.g., what if ID does not exist), or idempotency guarantees. With no annotations, the description carries the full burden, and it does not fully disclose 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a single sentence stating the purpose followed by two bullet-pointed notes. No unnecessary words. It is well-structured and front-loaded.
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 lack of output schema and annotations, the description is adequate but incomplete. It does not describe the return value (e.g., does it return the saved option?), error conditions (e.g., missing table), or any constraints. For a mutation tool with 4 parameters, more detail would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It adds meaning for 'id' (used for updates) and 'ordem' (defines position). However, it does not describe 'tabela_id' or 'nome', though 'nome' is self-explanatory. Overall, the description adds some value but not for all 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: 'Criar ou atualizar uma opcao em uma tabela de opcoes no Ploomes CRM.' It specifies the action (create/update) and the resource (option in an options table). However, it does not differentiate from sibling tools like 'salvar_tabela_opcoes' or 'garantir_opcoes_tabela_opcoes', which have similar purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The notes provide practical guidance: 'Passe o ID para atualizar uma opcao existente.' and 'A ordem define a posicao da opcao na lista.' This tells the agent when to use create vs update and how to control ordering. It does not explicitly state when not to use or compare to alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description only mentions a filter (Dynamic=true) but does not explicitly state that the tool is read-only, require permissions, or disclose other behavioral traits. As a search tool, read-only is implied but not confirmed.
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 very concise: two sentences plus two bullet points. It front-loads the main purpose and adds relevant notes without unnecessary words.
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 no output schema, the description should explain what the tool returns (e.g., list of fields). It does not mention return format or content. For a CRM search tool, this is a gap. However, the sibling set provides context for the ecosystem.
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%. The description does not explain any of the three parameters (nome, tipo_id, entidade_id). While parameter names are somewhat self-explanatory, the description fails to add meaning or clarify optionality (tipo_id) and usage context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches for an existing dynamic field ('campo dinâmico') in Ploomes CRM, using a specific verb and resource. It also mentions filtering by Dynamic=true, distinguishing it from generic field search tools like 'buscar_campos'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: 'Útil antes de montar checklists para reaproveitar campos já existentes' implies when to use it. However, it does not explicitly state when not to use or mention alternatives, though siblings imply alternatives exist.
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 must carry the full burden. It only states the tool removes a field, but does not disclose consequences, required permissions, reversibility, or side effects. For a destructive operation, 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 two sentences: one for the action and one for the prerequisite. It is concise, front-loaded with key information, and contains no unnecessary words.
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 has only one parameter and many siblings, the description adequately states the purpose and provides a key prerequisite. It could mention that the field must exist or specify return values, but overall it is sufficient for a simple deletion 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 coverage is 0% as the description does not mention the parameter. However, it indirectly explains that the 'id' parameter is the field ID obtained via another tool. The compensation is partial, as it does not describe the parameter type or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool removes a field from a section of the business form of a pipeline. It distinguishes from sibling tools like 'excluir_secao_formulario_pipeline' which removes a section, and 'excluir_campo_formulario_proposta' which removes a field from a proposal form.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a prerequisite to use 'buscar_formulario_pipeline' to obtain the field ID. This gives clear context on when to use the tool, but it does not explicitly state when not to use it or compare with 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?
No annotations are provided, so the description carries the full burden. It states 'Excluir' (delete) which is destructive, but does not disclose whether the deletion is irreversible, if there are any side effects on related data, or if special permissions are required. For a deletion tool, 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 very concise: two sentences and a prerequisite list. It is front-loaded with the purpose and gets straight to the point without any unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with one parameter and no output schema, the description covers the core purpose and prerequisite. It could mention whether the deletion is reversible or any error conditions, but given the simplicity, it is largely adequate.
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?
There is one parameter 'id_marcador' with 0% schema coverage. The description does not explain the parameter but advises to obtain it via 'buscar_marcadores', which provides some context. However, it adds minimal semantic value beyond the parameter name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Excluir um marcador/tag do Ploomes CRM', specifying the verb (excluir) and resource (marcador/tag). This distinguishes it from sibling tools like 'excluir_cliente' or 'excluir_produto'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a clear prerequisite: first use 'buscar_marcadores' to obtain the ID. This tells the agent when to use this tool and what prior step is needed. It does not explicitly mention when not to use it, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must convey behavioral traits. It implies a destructive action but does not disclose permanence, side effects, or authorization requirements. The prerequisite hint adds some context, but overall depth is limited.
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 short and front-loaded with the core action. It uses two sentences effectively, though the prerequisite could be integrated more concisely. No excess verbiage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter delete tool, the description covers the essential action and a key prerequisite. However, it omits return value or error handling. Given the tool's simplicity, it is reasonably 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 coverage is 0%, and the description does not elaborate on the id_produto parameter beyond its name. It only links it to buscar_produtos, leaving format and constraints unspecified. The description fails to compensate for the lack of schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool deletes a product from Ploomes CRM, directly matching its name and resource. It distinguishes from siblings like excluir_peca_produto by specifying the resource as 'produto'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides a prerequisite: obtain the product ID using buscar_produtos. This guides correct usage, though it does not mention when to avoid using the tool or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It clarifies create/update behavior but does not mention side effects, permissions, rate limits, or return values. The mutation nature is implied but not elaborated.
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 concise with a clear main sentence followed by bullet-point observations. It is front-loaded with the primary purpose and uses minimal wording. Every sentence adds value.
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 12 parameters, no output schema, and no annotations, the description is insufficient. It fails to explain the return value, behavior on success/failure, or provide context for most parameters. The tool is moderately complex, but the description only partially addresses the 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 description must add meaning. It explains the semantics of ID (create vs update), contato_id (from buscar_clientes), template_id (from buscar_templates_documentos), and the format for campos_customizados. However, it ignores other parameters (valor, titulo, etc.), leaving them unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates or updates a document/contract in Ploomes CRM, with the distinction of passing an ID for updates. This distinguishes it from sibling tools like buscar_documentos (list/search) and excluir_documento (delete).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides three observations that guide prerequisite usage: obtaining ContactId from buscar_clientes, TemplateId from buscar_templates_documentos, and the format for campos_customizados. It implicitly covers when to create vs update (via presence of ID). However, it does not explicitly mention when to use this tool versus reading or deleting documents.
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?
Sem anotações, a descrição não informa efeitos colaterais, permissões, limites de taxa ou tratamento de erros, focando apenas na ação básica de criar/atualizar.
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?
A descrição é concisa e direta, com propósito claro no início e observações relevantes, embora pudesse ser mais estruturada (ex.: usar marcadores).
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?
Cobre o uso essencial e dependências, mas falta informação sobre valores de retorno, cenários de erro e comportamento detalhado, adequado para um escopo moderado.
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?
Com cobertura de esquema de 0%, a descrição explica o significado de cada parâmetro (id para atualização, nome para nome da equipe, usuarios_ids como IDs de membros) e como obtê-los, superando a falta de detalhes no esquema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Descreve claramente a função de criar ou atualizar uma equipe no Ploomes CRM, distinguindo-se das ferramentas irmãs 'excluir_equipe' e 'buscar_equipes_de_usuarios' ao mencionar o uso desta última para obter IDs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explica quando usar (criar ou atualizar) e fornece pré-requisitos nas observações, mas não aborda explicitamente quando não usar ou alternativas.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states it creates or updates, which implies mutation but does not disclose further behavioral details such as idempotency, required permissions, or side effects. Since no annotations are provided, the description carries the full burden; it is adequate but not comprehensive for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a main sentence followed by bullet points with key observations. Every sentence provides useful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately covers purpose and key parameter hints, but does not describe the return value (e.g., does it return the created/updated tag?). This omission leaves the agent uncertain about the tool's output format.
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 4 parameters with 0% coverage. The description explains the 'id' parameter (pass to update) and 'entidade_id' (with mapping), but does not explain 'nome' or 'cor' beyond their schema titles (which are self-explanatory, but the description adds no extra context). It adds value for some parameters but not all.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Criar ou atualizar um marcador/tag no Ploomes CRM.' It specifies the verb (criar/atualizar) and resource (marcador/tag), and differentiates from sibling tools like 'buscar_marcadores' and 'excluir_marcador' by mentioning how to obtain the ID for updates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on when to use this tool (create or update) and explicitly advises using 'buscar_marcadores' to get the ID for updates. It also includes a mapping for 'entidade_id' values (1=Clientes, etc.), which helps the agent use the parameter correctly. However, it does not give explicit 'when not to use' instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states creates/updates based on ID presence, but lacks details on write behavior (e.g., partial vs full overwrite), response output, permissions, or side effects. Moderate 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?
Front-loaded with purpose, followed by bulleted observations. Efficient without waste. Could improve structure by grouping related parameters, but overall concise and readable.
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 36 parameters, no output schema, and no annotations, the description covers purpose and some prerequisite workflow but omits return value, error handling, and many parameter details. Adequate but has 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 coverage is 0%, but description adds meaning for a few parameters via observations (e.g., tipo_id, cidade_id, data_nascimento, cnpj, cpf, campos_customizados). However, many of the 36 parameters (e.g., skype, facebook, website) are unexplained. Partial compensation; missing many.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool creates or updates a client/contact in Ploomes CRM, distinguishing it from sibling tools like excluir_cliente, buscar_clientes, etc. The verb+resource is specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Eight observations explicitly list prerequisites and when to use other tools (e.g., buscar_clientes for ID, buscar_tipos_contato for TypeId) and format requirements for data_nascimento, cnpj, cpf, campos_customizados. Provides excellent guidance for correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states the core behavior (create/update) but lacks details on side effects, permissions, error conditions, or what happens if the ID does not exist. The behavior is clear but minimally transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, directly to the point, with no extraneous information. It is efficiently structured and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (two parameters, no output schema), the description adequately covers its purpose and usage distinction. It could mention return values or potential effects, but it is mostly complete for a basic upsert operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description adds value by clarifying that 'id' is for updates and 'nome' is always required. However, it does not explain the exact meaning of 'nome' (though it is obvious from the name) or any constraints beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates or updates a department in Ploomes CRM. It distinguishes itself from sibling tools like 'buscar_departamentos' (search) and 'excluir_departamento' (delete) by being the only upsert tool for departments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: pass an ID to update an existing department, implying omitting ID creates a new one. It does not, however, explicitly state when not to use this tool or mention alternatives beyond the implicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains the conditional logic for filter creation based on the checklist name (three cases). However, it does not disclose side effects, authentication requirements, or what the tool returns. The behavioral context is moderate but not exhaustive.
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 concise: two sentences and a bullet list. Every sentence adds value, and the structure is front-loaded with the main purpose before the observations. No waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description adequately covers the filter creation logic. However, it could briefly mention the purpose of the filter (e.g., used in checklists) or any prerequisites. Still, it is sufficiently complete for an agent to understand and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides minimal info (name and type for 'nome_checklist'). The description adds significant meaning by explaining how the parameter value determines the filter logic (three cases). This compensates for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool creates the default filter used by step checklists in Ploomes CRM. It provides specific behavior for different cases (Pessoa Física, Empresa, others), which distinguishes it from similar tools like 'salvar_checklist_etapa' that likely save the entire checklist.
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 (creating filters for checklists) but does not explicitly state when to use this tool versus alternatives. No exclusions or alternative tool names are provided. For example, it doesn't mention when 'salvar_checklist_etapa_completo' might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that template_id automatically resolves to form_id and mentions ordering behavior. However, it does not discuss side effects (e.g., overwrite vs. update), authentication needs, or what happens if parameters conflict. The behavioral disclosure is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a main sentence and numbered observations. It front-loads the core purpose. While a bit lengthy, every sentence adds value. Minor redundancy in explaining 'template_id resolve o form_id automaticamente' could be trimmed.
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 no output schema and no annotations, the description covers the tool's purpose, usage flow, and parameter semantics. It lacks information about return values, error handling, or what happens if template_id is invalid. However, for a tool with 6 optional parameters, it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 6 parameters with 0% description coverage. The description adds meaning to each: id for update, nome for section name, oculta likely for hidden state, form_id/template_id for creation, ordenacao for position. It explains template_id resolves to form_id. This compensates well for the schema's lack of 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 states the tool creates or updates a section in a proposal/sale/document form template, specifying it is a grouping of simple fields, not a product block. This is clear and specific, but does not explicitly differentiate from sibling tools like salvar_secao_campo for other contexts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly explains when to use the tool: pass an ID to update, provide template_id or form_id to create. It references sibling tools (buscar_templates_documentos, buscar_formulario_proposta, salvar_campo_formulario_proposta) and explains the ordenacao parameter behavior. This provides excellent usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool performs a read operation ('Buscar'), describes the nature of the returned fields, and warns about potential variation in integer meanings. It does not mention authentication or rate limits, but the read-only intent is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with paragraphs and bullet points, front-loading the purpose. It is slightly longer than necessary but remains informative. Every part adds value, though the observational notes could be more concise.
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 lack of an output schema, the description adequately explains what the tool returns (summary of modules and scope). It also references a sibling for full permissions. The tool has only three parameters, and the description covers the main usage flow, making it sufficiently complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It adds context about the Id field (usage in other tools) and mentions that nome and pagina exist, but does not explain their semantics in detail. The baseline of 2 for low coverage is increased to 3 because the description provides some functional context, though parameter-specific details are missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's verb ('buscar') and resource ('perfis de usuário'), and provides specific detail on what it returns (summary of enabled modules and visibility scope). It also distinguishes itself from sibling tools like salvar_perfil_usuario by explaining how the returned Id is used.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (to search for user profiles) and how to use the returned data (for salvar_perfil_usuario or salvar_usuario). It also provides observational notes about the integer fields, but does not explicitly state when not to use it or give alternatives beyond the sibling reference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It describes a read operation and mentions the output values, but does not disclose pagination behavior, rate limits, or any side effects. The description is adequate for a simple lookup but lacks behavioral depth.
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: two sentences and a bullet point. It states the main purpose and the primary use case without any filler. Every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema), the description covers the core use case well. However, it could mention that results are paginated or list-like, but for a basic lookup it's nearly 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%; the only parameter 'pagina' is not mentioned in the description. The description focuses solely on the output mapping (TypeId) and ignores the pagination parameter. With zero coverage, the description fails to compensate, leaving the agent unsure about how to use the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool retrieves contact types ('Buscar tipos de contato') and specifies the exact use case: obtaining TypeId when creating or updating a client, with a mapping (1=Empresa, 2=Pessoa). This effectively differentiates it from sibling tools like 'buscar_clientes' or 'salvar_cliente'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The observation explicitly tells when to use the tool: to get TypeId during client creation/update. It provides the specific values (1 and 2) and their meanings. This gives clear, actionable guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool removes a field (destructive), but does not explicitly state if the action is irreversible, requires specific permissions, or affects related data. It adds context about the field being from a form section and the tool being new, but lacks deeper behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections, front-loaded purpose, and only necessary details. It could be slightly more concise, but every sentence adds value, including prerequisites and exclusions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter, no output schema), the description covers purpose, usage, and alternatives. It does not mention side effects on collections or return values, but the core decision-making context is sufficient.
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?
With 0% schema description coverage, the description must compensate. It implies the 'id' parameter is the field ID obtained via buscar_formulario_proposta, but does not explicitly name it or describe its format beyond integer. This provides some context but leaves the parameter's semantics partially implicit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Remover um campo de uma seção do formulário de um modelo de Proposta/Venda/Documento', specifying the verb and resource. It distinguishes itself from the sibling tool excluir_campo_formulario_pipeline by noting it's for the Proposta/CPQ side, and from block removal tools by explicitly excluding product/parcel blocks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a prerequisite (use buscar_formulario_proposta to get the field ID), explicitly states when NOT to use it (for removing a block of products/parcelas), and gives an alternative tool (salvar_modelo_proposta). It also mentions the equivalent pipeline tool, offering comprehensive guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. It explains key behaviors: create vs update based on ID, ordering meaning, quick form toggle, and post-creation field addition. However, it does not disclose what the function returns on success/error, side effects, authorization needs, or how 'oculta' behaves. Moderate 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?
Concise yet informative. The main purpose is stated first, followed by numbered notes that cover essential usage details. No unnecessary sentences, well-organized for quick scanning.
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 no output schema and no annotations, the description provides adequate context for a create/update tool: prerequisites, parameter explanations, and subsequent steps. Lacks return value description and error handling details, but the notes cover key usage flow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but description compensates by explaining 5 out of 6 parameters: pipeline_id (implied via step 1), nome (required), id (update logic), ordenacao (position explanation), formulario_rapido (quick form). Only 'oculta' is left unexplained. Effective use of notes to add meaning beyond raw 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?
Description clearly states the tool creates or updates a section in a pipeline's business form. It explains the create/update distinction via ID presence. While it doesn't explicitly differentiate from sibling tools like 'excluir_secao_formulario_pipeline', the verb and resource are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit step-by-step guidance: use buscar_pipeline to get pipeline_id, buscar_formulario_pipeline to check existing sections, explains ordenacao and formulario_rapido semantics, and recommends salvar_campo_formulario_pipeline after creation. It clearly indicates when to use this tool and what to do before and after.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must fully disclose behavioral traits. It states the actions (GANHAR, PERDER, REABRIR) which imply state changes, but does not mention side effects, reversibility, permissions, or what triggers. It adds the constraint that PERDER requires razao_perda_id. This is adequate but incomplete for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: one sentence for purpose followed by three bullet-point observations. It is front-loaded with the core function and then provides actionable notes. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no output schema, and no annotations, the description covers all necessary aspects: purpose, prerequisites, and parameter-specific requirements. It does not describe the return value or errors, but for a tool with simple state-change actions, this is reasonably complete. Slightly higher completeness could include a note on idempotency or success indicators.
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?
With 0% schema description coverage, the description adds significant value. It explains the purpose of id_negocio (obtained via buscar_negocio), acao (the three enum values), and razao_perda_id (required only for PERDER, obtained via buscar_razao_perda). This contextualizes the parameters beyond the raw schema, though it could further clarify the default/null behavior of razao_perda_id for other actions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the tool's purpose: executing actions on a business ('ganhar, perder ou reabrir'). It explicitly lists the three actions and distinguishes this tool from sibling tools (e.g., buscar_negocio for retrieval, salvar_negocio for general updates). The verb 'Executar' plus resource 'negocio' makes the scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides concrete usage guidance with three numbered observations: using buscar_negocio to obtain the ID, using buscar_razao_perda for the loss reason ID, and noting that PERDER requires razao_perda_id. This helps the agent know prerequisites and when it is appropriate to call this tool vs. fetching data first. Missing explicit when-not-to-use statements but effectively covers key usage patterns.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Explicitly states 'soft delete' and warns about side effects of deleting default or used templates. With no annotations provided, the description fully carries the burden of behavioral disclosure and does so thoroughly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat verbose, including a historical note (NOVO) and a caution. While structured, it could be more concise without losing essential information.
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?
Covers purpose, prerequisites, and warnings. As a simple delete operation with one parameter and no output schema, the description is largely complete. However, it could mention success/error responses or irreversibility (though 'soft delete' implies reversibility).
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%. The description indirectly explains the 'id' parameter by mentioning 'obter o Id (DocumentTemplateId)' in the prerequisite, but does not formally describe the parameter's meaning or constraints. It adds some value but could be more explicit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool does 'Excluir (soft delete) um modelo de Proposta/Venda/Documento (PVD) do Ploomes CRM.' It specifies the verb (excluir/soft delete) and the resource (modelo de PVD), distinguishing it from other excluir tools for different entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides prerequisites (use buscar_templates_documentos to get the Id) and a caution about deleting default or used templates. This gives clear context and guidance for intended usage, though it does not explicitly mention alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the key behavioral trait: deleting a section also removes all fields within it. Since no annotations are provided, this warning is essential. However, it does not cover other aspects like idempotency, error states (e.g., section not found), or authentication requirements, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence for the purpose, one warning sentence, and a prerequisite list item. Every element is essential and front-loaded. There is no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description covers the essential points: what it does, the side effect, and how to obtain the input. It lacks details about the return value or error handling, but for a delete operation, the information is sufficient for safe use.
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 only parameter is 'id' (integer, required), and the schema coverage is 0%. The description adds meaning by explaining that this ID identifies the section to delete and directs the agent to usar buscar_formulario_pipeline to obtain it. This compensates for the missing schema documentation and provides practical guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (excluir) and the resource (seção do formulário de negócios de um pipeline), which distinguishes it from sibling tools like excluir_secao_formulario_proposta or excluir_secao_campo. The verb and resource are specific, leaving no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a prerequisite step (use buscar_formulario_pipeline to get the section ID) and warns about the cascading deletion of fields. This provides clear guidance on when to use the tool and what preparation is needed. However, it does not explicitly mention when not to use it or suggest alternative tools for deleting individual fields.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses that this tool does not read files (agent must prepare data), it combines multiple steps, and the product block inclusion is conditional. However, it does not mention potential failure modes or side effects beyond mentioning individual tools for recovery.
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?
Well-structured with clear sections: overview, prerequisites, alternatives. The description is informative without being verbose. Could condense slightly, but overall effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 11 parameters, no output schema, and complex composition, the description provides adequate context about the purpose and flow but lacks detailed parameter constraints or return value expectations.
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 description must compensate. It adds meaning by grouping visual parameters (cor_primaria, cor_secundaria, logo_url, fonte) and explaining secoes, incluir_bloco_produtos, and campos_bloco_produtos. However, not all 11 parameters are explained (e.g., nome_modelo, entidade_id, nome_empresa, rodape_texto). Partial compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a shortcut for 'CPQ com identidade visual' that generates HTML, creates model, sections/fields, and optionally builds product block. It distinguishes itself from sibling tools by explicitly naming them and clarifying it combines their logic in a single call.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use and when-not-to-use guidance: use individual tools for fine control or recovery after failure. Also states prerequisites: visual parameters and sections must come from a brief already extracted by the agent via other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses create/update behavior, that passing ID updates existing, that integer visibility fields are not reliably documented, and that extra permissions can be passed via permissoes_extra. However, it does not describe success/error response or potential side effects.
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?
Description is front-loaded with main purpose, followed by structured observations (numbered list). Appropriate length for a tool with many parameters, though slightly verbose. No wasted sentences.
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?
No output schema exists, so description should cover return values. It omits what the tool returns (e.g., created/updated profile object). Also missing authentication or admin privilege requirements. However, it provides sufficient context for usage with siblings and sandbox testing.
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 has 48 parameters with 0% coverage from description. Description compensates by explaining the pattern for *_visualizar/*_editar/*_excluir fields (integers for visibility scope) and the flexible permissoes_extra parameter. This adds meaning for key parameters but does not describe all 48 individually, leaving gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states 'Criar ou atualizar um perfil de usuário (nível de acesso) no Ploomes CRM.' It distinguishes from sibling tool buscar_perfis_usuario by specifying its role in obtaining IDs and checking existing permissions. The purpose is specific and clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear when-to-use (create/update profiles), when-to-use-alternatives (buscar_perfis_usuario for reading, other tools for specific permissions like tab/funnel/model visibility), and includes practical notes on testing integer values in sandbox. Explicit and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It implies a read-only operation by stating it 'retorna' data and does not mention side effects, but it does not explicitly state idempotency, authentication needs, or rate limits. It lists available FieldKeys but lacks details on response structure 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded: one sentence for purpose, followed by structured bullet points. Every sentence adds value, and there is no wasted prose.
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?
While the description covers the basics (purpose, parameter guidance, list of FieldKeys), it lacks details about the return format or structure. With no output schema, the agent may need more information about how sections and fields are represented. The tool is moderately simple, so gaps are not critical but noticeable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning. It explains formulario_rapido returns the QuickForm, and it contextualizes pipeline_id by pointing to buscar_pipeline. This adds sufficient value beyond the schema's bare types and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'buscar' and resource 'estrutura do formulário de criação/edição de negócios de um pipeline', and specifies the return of sections and fields. It distinguishes from sibling tools by referencing separate editing tools and the prerequisite tool buscar_pipeline.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: it explains the prerequisite (use buscar_pipeline to get pipeline_id), describes the parameter behavior (formulario_rapido=True for QuickForm), and points to alternative tools for editing (salvar_secao_formulario_pipeline, salvar_campo_formulario_pipeline). This clearly differentiates usage from writing tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that the tool returns HTML fragments (cabecalho_html, corpo_html, rodape_html) ready for 'salvar_modelo_proposta'. It also explains the behavior of 'incluir_bloco_produtos' (leaves a marker for later insertion). It mentions that logo_url must be a public URL. However, it does not mention whether the tool has side effects or requires specific permissions. Overall, strong disclosure but could be more explicit about non-destructiveness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear header, a 'NOVO' note highlighting the use case, a 'Parâmetros:' section with each parameter explained, and a 'Retorna' line. It is somewhat lengthy but every sentence adds value. Minor redundancy: the 'NOVO' note could be integrated more concisely. Overall, efficient for the information density.
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 complexity (8 parameters, no output schema, no annotations), the description provides good context: it explains the tool's role in the workflow, when to use it, and how the output integrates with other tools. It explains the return structure explicitly. However, it misses parameter explanations for two parameters (one required), and does not mention any error conditions or validation. For a tool generating HTML, it could also mention how the CSS is embedded. Still, it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The 'Parâmetros:' section explains 6 of 8 parameters: cor_primaria, cor_secundaria, logo_url, secoes, rodape_texto, incluir_bloco_produtos. However, it does not explain 'nome_empresa' (a required parameter) or 'fonte' (optional but with a default). This is a significant gap for a required field, leaving the agent without crucial context. The explanations provided are clear and include defaults and usage nuances, so partial compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Gerar HTML de cabeçalho/corpo/rodapé para um modelo de PVD'. It is specific about the resource (modelo de PVD) and action (gerar HTML). It also distinguishes the tool from siblings by referencing 'montar_bloco_produtos_proposta' and 'salvar_modelo_proposta', making it clear this is a component in a larger workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use the tool: 'use esta tool DEPOIS de extrair, desses arquivos, um brief estruturado'. It also advises against guessing colors/fonts without a source ('Não adivinhe cor/fonte/logo sem uma fonte'), and tells the agent to document the origin of each value. This clearly separates usage from alternative approaches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses behavioral traits: the tool writes HTML to page body, causes Ploomes to derive FormField, supports insertion position and hidden flag, and has known limitations (not tested with multiple blocks). It does not explicitly state that it overwrites existing HTML, but the behavior is well described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well structured: a clear one-line purpose, followed by a contextual paragraph explaining the derivation process, then a bulleted parameter list, and finally limitations. It is front-loaded with the core action. While detailed, every sentence adds value, earning a score of 4.
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?
There is no output schema, and the description does not mention what the tool returns (e.g., success indicator, updated HTML). Given the complexity (8 parameters, mutation behavior), the description adequately covers input and behavioral context but would benefit from stating return values. It is minimally viable but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description provides detailed semantics for all 8 parameters: template_id, pagina_id, nome_secao, codigo_secao, campos (with supported field keys), posicao, oculto, titulo_coluna. It explains defaults, uniqueness requirements, and supported values, fully compensating 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 that the tool inserts a repeatable 'Produtos' block into HTML of a proposal page. The verb 'inserir' and resource 'bloco repetível de Produtos' are specific. It does not explicitly distinguish from sibling tools, but the purpose is unambiguous given the detailed context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains when to use this tool (to create a functional block via HTML) and when not to (using salvar_campo_formulario_proposta results in a broken field). It also provides context about the derivation process and alternative approaches, making usage guidance thorough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full burden. It discloses key behavioral traits: moving vs. duplicating, direct update via ID, and effects of parameters like secao_id and largura_total. It could mention error conditions but is mostly transparent.
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 structured with bullet points and numbered notes, each sentence adding value. It is front-loaded with the main action. Slightly verbose but appropriately sized for the complexity.
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 6 parameters, no output schema, and no annotations, the description covers prerequisites, parameter meanings, and behavioral nuances. It is complete enough for an agent to invoke correctly, though return value and error handling are not detailed.
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 schema has 0% coverage, so description must compensate. It explains chave_campo with a list of valid keys, ordenacao and largura_total semantics, and secao_id fallback. id is clarified for direct update. This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Adicionar ou mover um campo no formulário de negócios de um pipeline.' This is a specific verb (add or move) and resource (form field of a pipeline), distinguishing it from siblings like 'salvar_secao_formulario_pipeline' and 'excluir_campo_formulario_pipeline'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes notes on prerequisites (use buscar_formulario_pipeline to get IDs), explains behavior when the field already exists (moved instead of duplicated), and provides a list of valid FieldKeys. While it doesn't explicitly state when not to use it, the context is clear enough for appropriate selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that this is a soft delete and warns about potential failures or consequences if the profile is linked to users. It does not detail success responses or authentication needs, but the key behavioral trait is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: purpose, historical context, prerequisites, and caution. It is front-loaded with the main action. The historical note about the test script is slightly extraneous but does not significantly detract from clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with one parameter and no output schema, the description covers the action, effect, input source, and risks. It provides sufficient context for an AI agent to use the tool appropriately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no description for the single 'id' parameter (0% coverage). The description compensates by explaining that the ID should be obtained via 'buscar_perfis_usuario', giving semantic meaning to the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Excluir' (delete) and resource 'perfil de usuário (nível de acesso)' from Ploomes CRM, specifying it is a soft delete. This distinguishes it from other sibling delete tools like 'excluir_cliente' or 'excluir_produto'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear prerequisite: use 'buscar_perfis_usuario' to obtain the profile ID. It also includes a caution about deleting profiles linked to users. However, it lacks explicit guidance on when to use this tool versus alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description covers key behaviors: it can add or move fields, only handles simple fields, and explains effects like full-width. It lacks mention of idempotency or authentication, but overall is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bullet points and front-loaded purpose. While slightly lengthy, each sentence adds value and no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 parameters, no output schema), the description fully covers prerequisites, behavior, limitations, and alternative tools. An agent can confidently use this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description adds meaning for some parameters (form_id, template_id, largura_total, chave_campo) via examples and notes, but 'id' remains unexplained. Adequate but not comprehensive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool adds or moves a simple field in proposal/sale/document forms. It distinguishes itself from sibling 'montar_bloco_produtos_proposta' by explicitly noting that blocks are not handled. The verb and resource are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is given on when to use (simple fields) and when not to (product blocks). It provides step-by-step instructions to retrieve necessary IDs and mentions alternative tools for blocks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses non-obvious behaviors: automatic field creation as 'Texto multilinha' if field doesn't exist, and texto_informativo as tooltip. However, it doesn't mention whether updating overwrites existing data or permissions needed, but overall provides significant 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?
Description is well-organized with numbered notes, front-loading the purpose. Each sentence adds value, though the notes are slightly verbose. Structure is clear and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 params, no output schema, and no annotations, the description explains the behavior well but omits return value information (e.g., does it return the checklist ID or object?). Also missing error scenario guidance, making it somewhat incomplete for an agent to fully anticipate outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description compensates. It explains etapa_id (use buscar_etapas_negocio), id (update), nomes_campos (list, auto-creates field), and texto_informativo (tooltip). However, 'nome' parameter is required but not explained in description, leaving a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates or updates a pipeline stage checklist in Ploomes CRM, using specific verb+resource. It distinguishes from sibling tools like excluir_checklist_etapa (delete) and buscar_checklists_etapa (search) by specifying the create/update behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance: 'Passe o ID para atualizar um checklist existente' indicates when to update vs create. It also references sibling tools (buscar_etapas_negocio for etapa_id, buscar_checklists_etapa for checklist ID) and explains the purpose of nomes_campos and texto_informativo, providing clear when-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description extensively covers behavioral details: format for etapas, hexadecimal color, MaxDays, WinStage/LoseStage, icone_id from buscar_icones_pipeline, nomenclature fields, tipo_funil defaults, and default visualizations. Missing permissions or rollback details.
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?
Well-structured with numbered observations, front-loaded with purpose. Some redundancy and length could be trimmed, but overall clear and organized.
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 11 parameters, no output schema, and no annotations, description covers most aspects including parameter details, defaults, and examples. Lacks error handling or return value, but complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage. Description compensates comprehensively: explains etapas structure, Color, MaxDays, WinStage/LoseStage, icone_id, cor, nome_singular/plural/genero_id, tipo_funil with accepted values, and visualizations defaults. Adds immense meaning beyond raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Criar ou atualizar um pipeline/funil de negócios' with specific verb+resource. Distinguishes from siblings like buscar_pipeline and excluir_pipeline.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to pass ID for update and mentions using buscar_pipeline to obtain ID. Provides clear context but lacks explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It correctly implies a read-only, non-destructive operation by stating 'Listar' and 'Retorna', but does not mention pagination, rate limits, or whether the list is exhaustive.
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 concise with three sentences, front-loaded with purpose, and contains no extraneous information. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains return values (ID and FontAwesome class) and provides a usage hint (use with salvar_pipeline). The tool is simple and the description covers all necessary 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?
There are no parameters, so schema coverage is 100%. The description adds no parameter-level detail, but none is needed. Baseline score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists available icons for pipelines, specifies it returns ID and FontAwesome class, and distinguishes from sibling tools like buscar_pipeline by focusing on icon retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context by advising to use the IconId when creating/updating pipelines with salvar_pipeline, but does not explicitly mention when to use this tool vs alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool uses the normal API, same User-Key, and does not call any LLM. It also describes the input and return structure. However, it omits potential error scenarios or side effects like overwriting existing fields.
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 concise, uses bullet points for parameters and return, and front-loads the purpose. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a single parameter with no output schema, the description adequately covers purpose, usage, parameters, and return value. It also links to the complementary tool 'aplicar_campos_novos_html_llm'. Missing details about potential errors or prerequisites (e.g., HTML must already contain <newfield> tags) but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 0% coverage (array of objects with no property definitions), so the description must compensate. It clearly lists the required keys (index, name, type_id, entity_id) for each object in 'novos_campos' and explains the role of 'index' for matching HTML tags.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates custom fields in Ploomes defined by the agent in HTML, specifying the verb 'criar' and resource 'campos customizados'. It distinguishes itself from sibling 'criar_campos_em_massa_ia' by noting it uses the normal API rather than the IA gateway.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (after the agent defines fields in HTML) and explicitly contrasts it with 'criar_campos_em_massa_ia', noting it requires no extra AI credentials. While it doesn't explicitly state when not to use it, the differentiation provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses behaviors for each mode: safe create, force create, rename. It warns that renaming affects all fields using the table. However, it does not mention authorization needs, rate limits, or what happens on duplicate name when garantir_existencia=false (creates duplicate). Still, it is largely transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with numbered observations, front-loading the main purpose. It is somewhat verbose but every sentence adds value given the complexity. Minor redundancy (e.g., 'Observacoes:' label), but overall efficient.
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 explains tool behavior but does not specify return value (e.g., created/updated table object). It also lacks information on error handling or prerequisites (e.g., authentication). Given no output schema and moderate complexity, some completeness gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, meaning no parameter descriptions in schema. The description fully explains all three parameters: id (use null or integer for create/rename), nome (required, identifies table), garantir_existencia (boolean controlling duplicate behavior). This adds significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Criar, atualizar ou garantir a existência de uma tabela de opções pré-cadastradas no Ploomes CRM.' This specifies the verb (create, update, ensure) and resource (options table), distinguishing it from sibling tools like buscar_tabelas_opcoes (read) and salvar_opcao_tabela_opcoes (add options).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage scenarios: 1) sem id com garantir_existencia=true (safe mode), 2) sem id com garantir_existencia=false (force create), 3) com id (rename). It references sibling tools: 'Use buscar_tabelas_opcoes para achar o Id' and 'use salvar_opcao_tabela_opcoes ... ou garantir_opcoes_tabela_opcoes ... para popular as opções.' It also warns about renaming affecting existing fields.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries full burden. It explicitly states that the tool does NOT call any endpoint, is purely local reconciliation, and explains the rationale behind its existence. No hidden side effects or ambiguities.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections, but it includes some redundant background context (e.g., documentation reference) that could be trimmed. It front-loads the purpose and uses bullet points for parameters, making it scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the input parameters, return value, and the overall flow. Given the tool's complexity and lack of output schema, it provides adequate context. However, it could mention potential failure cases or assumptions about the inputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining what each parameter is and where it comes from. It adds constraints (e.g., original order for campos_identificados, required fields per item, when to omit campos_criados). This goes far beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Montar o HTML final substituindo <field id="N"> por <field key="...">', combining results from two other tools. It uses specific verbs and resources, and distinguishes itself from sibling tools which are mostly CRUD operations on different entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use: after identifying and creating fields, and specifies that campos_criados can be omitted if all fields already have Key. It justifies why the tool is needed (bulk_fields_creation limitation). However, it does not explicitly state conditions when NOT to use it or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses key behaviors: it's a write operation (POST), creates fields with Key, and requires maintaining order. Could mention rate limits or error handling but sufficient.
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?
Somewhat verbose but well-organized: purpose, endpoint, important notes, parameters, return. Important notes are essential. Minor redundancy possible but overall efficient.
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?
No output schema, but description explains return value as list of fields with Key. Lacks error handling details. However, given complexity and context with sibling tools, it's fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but description fully documents each subfield of the campos array (Name, TypeId, EntityId, PathId, Multiple) and the idioma parameter with default. Adds meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states it creates fields in bulk that were identified by identificar_campos_html_ia and do not exist yet. It distinguishes from sibling tools by specifying that fields with Key should be handled by aplicar_campos_no_html_ia.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit numbered points tell when to use (only for fields without Key), when not to, and which alternative tool to use. Also emphasizes positional correspondence requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully bears transparency. Discloses no conversation memory, image placeholder behavior, credential requirements, and the role of previous_html. Leverages observations to explain limitations and side effects.
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?
Well-structured with paragraphs, bullet points, and numbered observations. Front-loads purpose and endpoint. Some redundancy (parameter list repeated in observations), but overall clear and appropriately sized for complexity.
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?
Covers input thoroughly, mentions follow-up tools, and addresses edge cases (placeholder images). No output schema, so description could explicitly state return value (HTML string) but doesn't. Still, context is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, so description must compensate. It provides detailed explanations for all 5 parameters, including example values, optionality constraints (prompt vs anexos), and data types for anexos. Adds significant meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states purpose: generate or edit HTML of Proposta/Venda/Documento model using AI feature. It specifies endpoint, credentials, and distinguishes between generation and editing based on previous_html parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage context: when to generate vs edit, requirements (prompt or anexos), and recommends follow-up tools. Lacks explicit 'when not to use' but clearly differentiates from manual template methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It explains the returned structure (FormField items), distinguishes block fields (QuickFormId) from common fields (FieldKey), and mentions product filter attributes. No performance or error details, but the behavioral disclosure is good.
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?
Concise and well-organized with numbered notes. Every sentence adds value, no redundancy. Front-loaded with the main purpose, then details in structured bullets.
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?
No output schema, so description must explain return structure, which it does adequately (FormField items with FieldKey/QuickFormId). Also covers block filtering attributes. Does not mention error cases or null parameter behavior, but is largely complete for a fetch tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description fully explains both parameters: template_id for top-level form, form_id for specific form or recursive block drill-down. Adds practical usage context that the schema alone lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches the form structure of a proposal/sale/document model. It specifies two distinct usage paths: by template_id or form_id, and distinguishes from sibling tools like buscar_templates_documentos.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: use template_id for the main form, form_id for specific forms or to dive into blocks. Recommends buscar_templates_documentos to get template_id. Explains the difference between FieldKey and QuickFormId fields, helping the agent decide when to call recursively.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses key behaviors: default exact match by Name, optional partial search via 'busca_parcial', and filtering by Id. However, it does not mention the return format or pagination details beyond the 'pagina' parameter, which is minor.
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 concise yet complete, using a single paragraph with numbered observations. Every sentence adds value, and the structure is front-loaded with a clear purpose statement followed by actionable notes.
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 no output schema, the description does not explain return values. However, it provides sufficient context for the intended use case (checking existence before creation) and explains parameter behaviors. It could be slightly more complete about result structure, but it is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions for parameters (0% coverage), so the description fully compensates. Each parameter ('id', 'nome', 'pagina', 'busca_parcial') is explained with its behavior and context, adding significant meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Buscar tabelas de opções pré-cadastradas no Ploomes CRM.' The verb 'Buscar' plus resource 'tabelas de opções' is specific and distinct from sibling tools like 'salvar_tabela_opcoes' or 'excluir_tabela_opcoes'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Use para localizar a tabela de opções antes de criar campos do tipo opções pré-cadastradas (TypeId 7) ou itens de checklist.' It also explains the default exact match behavior, when to use 'busca_parcial', and mentions the sibling 'salvar_tabela_opcoes' for context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description warns that deleting a section also removes all fields within it (cascading deletion), which is a critical behavioral trait. This adds value beyond the tool name and schema, especially since no annotations are provided. However, it does not mention reversibility 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a main statement, a comparison note, a caution, and prerequisites. Every sentence serves a purpose, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Considering the tool's simplicity (one parameter, no output schema), the description covers the key aspects: purpose, prerequisite, side effect, and sibling relationship. It could be enhanced with information about error handling or irreversibility, but it is sufficient for the agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only has an 'id' parameter of type integer with no description. The description explains that this id is the SectionId obtained from buscar_formulario_proposta, providing essential context for correct usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: deleting a section from a proposal/venda/documento form. It also distinguishes itself from the sibling tool excluir_secao_formulario_pipeline by noting it is equivalent but for the Proposta/CPQ side.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear prerequisites, instructing the agent to use buscar_formulario_proposta to obtain the SectionId. It also explicitly compares this tool to the sibling excluir_secao_formulario_pipeline, indicating when to use each.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It discloses that the tool performs writes (create/update), that updating replaces actions, and that actions have varying fields. It also notes lack of official documentation for action types. However, it doesn't explicitly mention potential side effects or error conditions (e.g., what happens if IDs are invalid). Still very transparent.
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 lengthy but well-structured with a summary line, then numbered notes. Every sentence earns its place, though some details (like the full list of entity IDs) could be in a separate reference. Still, for a complex tool with 10 params and actions, this level of detail is appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 10 parameters, the description is remarkably complete. It covers all parameters, their dependencies, how to obtain required IDs from other tools, and even provides action examples. It also warns about uncertainty in action field combinations. Nothing major is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but the description explains all 10 parameters in detail via numbered notes. For example, entidade_id lists possible values with mapping, gatilho_id refers to another tool, etapa_id conditionally required, and acoes provides examples and notes about behavior. This adds immense meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Criar ou atualizar uma automação (de funil ou geral) no Ploomes CRM,' which clearly states the action (create/update) and resource (automation). It distinguishes from siblings like buscar_automacoes (read) and excluir_automacao (delete).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: pass ID to update, omit for create. Details prerequisites for each parameter (e.g., entidade_id lookup, gatilho_id from buscar_gatilhos_acoes_automacao, etapa_id from buscar_pipeline). Warns that updating replaces the actions list, and advises testing in sandbox. No other tool gives such thorough guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full transparency burden. It discloses that the tool automatically creates a first page if pagina_id is not provided, that updating without pagina_id returns an error, that margins are in mm, and that HTML can contain field references. It also notes API documentation incompleteness and recommends sandbox testing. No contradictions with annotations exist.
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 lengthy (9 bullet points) but each point contributes value, explaining complex behaviors and prerequisites. It is front-loaded with the main purpose and then structured as numbered observations. While effective, it could be slightly more concise without losing clarity. A 4 reflects good structure with minor redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 23 parameters, no output schema, and no annotations, the description covers the essential complexity: creating/updating templates, automatic page creation, form building workflow, and references to sibling tools. It warns about incomplete documentation and suggests verification steps. However, not every parameter is explained, and return values are not described (though no output schema exists). This is comprehensive but not exhaustive, earning a 4.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The observations explain key parameters like entidade_id, form_id, pagina_id, corpo_html, and margin settings, adding meaning beyond the raw schema. However, not all 23 parameters are individually described (e.g., variaveis_nome_arquivo, parcelas_obrigatorias are not explained). The coverage is high but not exhaustive, justifying a score of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates or updates a 'modelo de Proposta/Venda/Documento (PVD)' in Ploomes CRM. It specifies that passing an ID updates an existing model, which distinguishes it from sibling tools like 'excluir_modelo_proposta'. The verb 'Criar ou atualizar' and resource 'modelo de Proposta/Venda/Documento' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides extensive usage guidance, including when to use each parameter (e.g., entidade_id required for new models, form_id only for reusing existing forms). It references sibling tools (buscar_campos_entidades, salvar_secao_formulario_proposta, montar_bloco_produtos_proposta) for follow-up actions. It also warns against manually creating a Form and advises checking results with buscar_templates_documentos. This covers when-to-use, when-not-to-use, and alternatives, meeting the highest standard.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully explains the tool's behavior: it returns structured rules derived from reverse engineering, does not call any external LLM, and is part of a recommended workflow. It discloses that it replaces a previous dependency (gerar_modelo_html_llm) and the rationale for removal. No contradictions or hidden behaviors.
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 long but well-structured with bold headers and clear sections (purpose, reason, fluxo, atalho, parameters). It front-loads the core purpose. However, it could be slightly more concise; for example, the historical context about the removed tool could be shortened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (HTML rules for proposal models), the description is complete: it explains the purpose, the problem it solves, the recommended workflow with 6 steps, a shortcut, and parameter details. No output schema exists, but the description doesn't need to explain return values since it's a guide returning rules.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description provides detailed explanations for all three parameters: entidade_id (EntityId root with examples), incluir_bloco_produtos (controls inclusion of product block rules), and formato (default vs markdown). This adds significant meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns HTML markup rules for Ploomes proposal models (PVD), using a specific verb ('Retornar') and resource ('regras de marcação de HTML'). It distinguishes from siblings like gerar_modelo_html_ia and montar_modelo_proposta_com_identidade by explaining its unique role (providing rules, not generating HTML) and the context of replacing a removed tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance via a 'FLUXO RECOMENDADO' (step 1) and an alternative shortcut (ATALHO) for simpler models. It also mentions when NOT to use this tool (if you want a simple model with visual identity) and names the alternative tool (montar_modelo_proposta_com_identidade). The purpose of the tool is contextualized with the problem it solves.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It discloses that the tool returns the same HTML with injected <field id="N"> tags and a list of fields with detailed attributes (Id, EntityId, Name, TypeId, Key, PathId, Multiple). It also mentions a caveat about the 'Multiple' field behavior, enhancing 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 well-structured with clear sections and bullet points, but includes some extraneous details like the raw endpoint URL and a reference to a bug file ('ver bugs-mcp-ploomes.md item 9'), which are not helpful for an AI agent. These minor wastes prevent a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, the description provides a thorough explanation of the return structure and how to use the results. It also contextualizes the tool within the broader pipeline, referencing sibling tools and steps, making it fully complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description adds significant meaning: 'html' is the HTML from 'gerar_modelo_html_ia', 'root_entity_id' is the same ID used there for computing PathId, and 'idioma' is the user's language. This fully 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: identifying dynamic fields in HTML generated by 'gerar_modelo_html_ia'. It specifies the verb 'identificar' and the resource 'campos dinâmicos'. This distinguishes it from sibling tools like 'criar_campos_em_massa_ia' and 'aplicar_campos_no_html_ia'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use the tool (after obtaining HTML from 'gerar_modelo_html_ia') and lays out the next steps: for new fields call 'criar_campos_em_massa_ia', then 'aplicar_campos_no_html_ia'. This provides clear context and alternatives.
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:

[![ploomes-mcp MCP server](https://glama.ai/mcp/servers/JoseAlmeida-Ploomes/ploomes-mcp/badges/card.svg)](https://glama.ai/mcp/servers/JoseAlmeida-Ploomes/ploomes-mcp)

Score Badge

Copy to your README.md:

[![ploomes-mcp MCP server](https://glama.ai/mcp/servers/JoseAlmeida-Ploomes/ploomes-mcp/badges/score.svg)](https://glama.ai/mcp/servers/JoseAlmeida-Ploomes/ploomes-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/JoseAlmeida-Ploomes/ploomes-mcp'

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