ActiveCampaign MCP

Server Quality Checklist

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

Latest release: v1.0.1
Disambiguation3/5
Many tools have clear distinctions by entity type (e.g., account vs deal custom fields), but the high volume and similar names for different entities cause confusion. Tools like 'list_all_custom_field_values' and 'list_all_custom_field_values_2' are ambiguous.
Naming Consistency2/5
Naming convention is inconsistent: some use verb_noun (create_contact), others use phrases with articles (retrieve_a_savedresponse), and there are suffixed numbers (list_all_..._1, update_a_task_outcome_1). No uniform pattern.
Tool Count1/5
With 325 tools, the count is excessive for an MCP server. It far exceeds the typical well-scoped range (3-15) and will overwhelm agents. Many tools could be combined or removed.
Completeness2/5
While the tool count is huge, coverage is uneven. Core CRM entities have CRUD, but missing key operations like email campaigns (only SMS/WhatsApp). The surface feels like a raw API dump rather than a curated, complete set.
Average 3.5/5 across 300 of 325 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 14 commits in the last 12 weeks
- Last stable release on July 8, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description clearly states it is destructive and deletes data, which aligns with annotations (destructiveHint: true). However, the idempotentHint: true annotation is contradictory for a delete operation, and the description does not clarify this behavior.
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 includes an emoji and repeated information from annotations and schema. It is not concise due to the misleading name-discrepancy and redundant content.
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 one-parameter tool with no output schema, the description should at least resolve the name discrepancy and explain the return behavior or side effects. It fails to provide complete context for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear parameter description ('ID of the saved response to remove'). The tool description does not add any extra semantic value beyond what the schema already provides, so a baseline score of 3 is appropriate.
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 states 'Delete a saved response' while the tool name is 'retrieve_a_savedresponse', creating a misleading mismatch between purpose and name. This causes confusion about what the tool actually does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description instructs to 'Confirm with the user before calling' but does not provide any guidance on when to use this tool versus alternative delete tools. It fails to differentiate from siblings like 'delete_a_record' or 'update_a_saved_response'.
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?
Annotations already indicate write operation (readOnlyHint false) and non-idempotence (idempotentHint false). The description explicitly adds 'Not idempotent — calling twice may create duplicates', which is consistent and useful, but no further behavioral details 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description contains a redundant header line, a 'WIP' prefix, and a conflicting final sentence ('Create a new task type'). It is not concise and wastes space on unclear or contradictory 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 clearly identify the entity being created, lacks return value information, and fails to differentiate from sibling tools. Given the simple input schema and lack of output schema, more clarity is needed for an agent to use it correctly.
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 100% so parameters (title, sentiment) are well-documented in the schema. The description adds no additional parameter-level information beyond what the schema provides.
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 is ambiguous and contradictory: it mentions both 'Create a task type - outcome relation' and 'Create a new task type', and the schema suggests creating an outcome with title and sentiment. The 'WIP' prefix indicates incompleteness. The purpose is not clearly stated.
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 alternatives like create_a_task_outcome or delete_a_task_type_outcome_relation. Lacks context for usage 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?
Annotations already set destructiveHint=true, so the description's 'DESTRUCTIVE' adds little new. The instruction 'Confirm with the user before calling' adds some context, but the conflicting purpose (address vs. address list) undermines 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 short with a header, a redundant line matching the title, and a safety note. It is concise but partially redundant.
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 one parameter and no output schema, the description should clearly state what is deleted and any side effects. It fails to consistently convey that it deletes an AddressList record, leaving ambiguity. No explanation of cascading effects or return value.
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 already documents the single 'id' parameter with a description, achieving 100% coverage. The description adds no further parameter details, so the baseline score of 3 is appropriate.
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 states 'Delete address associated with a specific list' which contradicts the tool name and the parameter description 'ID of the AddressList to delete', implying the tool deletes an address list itself, not just an address. This ambiguity harms purpose clarity.
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 warns to 'Confirm with the user before calling' due to destructiveness, but provides no guidance on when to use this tool versus other delete tools like delete_an_address or delete_a_list, which are 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?
The description aligns with annotations (readOnlyHint, destructiveHint) but adds no extra behavioral insights beyond what annotations already provide. Missing details on pagination, rate limits, or returned data shape.
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 (three lines) but at the cost of clarity. It is structured with a header and summary but lacks sufficient detail. Could be improved without being significantly longer.
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 provided, and the description does not explain what data is returned (e.g., what 'plus append' means). For a tool with 5 parameters including filters and pagination, more context is needed about how they affect results.
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 100% with all parameters described. The description does not add meaning beyond the schema. Baseline score of 3 is appropriate.
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 'Retrieve a contacts plus append' which is unclear; it doesn't explain what a 'plus append' is or how it differs from other contact retrieval tools like 'get_contact'. The purpose 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 like 'get_contact' or 'retrieve_contact_data'. The description only notes it's read-only, but does not specify appropriate contexts.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds 'Fetches data. Makes no changes' which reinforces but does not expand beyond annotations. No information about rate limits, authentication, or response structure is provided.
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 short lines) and front-loaded with the READ-ONLY indicator and endpoint. Every sentence serves a purpose, though it could include more detail 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?
Despite detailed annotations and complete schema coverage, the description lacks critical context: it does not explain how to specify a contact, how pagination works despite limit/offset parameters, or what data is returned (no output schema). The tool's relationship to similar siblings is also unclear.
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 covers all 4 parameters with descriptions, so schema coverage is 100%. The description does not add any additional meaning or usage context for the parameters (e.g., how filters or orders apply to contact automations). Baselined at 3 due to complete schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'List all automations a contact is in' which is a specific verb-resource pair. However, it does not clarify how to specify which contact (the input schema lacks a contact ID parameter), and the tool name is ambiguous between listing all contact automations globally vs. for a specific contact. The sibling tool 'list_all_contactautomations_for_contact' suggests a more targeted alternative, increasing 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 explicit guidance on when to use this tool versus alternatives like 'list_all_contactautomations_for_contact' or 'list_all_automations'. The description provides no context about use cases, prerequisites, or scenarios where this tool is 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?
Annotations already provide idempotentHint=true, destructiveHint=false, and readOnlyHint=false. The description redundantly states 'Idempotent' and 'Modifies an existing record in place,' adding minimal new behavioral insight. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat verbose with unnecessary elements like emoji and 'WIP'. The last sentence is redundant and potentially misleading. Could be more concise and focused.
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 mention return values, but does not. It also lacks clarity on what fields can be updated (though schema shows title under dealTasktype). The tool's purpose is understood but incomplete for an agent to fully anticipate behavior.
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 100%, so baseline is 3. The description does not add any parameter-level detail beyond what the schema already provides (id and body descriptions). No additional clarity on the body's structure or optionality.
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 specifies 'Update a task type - outcome relation', clearly identifying the verb and resource. However, the last sentence 'Update an existing task type' is inconsistent and confusing, and the 'WIP' label suggests incompleteness. It distinguishes from siblings like create/delete but lacks precision.
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 other update tools or the create/delete counterparts. The description only states the operation type ('WRITE') 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?
Annotations already provide idempotentHint=true and destructiveHint=false. The description adds that it modifies in place, which is consistent but does not disclose any side effects or behavioral nuances. Given annotations, the description adds minimal extra value.
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 repetitive with 'Update a conversation' appearing multiple times. It includes unnecessary header elements (emoji, method, path) that could be separated. It could be much more concise and 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 the complexity of the input schema with nested objects and required fields, the description is incomplete. It does not clarify which fields are updatable, the role of body.id, or the response. The existence of sibling tool 'partially_update_a_conversation' is not addressed.
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 explain parameters beyond the schema. Schema coverage is 50%, so description should compensate but does not. The nested body object and required fields are not described in the tool description.
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 a conversation, but it is repetitive and does not distinguish from the sibling tool 'partially_update_a_conversation', which suggests a partial update alternative. The verb and resource are 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?
No guidance on when to use this tool vs alternatives like 'partially_update_a_conversation'. No prerequisites or context provided beyond the idempotency hint, which is already in annotations.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description merely reinforces 'no changes' but adds no new behavioral context such as rate limits, authentication requirements, or pagination behavior. The tool's behavior is adequately conveyed by annotations, so the description adds minimal value.
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 includes an informative emoji and endpoint. It is front-loaded but could be more helpful with additional context while remaining concise. For a tool with 5 parameters, this is minimally adequate.
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 explain what 'bulk import status info' returns, how batchId affects results, or how it differs from the sibling list tool. Given no output schema, the description could provide more context about the response format or usage scenarios.
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 80% (4 of 5 parameters have descriptions). The tool description adds no additional parameter information beyond what the schema already provides. Per guidelines, high coverage warrants baseline 3.
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 fetches bulk import status information and makes no changes. The verb 'Fetches' and resource 'Import status info' are clear. However, it does not distinguish from the sibling 'bulk_import_status_list' tool, which likely has overlapping functionality.
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 'bulk_import_status_list'. There is no mention of prerequisites, expected context, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=false, idempotentHint=true, destructiveHint=false. Description adds HTTP method (PUT) and clarifies idempotency, but does not disclose additional behavioral traits like required permissions or side effects. Consistent with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise but includes redundant statements ('Update settings' and 'Modifies an existing record'). The emoji and HTTP method are informative but not structured for easy scanning. Could be more 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?
No output schema is provided, and description does not clarify the response format. The tool's purpose is unclear without knowing what 'settings' are updatable. Given minimal schema and annotations, the description is insufficiently 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 100% but only includes an 'id' parameter; description does not explain what other fields can be updated or the format of the request body. Adds no meaning beyond the schema, which is sparse.
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 identifies the action ('updates data', 'Update settings') and resource ('Configs'), but the resource is vague; it doesn't specify what kind of config. It distinguishes from sibling update tools only by name, not by explicit 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 on when to use this tool versus alternatives. No mention of prerequisites, context, or when not to use. The description only states the operation without any usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states 'Modifies an existing record in place. Idempotent.', which aligns with annotations (idempotentHint=true, destructiveHint=false, readOnlyHint=false). However, it adds no additional behavioral context such as side effects, required permissions, or error handling. The description adds minimal value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively short but contains redundancy: 'Update a stage' appears twice. The inclusion of the header line with emoji and HTTP method is helpful. It could be more concise by removing one of the repeated lines.
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 very brief given the complexity of the tool (nested object, many optional parameters). It does not explain that the body is optional, how partial updates work, or the purpose of the 'reorder' parameter. The output is not described, and no example is provided. The description is incomplete for a tool of this complexity.
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?
Given 100% schema description coverage, the baseline is 3. The description does not provide additional meaning or examples for parameters; it is purely generic. The schema already documents all parameters, so the description adds no extra value beyond what is 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 states 'Update a stage' and 'Update an existing stage', clearly indicating the action and resource. It includes the HTTP method and endpoint, aiding understanding. It distinguishes from create or delete tools but doesn't explicitly differentiate from other update 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?
The description provides no guidance on when to use this tool versus alternatives like 'move_deals_to_another_deal_stage' or 'create_a_deal_stage'. There is no mention of prerequisites, when not to use, or context for selecting 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?
Annotations already provide idempotentHint=true, destructiveHint=false, and readOnlyHint=false. The description adds 'Modifies an existing record in place. Idempotent,' which confirms mutation and idempotency but adds little beyond annotations. It does not disclose return value, authorization needs, 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is mostly concise but contains repetition ('Update an account' appears twice). The first line with emoji and method is useful, but the overall structure could eliminate 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?
The description lacks critical context for a complex nested schema: it does not mention return value (no output schema), whether the update is partial or full (PATCH-like?), or highlight important schema notes like the currency field requiring cents. The information is 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions for all parameters. The tool description adds no additional parameter information beyond what the schema provides. Baseline 3 is appropriate.
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 'Update an account' and includes the HTTP method and resource. It avoids ambiguity but does not elaborate on specific fields or distinguish from potential sibling update tools, though none exist in the sibling list.
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. The description only states it modifies an existing record, but does not explicitly contrast with create or other update tools. The sibling list includes many update tools, but no usage differentiation is provided.
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 adds 'Reversible' and states it 'links records', which goes beyond annotations. Annotations already indicate it is not read-only or destructive. However, it does not disclose error states or behavior for duplicate entries.
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 a cryptic prefix ('🟡 WRITE · links records · Group Members · POST /groupMembers') that is not immediately helpful and repeats the tool title. It could be more 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 tool has no output schema and nested parameters. The description does not explain the response format, prerequisites (e.g., field group must exist), or potential side effects, leaving important gaps for a write 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?
All parameters have schema descriptions (100% coverage), so the baseline is 3. The description adds no new meaning beyond the schema, e.g., not explaining that rel_id is a custom field ID or how ordernum interacts with existing orders.
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 'Add Custom Field to Field Group' and explains it 'Creates an association between records'. However, the examples (e.g., 'tags a contact') are broader than the actual function, introducing slight ambiguity. The verb 'add' and resource are 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?
No guidance is provided on when to use this tool versus alternatives like create_a_custom_field_group or update_custom_field_field_group. The description lacks context for selecting this tool correctly among siblings.
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?
Annotations already indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=true. The description reiterates idempotency and 'modifies in place,' adding minimal value beyond annotations. The PUT method and update verb are 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 concise with essential information front-loaded (purpose, method). Some repetition exists ('Update WhatsApp Template' appears twice), but overall it is efficiently 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 the complexity of the nested body object and no output schema, the description is too brief. It omits important context like update semantics (partial vs full replacement), error handling, and field constraints beyond what the schema provides.
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 50%, and the tool description does not elaborate on the two parameters (id and body). It fails to compensate for missing schema descriptions or clarify which body fields are updatable, leaving the agent without additional guidance.
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 a WhatsApp template by ID and is idempotent. The resource and action are unambiguous, distinguishing it from sibling tools like create or delete, though no explicit differentiation is made.
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 (e.g., creating a new template, updating other entities). It lacks context on prerequisites like the template existing or required permissions.
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 adds non-idempotency detail beyond annotations (idempotentHint=false). However, it doesn't mention required permissions, rate limits, or what happens to existing data beyond creation.
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 has redundancy (repeats 'Create a Flow Execution') and includes a noisy icon and endpoint line. It's short but could be more concise and 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 the complexity (nested objects, no output schema), the description lacks crucial details about return values, error handling, or post-creation effects. More completeness 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 coverage is 100%, so baseline 3. The description does not add any parameter meaning beyond what the schema already provides.
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 a Flow Execution and notes non-idempotency. However, it repeats 'Create a Flow Execution' and doesn't explain what a Flow Execution is, which could be confusing among many create 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?
The description provides no guidance on when to use this tool versus alternative create tools (e.g., create_a_new_contact, create_broadcast). It lacks 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?
Annotations already indicate write, non-idempotent, non-destructive. The description adds that it is not idempotent and reveals the HTTP method and endpoint, but no additional behavioral details beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is repetitive, stating 'Create an account' three times. The header line is useful but the prose could be condensed into one concise sentence.
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 create tool with nested parameters and no output schema, the description is minimal. It covers the basic purpose but omits details like response format, validation, or error handling.
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 100%, so baseline is 3. The description adds no further meaning to the parameters, merely repeating the tool's purpose.
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 an account, using verbs like 'Create' and 'creates data'. The purpose is clear, but it does not differentiate from the sibling tool 'create_an_account_1', and the repetition dilutes clarity.
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 'create_an_account_1' or other create tools. No prerequisites or context are provided.
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?
Annotations already indicate non-idempotent behavior; description adds 'calling twice may create duplicates.' No contradictions. Missing details on permissions, 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description contains redundant phrasing (e.g., 'Create an account note' repeated thrice). The emoji and HTTP method add minor value but 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?
No output schema, yet description doesn't mention return format. Also, nested object parameter (body.note) lacks explanation. For a write tool, more context 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 coverage is 100% (both parameters described in schema). Description adds no extra meaning beyond what schema provides, so baseline 3 applies.
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?
Tool description clearly states it creates a note for an account, with HTTP method and endpoint. However, it repeats 'Create' multiple times without sharpening the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs. alternatives like create_a_note or create_a_deal_note. Sibling tools exist but no differentiation provided.
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 mentions it creates data and is not idempotent, which aligns with annotations (readOnlyHint=false, idempotentHint=false). Adds duplicate warning but no additional behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Short but repetitive: repeats 'Create a new event (name only)' twice. The emoji and path line add structure but could be more 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?
No output schema and description does not mention return value or what the created event object looks like. Lacks prerequisites or error handling details.
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 100%, and description reiterates 'name only', confirming the single parameter. Schema already provides parameter description, so description adds marginal value.
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?
Clearly states 'Create a new event (name only)' and 'Create a new event tracking event (name only)', indicating the tool creates an event tracking event with just a name. Differentiates from siblings by specifying the resource type and limited fields.
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?
Only provides an idempotency warning ('Not idempotent — calling twice may create duplicates') but no explicit guidance on when to use this tool versus alternatives like enable_disable_event_tracking or other create 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?
Annotations already indicate readOnlyHint=false and idempotentHint=false. The description reinforces these by stating 'WRITE', 'creates data', and 'Not idempotent — calling twice may create duplicates.' This adds slightly more context (the duplication warning) but does not disclose potential side effects, error conditions, or authorization needs beyond what 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but contains redundant statements: 'Create a pipeline' repeated three times. The first line is informative but could be integrated. It is not excessively long, but it could be more concise and better structured (e.g., front-loading the key action and non-idempotent warning).
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 nested input schema and no output schema, the description lacks essential context about what a pipeline is, how the dealGroup relates, return values, error handling, or any domain-specific knowledge. The agent may need to infer the purpose from the schema alone, which is insufficient for a complex creation 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?
Input schema coverage is 100% with detailed descriptions for each property. The tool description does not add any additional meaning or examples for parameters, relying entirely on the schema. Per guidelines, baseline is 3 when schema coverage is high, and the description adds no extra value.
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 'Create a pipeline' and identifies it as a POST /dealGroups operation. It specifies the resource (pipeline/deal group) and action (create), making the purpose unambiguous. However, the repetition of 'Create a pipeline' adds noise, and it does not explicitly distinguish from other creation 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions it's a write operation and not idempotent, but provides no guidance on when to use this tool versus alternatives (e.g., create_a_deal_new or others). There are no prerequisites, context, or exclusion criteria, leaving the agent without clear decision support.
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?
Annotations already indicate non-idempotence and non-read-only, and the description reinforces this. However, it adds no new behavioral context (e.g., side effects, rate limits, required permissions) beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description contains slight redundancy (e.g., 'Create a customer' and 'Create a new e-commerce customer resource' convey the same info). It is not excessively long, but could be more 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 important context such as expected response format, handling of required fields, and the implications of the open world hint. For a create tool with nested parameters and no output schema, more detail 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 100% description coverage for all parameters, so the schema already documents the properties. The description does not add any parameter-level details or clarify usage 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 identifies the tool as creating a customer and specifies the domain (Ecom Customers) and HTTP method (POST). However, it does not explicitly distinguish this tool from sibling tools like create_a_new_contact or create_an_account, which also create records but 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 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., update_customer, list_all_customers). The only usage-related information is the non-idempotence warning, which is more about behavior than 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?
Annotations already indicate non-idempotent and non-readonly; description adds 'Not idempotent — calling twice may create duplicates' which matches the annotation. No additional behavioral traits are disclosed (e.g., auth needs, side effects on related resources).
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 repetitive, saying 'Create a task' multiple times. It could be streamlined to a single sentence without losing meaning. The header line adds useful context but is not technically part of the description.
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 complex nested parameters and no output schema, the description does not provide examples, clarify the relational nature (deal tasks), or explain how required fields like 'relid' and 'duedate' should be used. The tool is 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all properties having descriptions. The description does not add any extra parameter information beyond what the schema provides, meeting the baseline for high 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 it creates a task and includes the resource 'Deal Tasks' and endpoint. However, it does not differentiate from many sibling 'create_*' tools, and the repetition ('Create a task') adds no new information.
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 create_a_deal_new or others. The description does not specify context, prerequisites, or scenarios where this tool is 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?
Annotations already declare idempotentHint=false, destructiveHint=false, readOnlyHint=false. The description adds 'Not idempotent — calling twice may create duplicates' which aligns with this. However, it does not disclose required permissions, rate limits, or what happens on creation (e.g., default values for optional fields). With annotations present, the description provides minimal added value.
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 repeats 'Create a user' three times (header, standalone sentence, and final line). The header line is useful but the duplication wastes space. It could be condensed to one clear sentence. Not concise for the amount of 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?
No output schema is provided, yet the description does not explain what the tool returns (e.g., created user object, ID, or confirmation). For a creation action, it would be helpful to know if the user is automatically saved or requires subsequent steps. Also, no mention of authentication or side effects. The description is incomplete for a new user creation.
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 100% (each property has a brief description). The tool description does not add any extra meaning beyond the schema. Since no parameters are required per the schema, a user might wonder if all fields are truly optional; the description could clarify but doesn't. Baseline 3 as schema covers the field semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a user ('Create a user', 'Creates a new record'). It includes a header with 'WRITE' and 'POST /users' for quick identification. However, among many sibling create tools (e.g., create_a_new_contact, create_an_account), it does not differentiate itself, so it's clear but not distinguishing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like create_a_new_contact or create_an_account. The only usage hint is 'Not idempotent — calling twice may create duplicates', which is behavioral rather than contextual. No exclusions or prerequisites 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?
Annotations already declare idempotentHint and no destructive behavior. Description adds 'Modifies an existing record in place. Idempotent.' which matches, but adds little beyond annotations. No disclosure of side effects or state implications.
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?
Description is repetitive: 'Enable/disable' appears twice, and '🟡 WRITE' metadata is mixed in. Could be condensed to one or two sentences without redundant phrases.
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 a nested param, description covers basic operation but lacks response info or constraints. Adequate for a simple boolean toggle but not comprehensive.
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 100% coverage with description for 'enabled' field. The description does not add parameter-level meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool enables/disables event tracking, which is distinct from sibling 'enable_disable_site_tracking'. However, the description is cluttered with metadata, and the purpose is not as crisp as it could be.
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 over alternatives like 'enable_disable_site_tracking' or 'retrieve_event_tracking_status'. No prerequisites or context provided.
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?
Annotations already include readOnlyHint, idempotentHint, and destructiveHint=false. The description reinforces that it fetches data and makes no changes, which adds minimal behavioral context but does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise but contains minor redundancy (e.g., 'List all associations' and 'Retrieve all existing account association'). The emoji and endpoint prefix aid readability, but it could be tighter.
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 no output schema, the description should clarify what the response contains, but it does not. It only states 'List all associations' without describing the structure of returned data, leaving the agent with incomplete information.
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?
Input schema has 100% description coverage for all 6 parameters. The description does not add any parameter-specific information, but given high schema coverage, baseline 3 is appropriate.
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 lists all associations for account contacts, using the GET /accountContacts endpoint. It specifies it is read-only and fetches data without making changes. However, it does not differentiate this list operation from other list tools among many 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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention filtering or pagination usage, nor does it compare with other list tools. The agent is left to infer context from the name and endpoint.
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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds no new behavioral insights beyond restating that it makes no changes. Pagination behavior, rate limits, or return structure are not disclosed.
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 with four lines, but contains redundancy ('List all stages' and 'Retrieve all existing stages' repeat the same idea). Still, it is mostly concise and front-loads key info.
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 7 parameters (including nested objects) and no output schema, the description should hint at return format or pagination behavior. It provides no such context, leaving agents to infer from parameter names alone.
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 100% description coverage for all 7 parameters. The description does not add further meaning or usage examples. Baseline score of 3 is appropriate as the schema does the heavy lifting.
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 ('List all stages' and 'Retrieve all existing stages') and the resource ('Deal Stages'). It distinguishes itself from sibling tools like 'retrieve_a_deal_stage' by emphasizing 'all', but does not explicitly name alternatives.
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 siblings like 'retrieve_a_deal_stage' (singular) or 'list_all_pipelines'. The description does not mention exclusions or context-specific use cases.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds the HTTP method and path, which provides useful context beyond the annotations. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but repetitive ('List Flow Executions' appears three times). It could be more concise by removing 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?
With 8 parameters and no output schema, the description lacks information about the response format, pagination behavior, or how to interpret results. The schema covers parameters well, but context about usage patterns is missing.
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 88%, so the schema already describes most parameters. The description does not add any additional parameter meaning beyond what the schema provides.
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 lists flow executions, is read-only, and provides the HTTP method and path. However, it does not explicitly distinguish this from sibling list tools like 'list_flow_execution_contact'.
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 or when not to use it. The description only states the basic function.
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 adds context beyond annotations by stating 'WRITE', 'updates data', and 'Idempotent', but annotations already indicate idempotentHint=true and readOnlyHint=false. It does not disclose that the tool moves ALL deals from the source stage, which is a key behavioral trait not captured in annotations.
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 short but contains redundant information (e.g., 'Move deals to another stage' is mentioned twice). The template line '🟡 WRITE · updates data · Deal Stages · PUT /dealStages/{id}/deals' adds little value. Could be more concise and better 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?
The description lacks information about the return value or side effects (e.g., whether it returns the moved deals or an empty response). It also does not clarify that the source stage is implicitly specified by the 'id' parameter, which may lead to confusion. Given the lack of an 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and both parameters have descriptions. The tool description does not add any additional parameter semantics beyond what the input schema already provides, so it meets the baseline expectation.
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 'Move deals to another stage' and 'Move all deals in one stage to another stage', making the action and scope obvious. However, it does not differentiate from the sibling tool 'move_deal_tasks_to_another_deal_task_type', which performs a similar bulk move action but for tasks.
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 moving individual deals or when not to use it. There is no mention of prerequisites or context for usage.
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?
Annotations already provide idempotentHint and destructiveHint. Description adds that it modifies a record in place and is idempotent, but does not disclose error handling or side effects beyond annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Short and mostly to the point, but includes redundant repetition of 'Partially update a Conversation'. Still efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks details on return values, error cases, and usage context. With nested objects and no output schema, more information would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 50% schema description coverage, the description adds no extra meaning to parameters. It does not explain the 'id' parameter or the structure of the 'body' beyond what schema provides.
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 performs a partial update on a WhatsApp conversation via PATCH. However, it does not explicitly differentiate from the sibling 'update_a_conversation', though the name implies it.
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 (e.g., full update). No prerequisites or context provided.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds that it is a GET request and 'makes no changes', which aligns with annotations but adds minimal extra insight. No disclosure of error handling or rate limits is provided.
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 contains redundant phrases: 'Retrieve an account' appears twice. The first line with emoji and path is informative but could be integrated. Overall, it is somewhat verbose for a simple tool and could be made 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?
With no output schema, the description should hint at the return value (e.g., account details). It only says 'Fetches data', which is vague. For a simple read operation, this omission reduces completeness. Annotations are helpful but do not cover return semantics.
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 single required parameter 'id' is described in the schema as 'Account's ID'. The description does not add further meaning, but schema coverage is 100%, so the baseline is 3. No additional context like example values or format is provided.
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 retrieves an account by ID, using verbs like 'Retrieve' and 'Fetches'. It distinguishes itself from sibling tools like 'list_all_accounts' and 'create_an_account_new' by focusing on a single account lookup. However, it could be more specific about the returned data 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?
The description provides no guidance on when to use this tool vs alternatives (e.g., 'list_all_accounts' or other retrieve tools). An agent must infer that it's for fetching a specific account by ID, but no explicit when-to-use or when-not-to-use information 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?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds that it is a GET request and does not change the account, but this is minimal. No additional behavioral information such as rate limits, permission requirements, or response structure is provided.
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 short (4 sentences) but contains some redundancy: 'Retrieve a contact's data' and 'Fetches data' say the same thing. The emoji and path are useful. Structure is acceptable but could be tighter by removing duplicates.
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 5 parameters and no output schema, the description is minimal. However, annotations and schema descriptions cover the essential aspects (read-only, id required, pagination, filtering). The description does not explain the return format or how orders/filters work, but the schema parameter descriptions provide that context. Overall adequate but lacks summary of behavior.
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 100%, so the baseline is 3. The description does not elaborate on parameters beyond the schema's own descriptions. The first line hints at 'Contacts' but adds no new meaning to the parameters like id, limit, offset, orders, or filters.
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 retrieves a contact's data and that it is read-only. It distinguishes itself from other retrieve tools by specifying 'contact data' and including the HTTP path. However, it does not explicitly differentiate from sibling tools like 'get_contact' or 'retrieve_contact_field_values'.
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 does not mention prerequisites, when to use pagination/filters, or when to prefer other retrieve tools. The description only states it fetches data without changes, which is implied by the name and annotations.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description merely restates the read-only nature ('Makes no changes') without adding new behavioral context such as typical response size 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 (three sentences) and front-loaded with key info. No unnecessary words, though the emoji and formatting add minor visual value without harming clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval with one parameter and comprehensive annotations, the description is adequate. However, it lacks information about the response structure or any caveats, which would be helpful without 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 100% with a single parameter 'id' clearly described. The description does not add meaning beyond the schema, earning the baseline score.
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 'Retrieve a form' with specific verb and resource, and includes HTTP method and endpoint. However, it does not differentiate from sibling tool 'forms_1', which may have overlapping functionality.
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?
Description provides no guidance on when to use this tool versus alternatives like 'forms_1' or other retrieval tools. No explicit context or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds 'Idempotent' which is already declared in annotations (idempotentHint: true). It does not disclose any additional behavioral traits beyond what annotations provide, such as authentication requirements, 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?
The description is concise (three short sentences) and front-loaded with key info (emoji, HTTP method). The structure is clear, though the first line is somewhat dense with mixed symbols and text.
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 mutation tool with no output schema, the description lacks information about the response, error states, or practical usage context. Annotations provide safety info, but the description does not complete the picture for an AI 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 100%, and each parameter already has a description in the schema. The description adds no additional meaning or context for parameters, so it meets the baseline but does not enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update a custom field' and specifies the resource 'Account Custom Field Meta', which distinguishes it from other custom field update tools for deals or contacts. However, it could be more explicit about the scope (account custom field meta) to better differentiate among 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 like update_a_custom_deal_field_meta or update_a_custom_field_value. No prerequisites or context are provided, leaving the agent to infer usage.
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?
Annotations already indicate idempotentHint=true and destructiveHint=false. The description adds 'Idempotent' and 'Modifies an existing record in place', which are consistent but not new. No additional behavioral details like permissions, error handling, or side effects beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is relatively short but contains redundancy ('Update a pipeline' appears twice). The structured parts (emoji, HTTP method, resource) are front-loaded. Could be more concise by removing the duplicate 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?
No output schema is provided, and the description does not mention what the response contains. For a 2-parameter tool with nested body, additional context about return value or error handling 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?
Input schema has 100% description coverage for all parameters, including nested fields. The description does not provide any extra parameter information beyond what the schema already documents.
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 a pipeline, with the verb 'update' and resource 'pipeline' explicitly mentioned. It also includes the HTTP method and endpoint. However, it does not differentiate from sibling tools like 'create_a_pipeline' or 'delete_a_pipeline' beyond the verb.
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 other update tools (e.g., update_a_deal_stage, update_a_deal_new). No prerequisites, when-not-to-use, or alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description restates the idempotentHint and readOnlyHint from annotations without adding new behavioral details. It does not disclose authorization needs, rate limits, or side effects beyond what annotations already provide.
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 repetitive ('Update a secondary contact' appears twice). It front-loads the HTTP method and resource, but the redundancy reduces conciseness. Could be trimmed to one sentence.
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 (update with two params, no output schema), the description is minimally adequate. It lacks explanation of the body fields' roles and the return value, but the schema compensates partially.
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 100%, so the schema already explains the parameters. The description adds no parameter-specific information beyond the schema, resulting in a baseline score of 3.
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 'Update a secondary contact' and includes HTTP method and resource path. It distinguishes from siblings like create or delete secondary contacts, but doesn't elaborate on the concept of a secondary contact in the context of Contact Deals.
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 alternative update tools (e.g., update_a_contact_new, update_a_deal_new). The description only says it modifies an existing record, lacking context for decision-making.
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?
Annotations already provide idempotentHint=true and destructiveHint=false. The description adds 'modifies an existing record in place' but no additional context. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is repetitive ('Update a task outcome' appears twice) and contains a typo ('taskOutccomes'). Could be made 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?
No output schema and does not clarify response behavior (e.g., returns updated record or status). Nested object semantics are not explained beyond schema. Incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and schema descriptions sufficiently define parameters. The tool description adds no extra meaning beyond what's already provided.
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 updates a task outcome and includes idempotency. However, it is repetitive and does not differentiate from sibling tools like create or delete, reducing clarity.
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 alternatives. The description lacks prerequisites, conditions, or exclusions, leaving the agent uncertain about appropriate usage.
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?
Annotations already provide non-readOnly, idempotent, and non-destructive hints. The description adds 'Modifies an existing record in place' and 'Idempotent', which aligns with annotations but adds minimal extra 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 somewhat repetitive ('Update broadcast message' appears twice) and includes a noisy prefix (emoji, HTTP details). It could be more concise while retaining essential 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?
No output schema, yet the description does not explain return values or behavior on success/failure. It also lacks context on what specific fields can be updated despite the complex nested body 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 100% with descriptions for both parameters. The description does not add meaning beyond the schema; it only restates the tool's purpose.
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 a broadcast message, with verb+resource. It also includes the HTTP method and path. However, it repeats 'Update broadcast message' twice without significant additional differentiation from siblings like create_broadcast or update_aibroadcast.
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 alternatives. It does not mention prerequisites, exclusions, or scenarios where this tool is preferred over create_broadcast or other update tools among siblings.
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?
Annotations already indicate idempotentHint=true and non-destructive. Description adds 'Idempotent' and 'Modifies in place,' which is consistent but adds little beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is short but contains repetition ('Update a webhook' appears twice). The emoji and endpoint are helpful but 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?
No output schema, and description does not explain return values or error handling. For an update tool, it lacks information on success/failure behavior.
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 100%, so baseline is 3. Description does not mention any parameter details, adding no 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?
Clearly states it updates a webhook and modifies an existing record. Distinguished from sibling tools like create_webhook and delete_webhook by name and description.
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. The description mentions idempotency but does not contrast with create or delete 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?
Annotations already indicate readOnlyHint=false, idempotentHint=false, destructiveHint=false. The description adds only the non-idempotence note, which repeats annotation context. No additional behavioral details (e.g., side effects, rate limits, required permissions) are provided.
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 a banner prefix and three statements that essentially repeat the same idea. It could be consolidated into a single clear sentence without losing meaning. It is not excessively long but contains 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?
No output schema exists, so the description should clarify what the response contains (e.g., created record ID). It also does not address the fact that the input schema has no required fields, leaving ambiguity about minimal viable input. The tool is a create operation, and the missing post-creation context reduces 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?
Input schema has 100% description coverage, so the baseline is 3. The description does not elaborate on parameters beyond the schema; it merely repeats the action. No extra meaning or usage hints for fields like 'tag', 'name', 'format', 'content', or 'listids'.
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 states verb 'creates' and resource 'variable' (personalization). It is clear but includes redundant phrasings ('Create a Variable', 'Creates a new record', 'Create a personalization variable'). Does not explicitly differentiate from sibling tools like edit_variable or list_variables, but the name and context make it reasonably specific.
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 usage warning about non-idempotence ('Not idempotent — calling twice may create duplicates'), which is helpful. However, lacks guidance on when to use this vs. other variable tools (e.g., edit_variable or list_variables), and no prerequisites or success 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?
Annotations already mark it as destructive; description adds 'High blast radius.' However, there is inconsistency: description says 'bulk delete' and 'many records,' but the input schema only accepts a single integer 'ids,' making behavior 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 includes a header with emoji and route, followed by two sentences, but ends with a redundant 'Delete an existing account' which contradicts 'bulk.'
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 how to delete multiple records (e.g., repeat calls or accept array), no output schema info, and does not clarify return value or side effects beyond blast radius recommendation.
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 100% but the description does not explain how a single integer 'ids' enables bulk deletion; it contradicts the schema by implying multiple records can be deleted with one 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 'delete' and resource 'accounts', and emphasizes 'bulk delete' and 'Deletes many records in a single call,' distinguishing it from single-delete siblings like 'delete_an_account'.
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 caution with 'High blast radius — always confirm before calling,' but lacks explicit comparison to alternatives or when not to use (e.g., for single deletions).
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?
Annotations already provide idempotentHint=false, destructiveHint=false, readOnlyHint=false. The description reinforces non-idempotency by warning that calling twice may create duplicates, which adds some value. However, no information about permissions, side effects, or limits beyond what annotations convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three short lines, front-loading the purpose. It uses helpful icons and HTTP method. No unnecessary words, though it 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?
For a creation tool without an output schema, the description should mention what is returned (e.g., the created feed). It only states it creates a new record and is not idempotent. Additionally, no guidance on how it relates to sibling tools like list_all_calendar_feeds or update_a_calendar_feed.
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 100% as each property in the body has a description. The description does not add any additional parameter semantics beyond what the schema already provides.
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 a calendar feed (verb+resource) and mentions it creates a new record. However, it does not distinguish from sibling tools like update_a_calendar_feed or list_all_calendar_feeds beyond the verb, though the name itself 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?
No guidance on when to use this tool versus alternatives like update_a_calendar_feed or remove_a_calendar_feed. The only usage hint is the non-idempotency warning, but no context about prerequisites or appropriate scenarios.
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?
Annotations already indicate readOnlyHint=false, idempotentHint=false, destructiveHint=false. The description repeats the write nature ('🟡 WRITE', 'creates data') and the idempotency warning. It adds the HTTP method (POST) and resource path, but no additional behavioral context like authentication or error states.
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 short but repetitive: 'Create a task type' appears three times. The emoji and method prefix add structure but some redundancy reduces conciseness. It could be trimmed to a single sentence with the same 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?
For a simple create tool with one parameter and no output schema, the description covers basic purpose and idempotency. Missing elements include: what the response looks like (since no output schema), confirmation of success, and mention of the uniqueness constraint on title (though in schema). Adequate but not thorough.
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 100% with descriptions for 'title' and 'status' (including uniqueness constraint on title). The description adds no parameter information, relying solely on the schema. Since schema already describes parameters well, baseline score of 3 is appropriate.
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 a 'task type' for deals, using 'Create a task type' and 'Creates a new record'. It identifies the resource as 'Deal Tasktypes'. However, it does not differentiate from sibling create tools like 'create_a_task_outcome' or 'create_task', missing an opportunity for distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The only guideline is the idempotency warning: 'Not idempotent — calling twice may create duplicates.' This is useful but does not specify when to use this tool versus alternatives (e.g., 'create_a_deal_note'), nor does it provide prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a write, non-idempotent operation. The description adds 'Not idempotent — calling twice may create duplicates', which aligns with annotations but doesn't disclose additional behaviors like authorization needs 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description repeats 'Create a task outcome' three times and includes unnecessary emoji/header lines. Could be more 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?
Minimal description covers basic creation and idempotency but omits information about required fields (title and sentiment are required in the schema) and the response format (no output schema). Adequate for a simple tool but 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 100%, so baseline 3. The description adds no extra meaning for parameters; it only restates the tool's purpose. No value added 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 'Create a task outcome' and 'Creates a new record', effectively conveying the verb and resource. However, it does not differentiate from the sibling tool 'create_a_task_outcome_1'.
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 (e.g., update or the sibling create tool). Missing context about prerequisites or scenarios.
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 adds 'Not idempotent — calling twice may create duplicates,' which reinforces the idempotentHint in annotations. Beyond that, no additional behavioral traits (e.g., side effects, rate limits) are disclosed.
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 contains repetition ('Create a task reminder' appears twice, and 'Create a new task reminder' is redundant). It includes an emoji and endpoint line, but could be more succinct.
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 simple parameter structure and high schema coverage, the description provides minimal context. It does not explain prerequisites (e.g., the task must exist) or what the response contains, though no output schema exists.
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 already provides clear descriptions for both parameters (dealTask and interval) with 100% coverage. The tool description adds no extra context or meaning beyond what the schema offers.
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 'Create a task reminder' and 'Creates a new record,' making the tool's purpose evident. However, it does not differentiate from sibling create tools like create_a_task, though the name itself provides some distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as create_a_task or other reminder-related tools. There is no mention of prerequisites or context for usage.
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?
Annotations already indicate non-idempotent and non-read-only behavior. The description adds that calling twice may create duplicates, which aligns with idempotentHint=false. However, no additional behavioral details are given (e.g., side effects, authorization requirements, or limits).
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 short but includes redundant text ('Create custom field options' appears twice) and a header with emoji and endpoint info that could be streamlined. It is not ideally front-loaded for quick scanning.
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 creation tool with one nested parameter and no output schema, the description is minimally adequate. It covers the basic create action and non-idempotency, but lacks information about response format, error handling, or required relationships with other resources.
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 provides complete descriptions for all parameters (100% coverage), so the description adds no new meaning. It does not elaborate on the body object or provide usage examples beyond what the schema already offers.
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 'create' and resource 'custom field options', and includes context like 'Field Values' and 'POST /fieldOption/bulk'. However, it does not differentiate from similar sibling tools like 'create_a_custom_field_value' or 'create_custom_deal_field_meta', leaving ambiguity about when to use this specific tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives. The description lacks any context about prerequisites, such as needing a custom field ID or when creating options is appropriate versus other field creation 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?
The description notes that 'Not idempotent — calling twice may create duplicates,' which adds value beyond the annotations (idempotentHint false). However, it does not disclose other behavioral traits like required permissions, rate limits, or side effects beyond duplication. Annotations already indicate readOnlyHint false and destructiveHint false, so the description partially fills the gap.
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 repetitive, repeating 'Create a webhook' twice and including redundant phrases like 'Creates a new record.' The initial line with the label is useful but could be integrated more cleanly. It could be shortened to one or two sentences without losing 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 100% schema coverage and annotations, the description covers basic intent and non-idempotence. However, it does not mention the expected return value or that the created webhook object is returned. For a create tool, this is a minor gap. It is minimally complete but could provide more context about the response.
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 100%, with each property documented thoroughly. The description adds no additional meaning beyond what the schema already provides (e.g., required fields, validation rules). Baseline 3 is appropriate.
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 'Create a webhook' and includes a label 'WRITE · creates data · Webhooks · POST /webhooks', making the verb and resource explicit. It distinguishes from sibling tools like get_webhook, delete_webhook, and update_webhook, but does not differentiate from other create_* tools, which is acceptable given the distinct 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?
There is no guidance on when to use this tool versus alternatives, such as when to create a webhook versus update or delete. No exclusions or prerequisites are mentioned, leaving the agent without context for appropriate invocation.
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?
Description adds value beyond annotations by explicitly marking the tool as destructive and advising user confirmation. It includes the HTTP method and URL, which clarify the operation. However, it repeats the purpose without additional 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is repetitive ('Delete WhatsApp Template' appears three times) and includes a URL that may not be necessary. It could be condensed into a single sentence without loss of clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple destructive tool with good annotations, the description provides essential safety warnings but lacks details on return values or side effects. It is functionally 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.
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 only states 'Deletes a WhatsApp Template by Id.' without elaborating on the 'id' parameter, its format, or constraints. This fails to compensate for the lack of schema 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?
The description clearly states 'Delete WhatsApp Template' and uses the verb 'delete' with a specific resource. It distinguishes itself from sibling delete tools by targeting WhatsApp templates specifically.
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 alternatives like other delete tools or update operations. The name implies usage for WhatsApp templates, but no explicit context or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, etc. The description reiterates 'Makes no changes' and includes a READ-ONLY icon, which adds minor emphasis but does not go beyond the annotations. No additional behaviors like pagination limits or rate limits are disclosed.
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 (3 lines including icon and endpoint) with a clear front-loaded label 'READ-ONLY' and endpoint. Every element serves a purpose, but it could be slightly more informative without losing 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?
Despite having 8 parameters and no output schema, the description does not explain the return format, pagination behavior, or typical use cases. It relies entirely on the schema, leaving gaps about what the response contains.
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 100% description coverage for all 8 parameters, so the schema already documents parameter meaning. The description adds no extra parameter-specific context, resulting in a baseline score of 3.
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 explicitly states 'Retrieve exclusions list' and labels it as READ-ONLY, clearly indicating the action and resource. It distinguishes from sibling tools by naming the specific list type (exclusions), though it does not elaborate on what exclusions represent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It simply repeats that it fetches data without changes, but fails to mention when it is appropriate or preferable to other list retrieval tools among the many siblings.
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 explicitly states 'READ-ONLY' and 'Makes no changes to your ActiveCampaign account', which aligns with annotations (readOnlyHint, destructiveHint). The disclosure of the HTTP method (GET) provides additional context. However, it does not reveal any traits beyond what annotations already convey, so the description adds limited value.
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 short but contains redundancy: 'Retrieve a contact' and 'Retrieve an existing contact' say the same thing. The emoji and HTTP path are useful but add minimal value. It could be more concise by removing repetition. Overall, it's adequate but not polished.
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 read tool with one parameter and no output schema, the description explains the basic action and safety. However, it does not mention what the response contains (e.g., full contact object) or how it differs from sibling tools. Given the context of many similar tools, the description is minimally sufficient but lacks contextual 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?
The input schema covers the single parameter 'id' with 100% description coverage, so the baseline is 3. The description does not add any extra context about the parameter beyond the schema's 'ID of the contact'. No examples, formats, or constraints are given, so no meaningful addition 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 retrieves a contact, using verbs like 'Retrieve' and 'Fetches data'. It identifies the resource (contact) and the HTTP method (GET). However, it does not distinguish this tool from sibling retrieval tools like 'retrieve_contact_data' or 'retrieve_contact_field_values', all of which also retrieve contact information, reducing purpose differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or context for use. Given the large number of sibling tools for retrieving various contact details, the lack of usage guidance is a significant gap.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which the description reinforces with 'Fetches data. Makes no changes.' The description adds a visual indicator ('🟢 READ-ONLY') and the HTTP method, but does not disclose additional behaviors such as error handling, rate limits, or authorization requirements. With annotations covering the safety profile, the description provides adequate but not extensive 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 short and front-loaded with the read-only indicator and HTTP method. It is mostly efficient, though there is slight redundancy (title repeated in description). Every sentence serves a purpose, but the explanation of the resource 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?
The tool has no output schema, and the description does not explain what the return value looks like or what 'editor markup' represents. For a data-fetching tool, this is a critical omission. Given the large number of sibling tools, a user would benefit from knowing the structure or usage context, which is entirely missing.
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 100% coverage with the 'messageId' parameter described as 'required'. The description does not mention the parameter at all, adding no additional meaning beyond what the schema provides. Baseline score of 3 is appropriate as schema already documents the parameter sufficiently.
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 it 'Gets Editor Markup' and 'Fetches data', clearly indicating a read operation on a resource. The verb 'get' and resource 'editor markup' are specific, distinguishing it from sibling tools like 'retrieve_a_message'. However, the term 'editor markup' is not explained, leaving some ambiguity about what exactly is retrieved.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It only states that it fetches data without any context about prerequisites, typical use cases, or scenarios where other tools like 'retrieve_a_message' might be more appropriate. Given the large list of sibling tools, this lack of guidance is a significant gap.
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?
Annotations already declare readOnlyHint and destructiveHint. The description adds that it fetches data and makes no changes, which aligns but does not add significant new behavioral context beyond the endpoint path.
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 short but contains redundancy ('Retrieve logged-in user' appears twice). It is not as concise as it could be, but still 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 tool is simple, but the description lacks clarity on what data is returned. With no output schema, additional details about the response shape would improve completeness. Pagination parameters seem out of place for a single-user retrieval, and that is not addressed.
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 100%, so the input schema already describes all parameters. The description adds no additional meaning to the parameters, earning a baseline score of 3.
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 'Retrieve logged-in user' with a specific verb and resource. It is distinct from sibling tools like 'list_all_users' or 'get_user' (which likely requires an ID), though it does not explicitly differentiate itself.
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 get_user or list_all_users. The description does not provide context or prerequisites.
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?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint. The description adds 'Fetches data. Makes no changes.' which aligns but does not disclose additional behavioral traits beyond the endpoint method. Average value added.
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 repetitive (e.g., 'List all customers' vs 'List all e-commerce customer resources') and includes an emoji and endpoint notation. Could be more concise without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and 7 parameters, the description only covers the high-level function. Annotations provide safety context, but the description does not explain pagination, output format, or edge cases. Minimal 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 100%, so the schema already documents all parameters. The description adds no information about parameters or how to use them, meeting the baseline.
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 lists all customers, specifying 'Ecom Customers' and the endpoint path. It's unambiguous but does not differentiate from other list tools for different entities among the many 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 explicit guidance on when to use this tool versus alternatives. The description only states what it does, not when to use it or when not to. Given the large number of sibling tools, this is a gap.
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?
Annotations already declare readOnlyHint and destructiveHint. The description adds that it fetches data and makes no changes, but does not disclose other behaviors like pagination limits or auth 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 short but repetitive ('List all task types' and 'Retrieve all existing task types' say the same thing). It could be more 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 rich annotations and schema, the description is adequate. However, it omits the return format and does not mention pagination defaults, which could 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 100%, so parameters are already well-documented. The description adds no additional parameter-level meaning beyond what the schema provides.
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 lists all deal task types, using verbs like 'List' and 'Retrieve'. It distinguishes from CRUD siblings, though it doesn't explicitly name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lacks any guidance on when to use this tool versus alternatives like retrieve_a_deal_task_type. No exclusion criteria or use cases are provided.
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?
Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds the endpoint 'GET /scores' and restates 'Makes no changes'. This aligns with annotations but doesn't add significant new behavioral context beyond what annotations already convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: three short lines with emoji, endpoint, and safety note. It is front-loaded with the key purpose. However, it 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 the tool has 4 parameters including nested objects and no output schema, the description is too minimal. It does not explain what scores represent, the return format, or pagination details (though limit/offset are in schema). For a complex tool, more context 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 coverage is 100%, so the input schema already documents all parameters well. The description does not add any parameter-specific meaning or examples 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 lists all scores and is a read-only operation. The verb 'List' and resource 'scores' are specific. While it doesn't explicitly differentiate from sibling list tools, the name and context make the purpose obvious.
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 alternatives like 'retrieve_a_score'. There is no mention of when to use or not use this tool, nor any prerequisites or context for usage.
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?
Annotations already declare the tool as read-only and non-destructive. The description adds 'Fetches data. Makes no changes' and includes an emoji indicator, but does not elaborate on pagination behavior or API specifics beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but contains redundancy: 'List all secondary contacts' appears twice and 'Retrieve all secondary contacts' repeats the same idea. It could be more concise by eliminating duplication.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity, rich annotations, and full schema coverage, the description is adequate. However, it fails to clarify that 'all' is paginated (implied by limit/offset) and lacks guidance on when to use list vs retrieve.
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 100% coverage with detailed descriptions for all four parameters (limit, offset, orders, filters). The tool description adds no additional parameter information, so it meets the baseline without extra value.
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 explicitly states 'List all secondary contacts' and 'Retrieve all secondary contacts', clearly indicating the action and resource. The tool name is self-explanatory, and it distinguishes from sibling 'retrieve_a_secondary_contact' which targets a single contact.
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 listing tool versus the singular retrieval or other alternatives. The description only states its read-only nature, missing context on pagination or selection 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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds the HTTP method and that it fetches data without changes, but does not disclose pagination or other behaviors beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise with two sentences, but contains slight redundancy between 'List all tasks' and 'Retrieve a list of existing tasks'. The emoji and endpoint line provide structure but one sentence could be removed.
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 17 parameters and no output schema, the description fails to mention pagination or that the result is a list. It leaves many important details unaddressed for a complex 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?
All 17 parameters have descriptions in the input schema (100% coverage), so the description adds no additional parameter information beyond stating the tool lists tasks. Baseline 3 is appropriate.
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 'List' and resource 'tasks', and includes the HTTP method. However, it does not explicitly differentiate from sibling tools like 'get_task' which retrieves a single task, though the scope is implied.
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 'get_task', 'create_task', or other list tools. There is no mention of prerequisites or 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?
Annotations already declare readOnlyHint and idempotentHint. The description adds '🟢 READ-ONLY' and 'Makes no changes,' but doesn't disclose pagination behavior, rate limits, or response structure beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively short but redundant with 'List all users' appearing twice. The emoji and 'Fetches data' add limited value. Could be more 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 no output schema, the description does not explain the response format. Rich annotations compensate partially, but completeness is average for a listing 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 100%, so parameters are well-documented in the schema. The description does not add extra meaning about limit, offset, orders, or filters.
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 lists all users and uses a read-only verb + resource. However, it doesn't differentiate from other list_all_* siblings like list_all_contacts, and repeats 'List all users' twice.
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 list_all_contacts or get_user. No context about prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description repeats that it fetches data and makes no changes, aligning with annotations but adding no new behavioral insights beyond the emoji and HTTP method.
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 short but somewhat repetitive ("List Conversations" appears twice). It includes an emoji and HTTP path but could be more concise by removing 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?
While the schema covers parameters well, the description does not clarify pagination behavior (e.g., interplay of page, offset, page_size) or response structure, leaving some gaps for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The tool description adds no additional meaning or usage details for 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 clearly states the tool lists conversations and is read-only. However, it does not differentiate from sibling tools like list_all_contacts or list_all_deals, missing an opportunity to specify its unique scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor are filters, pagination, or other parameters explained in terms of usage 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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description repeats 'Makes no changes' and 'READ-ONLY,' adding no new behavioral context beyond what the annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and efficient, but it includes redundant phrasing like 'Retrieve a list' which echoes the tool name. The structure is acceptable but could be more 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?
For a simple read-only retrieval with one parameter and output schema missing, the description minimally covers the key points. However, it lacks details about what a 'list' refers to in ActiveCampaign and what the response contains.
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 covers the single parameter 'id' with a description. The tool description does not add additional meaning or usage details for the parameter, so it stays at baseline given 100% 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 'Retrieve a list' and 'Fetches data,' making the verb and resource evident. However, it does not differentiate from many similar 'retrieve_a_*' sibling tools, such as retrieve_a_campaign or retrieve_a_deal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description redundantly states 'Makes no changes' but adds no new behavioral traits such as required permissions, rate limits, or response behavior. The addition of the GET endpoint is mildly helpful but insufficient to significantly raise the score.
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 front-loaded with a helpful emoji and endpoint line, but it contains redundancy: 'Retrieve a task outcome' appears twice, and 'Fetches data...' essentially repeats the read-only hint from annotations. It could be more concise without losing 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 simplicity (one parameter, no output schema) and comprehensive annotations, the description is nearly adequate. However, it does not mention what the response contains or provide any example. For a retrieval endpoint, telling the agent that it returns the task outcome object would add useful context. Overall, minimal but acceptable.
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 has full coverage (100%) for the single parameter 'id', with a description 'Task outcome's id'. The tool description adds no additional detail about the parameter, such as its format or examples. Baseline for high schema coverage is 3, and the description does not improve or detract from this.
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 'Retrieve' and the resource 'task outcome'. It also includes the HTTP method and endpoint path, making the tool's purpose unmistakable. It is well-differentiated from sibling tools like create, list, update, and 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?
The description provides no guidance on when to use this tool versus alternatives. For example, it does not indicate that for retrieving a single outcome by ID this tool is appropriate, while for listing all outcomes the 'list_all_task_outcomes' tool should be used. This lack of contextual usage advice hinders an AI agent's decision-making.
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?
Annotations already declare readOnly, idempotent, and non-destructive. The description reinforces that it fetches data and makes no changes, but adds no further behavioral context beyond what is in the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with the HTTP method and path front-loaded. However, it redundantly restates the tool's purpose and the read-only nature already covered by annotations.
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 no output schema, the description does not explain what the returned counts look like or how to interpret them. It also does not provide context for the nested parameters or pagination, making it incomplete for an agent to fully utilize.
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 100%, so all parameters are documented in the schema. The description does not add any additional parameter-specific 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 it retrieves 'automation entry counts' for a contact, with HTTP method and path. However, it does not differentiate from other retrieve_contact_* sibling tools, leaving ambiguity about what specifically this tool returns.
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 given on when to use this tool versus alternatives. It lacks context about what 'automation entry counts' represent or when an agent would need them.
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?
Annotations already indicate idempotentHint=true, and the description adds 'Idempotent' and 'Modifies an existing record in place'. No contradiction. However, it does not disclose additional behaviors beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with HTTP method and path, but includes redundant sentences: 'Update an account note' and 'Update an existing note for a account' say the same thing. Could be more 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?
No output schema, and the description does not mention return values or response format. For a simple update operation, this might be adequate, but more context on the response 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?
Schema coverage is 100%, so the baseline is 3. The description does not add meaning to parameters like 'id', 'noteid', or 'body' beyond what the schema already specifies.
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 'Update an account note' and includes the HTTP method and path. The verb 'update' and resource 'account note' are specific, but it does not differentiate from the similar sibling 'update_a_note'.
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 'create_an_account_note' or 'update_a_note'. The description only implies usage through the verb 'update' but lacks explicit 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?
Annotations already provide readOnlyHint=false, idempotentHint=true, destructiveHint=false. The description adds 'Idempotent' and 'in place', confirming but not adding significant new behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three short lines. It front-loads the verb and resource. Some may find it overly minimal, but it is efficient without 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?
For a tool with nested parameters and no output schema, the description is incomplete. It does not clarify whether the update is partial or full replacement, nor does it describe success response or error conditions.
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 100%, so baseline is 3. The description does not add any meaning beyond the schema; it does not explain how to use the body or id 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 'Update a contact' and 'Modifies an existing record in place', providing a specific verb and resource. The emoji and HTTP method add clarity. However, it does not distinguish from siblings like 'sync_a_contacts_data' or 'update_a_secondary_contact'.
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 does not mention that this is for updating an existing primary contact by ID, nor when to prefer it over create or sync 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?
Annotations already indicate idempotentHint=true and destructiveHint=false. The description adds 'Idempotent' and 'Modifies an existing record in place', which aligns with annotations but adds no new behavioral context (e.g., permissions, side effects, or field constraints). With annotations present, the description does not significantly enhance 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 relatively short, front-loads key information (emoji, path, verb), and avoids fluff. The two-sentence structure is efficient, though the 'Update a custom field' could be combined with the following sentence for slightly better 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?
Without an output schema, the description should explain what the response contains or confirm success. It also fails to clarify whether the update is partial or full (PUT with optional body suggests partial, but this is not stated). The nested object in body is not referenced, leaving ambiguity about which fields are updatable.
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 100%, so the schema fully documents parameters (id, body with nested properties). The description adds no additional meaning or context beyond what the schema provides, thus meeting the baseline without improvement.
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 'Update a custom field' and includes the resource path and HTTP method, distinguishing it from sibling tools like 'update_a_custom_field' or 'update_a_custom_deal_field_value' by naming 'Deal Custom Field Meta'. However, it could be more precise about the specific resource (deal custom field meta) to avoid confusion with similar 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?
The description does not provide any guidance on when to use this tool versus alternatives, such as 'update_a_custom_deal_field_value' for values or 'update_a_custom_field' for contact fields. No prerequisites or conditions are mentioned, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide idempotentHint=true and destructiveHint=false. The description adds 'Modifies an existing record in place,' which is consistent but adds limited extra context. No contradictions, but could disclose more about authentication or error states.
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 with front-loaded icons and HTTP method. It accomplishes its purpose without verbosity, though it could include a brief note on parameters or response without becoming lengthy.
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 nested parameters and no output schema, the description is minimal. It fails to explain how to construct the body or what the response contains, leaving gaps that the schema alone may not fully address 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 100%, so the schema already documents both parameters (id and body). The description adds no additional meaning beyond what the schema provides, meeting the baseline but not exceeding 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 it updates a custom field value for deals, with HTTP method and idempotency noted. However, it does not differentiate from sibling tools like 'update_a_custom_field_value' or 'bulk_update_a_custom_deal_field_value', which reduces specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as create or bulk update tools. The description lacks any 'when-to-use' or 'when-not-to-use' context, leaving the agent without decision support.
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?
Annotations already provide idempotentHint=true and destructiveHint=false. The description adds 'Modifies an existing record in place' and 'Idempotent', which aligns with annotations but does not disclose additional behavioral traits like error handling, side effects, or access requirements. Does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is short (5 lines) and front-loaded with key info (emoji, HTTP method, purpose). However, 'Update a deal' appears twice, introducing minor redundancy. Could be tightened without losing 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?
Tool is complex with nested body object and many fields, yet description omits return value, error handling, and example usage. With no output schema, more context is needed for an agent to confidently invoke this tool correctly.
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 100%, so the description carries minimal burden. The description only says 'Update an existing deal' without elaborating on parameters like 'id', 'body', or nested fields. Baseline 3 is appropriate as the schema already documents 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?
Clearly states 'Update a deal' and 'Modifies an existing record', using specific verb and resource. Siblings include create and delete deal tools, so purpose is distinguishable. However, the description repeats 'Update a deal' without further differentiation, missing a chance to explicitly set it apart from other update 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 on when to use this tool versus alternatives like update_a_deal_note or update_a_pipeline. The description does not mention prerequisites, context, or scenarios where this tool is preferred. The only hint is the HTTP method PUT and idempotency, but not contextual usage.
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?
Repeats idempotentHint from annotations, adds 'in place' context. No contradictions but no new behavioral traits beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Redundant phrasing, header and description repeat same idea. Could be more 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?
Adequate for a simple update tool with annotations, but lacks explanation of return value or side effects beyond mutation.
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 100%, so description adds minimal value beyond parameter names. No extra semantics for source enum or prompt.
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?
Clearly states it updates a broadcast using AI, distinguishing from create and possibly update_broadcast. However, not explicit about how AI differs.
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 broadcast update tools. Sibling update_broadcast exists but no comparison.
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?
Annotations already declare idempotentHint=true and destructiveHint=false. The description adds 'Idempotent' and 'Modifies an existing record in place,' which is consistent but does not disclose additional behavioral traits such as error handling or effects on related 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 with two lines and a clear emoji indicator. It avoids redundancy but could be more front-loaded with key information. The repetition of the title is a minor inefficiency.
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 of nested parameters and no output schema, the description lacks critical context: it does not explain what the 'record' is (field group membership), the effect of the operation, or error conditions. The endpoint path is mentioned but not explained.
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 100%, so baseline is 3. The description does not add meaningful context beyond the schema descriptions. The phrase 'Group Members' hints at the purpose of the body fields but does not clarify parameter roles or relationships.
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 'Update Custom Field Field Group' and 'Modifies an existing record in place,' which, combined with sibling names (add_custom_field_to_field_group, delete_custom_field_field_group), clearly indicates an update operation on a field group member. However, it could be more specific about the resource being updated (membership) rather than the field group itself.
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 the sibling add or delete tools. It lacks context about prerequisites or conditions that would warrant an update instead of add/delete.
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?
Annotations already indicate a write operation (readOnlyHint=false) and non-idempotent (idempotentHint=false). The description adds explicit detail: 'Not idempotent' and 'Creates a new record', confirming the write nature. It also includes the HTTP method (POST). No contradictions found.
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 short but contains redundancy: 'Create a stage' appears twice, and the same idea is reiterated. The emoji and HTTP method provide some structure, but the repetition wastes space. It is acceptable but not optimally 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?
Despite detailed input schema (100% coverage), the description lacks critical contextual information: what is returned on success, any required preconditions (e.g., pipeline must exist), or error scenarios. For a creation tool with no output schema, this leaves the agent guessing about post-invocation behavior.
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 100%, so the schema already documents all parameters thoroughly (e.g., color, group, order, etc.). The tool description adds no additional meaning or context beyond what the schema provides, meeting the baseline expectation.
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 a deal stage, specifying 'Create a stage for a pipeline'. This distinguishes it from sibling tools like create_a_pipeline or create_a_deal. The verb 'create' and resource 'deal stage' are clear, but there is slight redundancy with repeated 'Create a stage'.
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 only warns about non-idempotence ('calling twice may create duplicates'). It does not provide guidance on when to use this tool versus alternatives (e.g., update_a_deal_stage, create_a_pipeline), nor does it mention prerequisites like the pipeline must exist. Usage context is minimal.
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?
Annotations already indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=false. The description adds the non-idempotency warning, which is useful, but does not disclose other potential side effects or 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, front-loaded with key info, and contains no unnecessary words. 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 the complex input schema with many parameters and no output schema, the description lacks context about the return value, error handling, and the overarching purpose of the group. It is insufficient 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters. The description adds no additional meaning beyond the schema, which is adequate but does not explain the purpose of the group or permission fields.
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 ('Create'), resource ('a group'), and includes HTTP method and endpoint. It's distinct from siblings, but could benefit from specifying what a 'group' represents in this context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, prerequisites, or conditions. The description simply states the action without context for choosing it.
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?
Annotations already indicate write (readOnlyHint=false). Description adds value by explicitly noting non-idempotence. However, other behavioral traits (e.g., permissions, side effects) are not disclosed.
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 extremely concise with two sentences including the emoji prefix and POST path. Every element earns its place with no 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?
No output schema and no description of return values or post-creation behavior. For a creation tool, this is incomplete; it lacks information about what the response contains or what happens on success.
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?
Input schema has 100% coverage, so baseline is 3. Description does not add any extra meaning about the parameters (name, type, canSplitContent).
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 creates a campaign via POST and mentions it is a write operation. However, it does not differentiate from sibling tools like 'duplicate_campaign' or 'create_or_update_record'.
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 states it creates a new record and is not idempotent, but no when/why 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?
Annotations already indicate readOnlyHint=false, idempotentHint=false, and destructiveHint=false. The description reinforces the non-idempotency with a warning about duplicates. This adds marginal value beyond the annotations but does not contradict them. No additional behavioral traits (e.g., authentication needs, return format) are disclosed.
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 a metadata line and two short sentences. The metadata provides quick context (method, resource, HTTP verb). However, it could be better structured (e.g., using bullet points for key facts). Overall, it is efficient 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?
For a creation tool with no output schema, the description should ideally explain the response or error conditions. It does not, but the input schema is fully described. The duplicate warning adds some context. Given the low complexity (a single nested parameter), the description 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents each parameter with clear descriptions (e.g., fieldValue explains currency handling). The description does not add any further parameter semantics; baseline of 3 is appropriate.
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 explicitly states 'Create a custom field value' and 'Creates a new record', making the purpose clear. However, it does not differentiate this tool from sibling tools like update_a_custom_deal_field_value or retrieve_a_custom_deal_field_value, which would be helpful given the similar names.
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 (e.g., update or retrieve). It does not mention prerequisites (e.g., that the custom field must exist) or when not to use it. The only usage hint is the idempotency warning, but it lacks explicit context for decision-making.
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?
Annotations already provide readOnlyHint, destructiveHint, and idempotentHint. The description adds the warning about duplicate creation, which is useful. No further behavioral details like side effects or authentication needs are given.
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, using an emoji and brief sentences. Every part adds value, though it could be slightly more detailed.
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 (nested object) and lack of output schema, the description is adequate but lacks information about response format, error handling, or validation constraints beyond the 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 description coverage is 100%, so the schema thoroughly documents each parameter. The description does not add any additional meaning or usage tips 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 creates a list, specifies the HTTP method and endpoint, and highlights non-idempotency. However, it does not explicitly distinguish from other create tools, but the name and context make the purpose 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 versus alternatives like create_segment or create_a_list_group_permission. There is no mention of prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-idempotent (idempotentHint=false). The description adds a warning about flexibility and segment-builder compatibility, which is useful. However, it does not disclose return values, error scenarios, or side effects beyond duplicate creation.
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 concise but includes some redundancy (e.g., 'Creates a new record' after 'Create a Segment'). The front-loaded emoji and endpoint are good, but the warning 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?
Given the complex nested schema and lack of output schema, the description is insufficient. It does not explain what the response looks like, error handling, or required permissions. The warning about segment-builder is helpful but does not cover the missing context.
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 100% with detailed descriptions for all nested properties. The description adds a high-level caution about the data structure but does not enhance understanding of individual parameters beyond the schema. Baseline score 3 applies.
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 it creates a Segment and includes the HTTP method and endpoint. It is clear that the tool creates a new segment resource, but it does not explicitly distinguish from other create tools like create_a_new_contact. However, the name and context make the purpose sufficiently clear.
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 mentions non-idempotency and warns that only segment-builder-supported configurations work, advising users to refer to the builder page. However, it does not specify when to use this tool over alternatives like update_segment or retrieve_a_segment, nor does it mention prerequisites or authorization.
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?
Annotations already mark destructiveHint=true, and the description reinforces this with 'DESTRUCTIVE' and 'deletes data,' but does not add new behavioral traits beyond the annotations. The confirmation instruction is a useful addition, but overall transparency is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using a header with icon and HTTP method, followed by clear statements. Each sentence serves a purpose, though the header may partially repeat the title. No unnecessary wording.
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 simple tool with one parameter and no output schema, the description covers purpose and a key usage warning. It does not specify return values or side effects beyond deletion, but this is typical for a delete operation and overall completeness 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?
There is only one parameter 'id' with a clear schema description. The description does not add additional semantic meaning beyond the schema, so with 100% coverage, a baseline score of 3 is appropriate.
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 'Delete a list' and 'Deletes a record,' making the purpose obvious. It uses a strong verb-resource combination and distinguishes from siblings by specificity, though it does not explicitly differentiate from similar delete 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?
The only usage guidance is 'Confirm with the user before calling,' which suggests a prerequisite but lacks context on when to use this tool over alternatives, such as update or retrieve tools for lists. No explicit when-not-to-use or alternative recommendations.
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?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the description's '🔴 DESTRUCTIVE · deletes data' and 'Confirm with the user' reinforce but do not add significant behavioral info beyond the annotations. The description could mention permanence or side effects but does not.
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 repetitive: 'Delete a connection' appears twice, followed by 'Deletes a record' and 'Delete an existing connection resource.' It contains redundant lines that could be condensed into a single clear sentence. The structure is not 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 required param, no output schema) and annotations that cover safety, the description is adequate. However, it misses useful context like idempotency (though annotations indicate it) and potential side effects of deletion.
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 100%, and the schema description for 'id' is adequate. The tool description does not add any additional meaning about the parameter beyond what the schema already provides.
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 connection resource, using specific verb and resource. It differentiates from siblings by being explicitly for 'connections', not other entities. However, it lacks detail on what a connection is in this context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a usage guideline: 'Confirm with the user before calling.' This gives a safety cue. However, it does not specify when to use this tool versus other delete tools (e.g., delete_variable), nor does it exclude use cases or suggest 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?
Annotations already indicate it's a write operation (readOnlyHint false), not destructive (destructiveHint false), and idempotent. Description adds context that it unlinks records and is reversible, which is consistent. However, it could specify that it deletes a group member association, not the field group itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is short and includes useful meta information (emoji, HTTP method). Every sentence adds value, though the structure could be cleaner (e.g., integrating the emoji line with the main description). 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?
Given no output schema and simple parameters, the description explains the core effect (removing an association) and reversibility. However, it lacks specificity about which entities are unlinked (custom fields and field groups) and the example given (untagging contacts) seems mismatched with the tool name.
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 100% with descriptions for both parameters (body, groupID). The description does not add any meaning beyond what the schema provides. For example, 'groupID' could be clarified as the ID of the group member association, not the field group ID.
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 states it removes an association between records and is reversible. However, the tool name 'delete_custom_field_field_group' could be misinterpreted as deleting the field group itself, while the description clarifies it's an unlinking operation. This is somewhat clear but could be more explicit about what entities are unlinked.
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 like 'delete_a_custom_field_group' or 'add_custom_field_to_field_group'. The description does not differentiate from sibling delete tools or provide context on when unlinking is 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?
Annotations already provide destructiveHint and idempotentHint. The description adds a user confirmation note beyond annotations, which is valuable. However, it does not explain consequences like irreversibility or cascading effects, missing an opportunity for fuller transparency.
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 overly repetitive: 'Delete a webhook' appears three times, and 'Deletes a record' is redundant. The opening tag line is useful, but the rest could be condensed into one or two sentences, wasting space.
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 and no output schema, the description covers the basic action. However, it lacks details on error handling (e.g., webhook not found) and success response, making it only adequately 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?
The input schema fully describes the 'id' parameter with coverage 100%. The description adds no additional meaning about the parameter, such as where to find the ID or validation rules, so the baseline score of 3 applies.
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 a webhook' and the resource type. The name and symbol reinforce the purpose. However, the description is repetitive with three nearly identical statements, which slightly reduces clarity.
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 safety instruction 'Confirm with the user before calling,' which helps guide proper use. However, it does not explicitly differentiate from other delete tools like 'delete_a_record' or 'update_webhook,' leaving the choice to the agent's implicit understanding.
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 includes 'READ-ONLY' and 'Makes no changes', which aligns with annotations (readOnlyHint=true, destructiveHint=false). Annotations already declare safety, so the description adds minor context (HTTP method) but does not disclose rate limits or other 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (3 lines), with the READ-ONLY badge and endpoint upfront. Every sentence adds value, but it could briefly mention that this retrieves a specific exclusion by ID to improve clarity without adding verbosity.
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 with one parameter, annotations, and no output schema. The description minimally covers the operation but does not explain what an exclusion is or what the response contains, which might be helpful for an agent with no prior context.
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 100% coverage with a single parameter 'id' described as 'ID of the exclusion to retrieve'. The description does not add any additional meaning or format hint beyond the schema, so it scores baseline 3.
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 'Retrieve an exclusion' and 'Fetches data', indicating the action and resource. The name includes 'retrieve_an_exclusion', reinforcing the purpose. However, it does not explicitly differentiate from the sibling tool 'exclusions_retrieve_a_list', which retrieves a list of exclusions.
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 'exclusions_retrieve_a_list' or 'update_an_exclusion'. There is no mention of prerequisites or scenarios where this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false. The description repeats 'Fetches data. Makes no changes' but adds no new behavioral details such as pagination or rate limits. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but includes redundant phrasing ('List all webhook events' appears twice). The emoji and HTTP method add some context but are not essential. 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?
The tool has 4 optional parameters with nested objects (orders, filters) and no output schema. The description does not explain what a webhook event is or what the response contains, leaving the agent uninformed about return values.
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 100% (each parameter has a description). The tool description does not add additional meaning beyond the schema, so baseline score of 3 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 'List all webhook events' with a verb and resource. It distinguishes from sibling tools like get_a_list_of_webhooks (which lists webhook endpoints) and get_webhook (singular).
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 the tool is for listing webhook events but provides no guidance on when to use it vs. similar list tools like get_a_list_of_webhooks. No explicit alternatives or exclusions are given.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description echoes 'Fetches data. Makes no changes,' which is consistent but adds no new behavioral details (e.g., pagination default, rate limits, empty results). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description contains redundancy ('List all webhooks' appears twice) and a repeated emoji/annotation. While front-loaded with purpose, it could be more concise by removing duplicate lines.
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 list tool with 7 optional parameters and no output schema, the description provides the core purpose and safety profile. The parameter descriptions in the schema cover details like pagination and filtering, so the description is reasonably complete without needing to restate them.
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 100% with thorough parameter descriptions. The tool description does not add any parameter information beyond the schema, so baseline score of 3 is appropriate.
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 'List all webhooks' and 'Fetches data. Makes no changes,' making the tool's purpose unambiguous. However, it does not explicitly distinguish from sibling tools like 'get_webhook' (single webhook) or other list 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 on when to use this tool versus alternatives (e.g., get_webhook). No exclusions or prerequisites are mentioned, leaving the agent to infer usage from 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?
Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description reinforces 'Fetches data. Makes no changes' and adds endpoint info, but provides no additional behavioral traits like pagination behavior or response structure.
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 to the point, but includes an emoji and endpoint string which may be considered clutter. Still, it is front-loaded and efficient with minimal 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 annotations (readOnlyHint, idempotentHint) and schema coverage, the description is minimally adequate but does not explain return values or pagination details. Since output schema is absent, a brief note on response structure 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?
Input schema has 100% description coverage, so the description adds no extra meaning for parameters. Baseline score of 3 is appropriate; the description does not document parameters beyond what schema provides.
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 'Get All Custom Field Groups' and specifies it is read-only and fetches data. The verb+resource is clear, but it does not differentiate from sibling tools like list_all_custom_fields_meta, which limits specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description lacks context on prerequisites, when-it-is-appropriate, or when to choose other 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?
Annotations already provide rich safety hints (readOnlyHint, openWorldHint, idempotentHint, destructiveHint). Description adds only the HTTP method and 'Makes no changes', which adds minimal value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Contains redundant phrases ('Retrieve a branding' appears twice) and clutter (emoji, all-caps). Could be more concise without losing meaning.
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 read-only tool with one parameter and rich annotations, the description is barely adequate. It does not describe the return format or any expected output, but the output schema is not provided.
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?
Description does not explain the 'id' parameter or its role. With 0% schema coverage, the description should clarify that the ID identifies which branding to retrieve. The single parameter is obvious but could be clearer.
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 'Retrieve a branding', 'Fetches data. Makes no changes', and includes the HTTP method and endpoint. Distinguishes from sibling tools like 'brandings' (likely list) and 'update_branding'.
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?
Implied usage for retrieving a single branding by ID, but no explicit guidance on when to use this vs. other tools like 'brandings' (list all). No when-not-to-use or alternatives 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds 'READ-ONLY' and 'Makes no changes', which aligns but adds little extra. No deeper behavioral info like pagination limits 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description has minor redundancy (e.g., 'List all accounts' and 'Retrieve all existing account'). It is short but could be more streamlined. Front-loaded with read-only indicator.
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 6 parameters and many sibling tools, the description lacks context on pagination behavior, default ordering, or relationship to other account endpoints. Minimal for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with detailed param descriptions. Tool description does not add any extra semantic meaning beyond what is already in the input 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 'List all accounts' and 'Retrieve all existing account', using specific verb and resource. It is distinct from sibling tools like 'list_all_contacts' or 'retrieve_an_account'.
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 alternatives (e.g., 'search' or 'retrieve' specific account). No exclusions or context for when this list is 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?
Annotations already provide readOnlyHint=true and destructiveHint=false. The description reinforces by stating 'Fetches data. Makes no changes'. Adds no additional behavioral context beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is very short (3 lines) and front-loaded with a label and endpoint. Every sentence serves a purpose. 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 one parameter, no output schema, and comprehensive annotations, the description is adequate. However, it does not mention that the tool corresponds to a GET endpoint or specify the response format, leaving some gaps for the 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 100%, with parameter 'id' described as 'ID of the calendar feed to retrieve'. The description does not add extra meaning beyond the schema. Baseline of 3 is appropriate.
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 'Retrieve a calendar feed' which is a clear verb+resource. The tool name 'list_all_calendar_feeds_1' could imply listing, but the description corrects to single retrieval. Does not explicitly differentiate from sibling 'list_all_calendar_feeds' but the required 'id' parameter implies singular.
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 'list_all_calendar_feeds' or other retrieve tools. Lacks context on prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description confirms read-only behavior and no side effects, which aligns with annotations. It adds context about the endpoint and that it deals with deal data. However, it doesn't mention pagination or rate limits, though annotations already provide safety hints.
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, front-loading the read-only indicator and endpoint. Every sentence adds value 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 the tool has 5 parameters including pagination and filters, the description is minimal. It doesn't explain pagination or filtering behavior, but the schema covers parameters adequately. Output format is not described, but no output schema exists.
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 100%, so baseline is 3. The description adds no parameter-specific information beyond what the schema already provides.
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 reads deal custom field values. It uses a verb ('List') and a resource ('custom field values'). However, it does not differentiate this tool from similar sibling tools like 'list_all_custom_field_values' or 'list_all_custom_field_values_2'.
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 are many similar list tools among siblings, but the description provides no criteria 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?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description reinforces read-only nature but adds no new behavioral details beyond the HTTP method. With annotations present, the description adds minimal value but does not contradict.
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, using markers and a clear structure. It front-loads the key information (read-only, resource, endpoint). However, it could be more informative about the response without becoming overly long.
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, and the description does not explain the return structure or pagination behavior beyond what the parameters imply. While the tool is simple, some additional context about the response format 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?
Schema coverage is 100% with detailed parameter descriptions for limit, offset, orders, search, and filters. The description does not add any additional meaning beyond the schema, achieving the baseline for high 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 verb 'List' and the resource 'deal roles', and indicates it's read-only. However, it does not explicitly differentiate itself from sibling list tools like list_all_deals or list_all_deal_stages, relying on the tool name for distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description only states what it does, not when to choose it over other list tools 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds 'Makes no changes' but does not disclose pagination behavior, rate limits, or other traits beyond annotation scope.
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 front-loaded with the core action. However, the emoji and 'READ-ONLY' label are somewhat redundant with annotations.
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 tool with 4 parameters and no output schema, the description covers the basics but lacks details on pagination handling or result structure. It is adequate but not comprehensive.
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 100%, so parameters are well-documented. The description does not add additional context beyond what the schema provides, resulting in baseline score.
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 'List all messages' and specifies the HTTP method and read-only nature. However, it does not differentiate from sibling tools like list_all_contacts or list_all_deals, which share the same 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 (e.g., get_broadcast, retrieve_a_message). The description only states it's read-only, which is already in annotations.
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?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description adds that it makes no changes and is a GET request, which is consistent but does not add significant new behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded. However, it repeats 'List all orders' twice and has extra symbols (🟢, ·). Still, it is efficient and easily scanned.
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?
With 18 optional parameters and no output schema, the description does not mention pagination, filtering capabilities, or how to use the parameters effectively. The schema covers details, but the description could summarize key usage patterns.
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 100%, so the schema fully documents each parameter. The description does not add any additional meaning or examples for parameters. Baseline 3 is appropriate.
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 lists all orders and is read-only. It mentions the endpoint and that it fetches data without making changes. However, it does not explicitly distinguish from sibling tools like 'get_order', though the name and context imply it.
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, exclusions, or when not to use it. Given many sibling tools for orders, this is a gap.
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?
Annotations already declare readOnlyHint and idempotentHint. Description adds 'Fetches data. Makes no changes' which reinforces but doesn't exceed annotations. No disclosure of potential behavior like default pagination or sorting.
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?
Very concise (one sentence plus labels). Front-loaded with read-only indicator and endpoint. Could include more detail without being wasteful.
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 list tool with no output schema, the description is decent but lacks explanation of what 'EcomOrderProducts' are, relationship to orders, or that it returns a list of objects with pagination metadata.
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 100% with clear parameter descriptions for limit, offset, orders, filters. Description adds no additional parameter context, so baseline score of 3 is appropriate.
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?
Clearly states 'List EcomOrderProducts' with a read-only indicator and endpoint. However, it does not differentiate from siblings like 'list_products_for_order' which may overlap in functionality.
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 alternatives (e.g., 'list_products_for_order' or 'retrieve_an_ecomorderproduct'). No context on appropriate conditions for pagination or filtering.
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 adds context beyond annotations by stating the HTTP method ('GET'), endpoint path, and that it 'Makes no changes' to the account. This reinforces the read-only and idempotent hints from annotations. No contradictions. However, it does not detail pagination or result structure.
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 short (5 lines) but contains repetition: 'List Flow Execution Contacts' appears twice. It is not overly verbose, but the redundancy reduces conciseness. Structure 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?
With 14 parameters, no output schema, and a list operation, the description lacks details on pagination, filtering behavior, and what the response contains. This is insufficient for a complex tool; more context 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?
Input schema has 14 parameters with 79% description coverage. The tool description does not add any parameter-specific information beyond what is already in the schema. Given high coverage, baseline score of 3 is appropriate.
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 'List Flow Execution Contacts' and 'Fetches data. Makes no changes.' It clearly identifies the tool as a read-only list operation. However, it does not explicitly distinguish from sibling 'get_flow_execution_contact' (singular) which likely retrieves a single item. The purpose is clear but lacks explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., 'get_flow_execution_contact'). No when-to-use, when-not-to-use, or prerequisites are mentioned. The read-only nature is already captured by annotations.
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 aligns with annotations (read-only, idempotent, non-destructive), but adds no behavioral detail beyond confirming read-only nature.
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?
Very concise with read-only indicator upfront, but lacks any parameter or usage structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Minimal description; while acceptable for a simple fetch tool, it fails to explain what personalization tags are or how scoping works.
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?
Input schema has 100% description coverage, so the description adds no additional parameter 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 it fetches personalization tags and is read-only, but it does not differentiate from similar list/retrieve 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 on when to use this tool vs alternatives among many sibling retrieval 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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds 'Fetches data. Makes no changes.' which is consistent but does not provide additional behavioral context beyond the annotations. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with 'READ-ONLY' and the HTTP method. It conveys the necessary information without extraneous text, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of the tool and rich annotations, the description is adequate. However, it does not mention the return format or data structure, which could be helpful since there is no 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 100%, and the parameter 'id' is described in the schema as 'ID of the field to retrieve'. The description does not add any extra semantic meaning or usage details for the 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 'Retrieve a custom field' and 'Fetches data. Makes no changes.' It identifies the resource (custom deal field meta) and action (retrieve). However, it does not explicitly differentiate from similar sibling tools like retrieve_a_custom_field_meta, 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?
The description implies a read-only operation but provides no explicit guidance on when to use this tool versus alternatives (e.g., list_all_custom_fields_meta or retrieve_all_custom_deal_field_meta). It does not mention prerequisites or that an ID is required, which is already in the schema.
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?
Annotations already provide readOnlyHint, idempotentHint, etc. The description adds the HTTP method 'GET /fields/{id}' and states 'Fetches data. Makes no changes.' which reinforces but does not substantially extend the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the read-only indicator, resource type, and HTTP method. It efficiently communicates the tool's function without 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?
For a simple read tool with rich annotations, the description covers the basics. However, it fails to clarify that 'contact' in the tool name refers to contact custom fields, which may cause confusion. The lack of output schema is not an issue here.
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 100% with a single parameter 'id' described as 'ID of the field to retrieve'. The description adds no further semantics 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 retrieves a custom field by ID using 'Get a custom field by ID'. It distinguishes itself from write tools but not from similar 'retrieve' siblings like 'retrieve_a_custom_field_meta' or 'retrieve_a_custom_field_value'.
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 other retrieve tools. No exclusions or context provided.
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?
Annotations already declare readOnlyHint and destructiveHint=false, so the description's 'READ-ONLY' and 'Makes no changes' reinforce but add no new behavioral insights. The description does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the emoji and label. However, it redundantly states 'Retrieve a stage' twice. Still efficient with minimal 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?
Given no output schema and simple input, the description is sufficient for a straightforward retrieve-by-ID tool. However, it could mention that the response contains stage details, but basic completeness is met.
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 100% for the single 'id' parameter, so the description does not need to elaborate. It adds no extra meaning beyond what the schema provides, earning a baseline score of 3.
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 (retrieve) and resource (stage) with 'Retrieve a stage' and 'Fetches data'. It includes the HTTP method and labels like 'Deal Stages', distinguishing it from other tool types. However, it could more explicitly differentiate from 'list_all_deal_stages' which retrieves multiple stages.
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 siblings like 'list_all_deal_stages' or other retrieve tools. The description does not mention prerequisites, when not to use, or provide any contextual hints for an agent to decide appropriately.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description merely restates 'Fetches data. Makes no changes.' which is consistent but adds little beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise at two sentences plus a decorative line. It is front-loaded with the method and emoji, but the structure could be improved with bullet points for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter and rich annotations, the description is mostly adequate. However, there is no output schema and the description does not hint at the return format or structure, which is a minor gap.
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 100% for the single parameter 'id', and the schema provides a description. The tool description does not add any additional semantics or examples 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 verb 'Retrieve' and resource 'custom field value', and explicitly says it makes no changes. However, it does not differentiate from the sibling tool 'retrieve_a_custom_field_value', which appears to have the same purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the many similar retrieve tools (e.g., retrieve_a_custom_field_value). The description lacks usage context 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?
Annotations already declare readOnlyHint, idempotentHint, and no destructive behavior. The description adds the HTTP method, endpoint path, and restates that it is read-only and makes no changes. This adds some context but no new behavioral details like rate limits, authentication requirements, 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 short and includes a visual indicator and method, which is efficient. However, it could be better structured with clear sections like 'Purpose' and 'Notes'. Nonetheless, it avoids unnecessary verbosity.
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 is adequate. It states the operation is read-only and fetches data, but does not describe the return structure or fields. More detail on what data is returned 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?
The input schema has 100% coverage with a description for the 'id' parameter. The tool description does not add any additional meaning beyond what the schema provides, so the baseline score of 3 is appropriate.
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 an EcomOrderProduct, with verb 'Retrieve' and resource 'EcomOrderProduct'. It also includes the HTTP method and path. However, it does not explicitly distinguish from the sibling tool 'list_ecomorderproducts' which lists all products, though the name and single ID parameter imply retrieval of a single item.
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 'list_ecomorderproducts' or other retrieval tools. It lacks any context for selection, such as conditions 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description's statements ('Fetches data. Makes no changes') add little beyond confirming safety. It does not disclose additional behaviors like required permissions 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with only two functional sentences plus an emoji line. It is front-loaded with key information (read-only, resource). However, the HTTP method line is redundant with the REST endpoint implied by the name.
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 an output schema, the description does not explain the return structure (e.g., list of deals with fields). It adequately states the purpose but could be more complete for a tool with five parameters and pagination.
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 covers 100% of parameters with descriptions. The tool description adds no additional parameter-specific meaning; it merely restates the function. With full schema coverage, the baseline is 3.
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 'Retrieve a contact's deals' with a specific verb and resource. The title also repeats this. However, there is a sibling tool named 'retrieve_contact_deals_list' which could cause confusion, and the description does not differentiate between them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus its alternatives, such as 'list_all_deals' or 'retrieve_contact_deals_list'. It lacks context about prerequisites or exclusivity conditions.
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?
Annotations already include readOnlyHint, idempotentHint, openWorldHint, and destructiveHint false. The description adds the HTTP path and repeats 'Fetches data. Makes no changes', which aligns with annotations but does not provide additional behavioral context beyond structured 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 and front-loaded with a read-only indicator and HTTP path. However, there is minor redundancy: the title line is repeated in the description. Overall, it is efficient but not perfectly lean.
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 does not mention return values or pagination behavior, though parameters imply pagination. Given no output schema, more context on what the response contains would improve completeness. Still adequate for a simple retrieval 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?
Input schema has 100% description coverage for all 5 parameters, so the schema already documents parameter semantics adequately. The description does not add any extra parameter information 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 retrieves a contact's field values, specifying the resource and verb. However, it does not distinguish itself from siblings like 'retrieve_a_custom_field_value' or 'list_all_custom_field_values', which could lead to 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?
The description provides no guidance on when to use this tool vs alternatives. It only states it is read-only, which is already indicated by annotations. No context on when not to use or preferred scenarios.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description reinforces 'Fetches data. Makes no changes.' but adds no extra behavioral context (e.g., auth needs, rate limits, data scope).
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?
Extremely concise: two sentences plus a header. Every word is necessary and there is no 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?
Despite good annotations and schema, the description is too brief. With no output schema, it fails to explain the return format (e.g., list of log entries), pagination, or what the logs contain, leaving agents underinformed.
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 100% with descriptions for all 5 parameters. The description does not add meaning beyond the schema, so baseline 3 is appropriate.
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 'Retrieve a contact's logs' and includes the endpoint, making the resource and action clear. However, among siblings like 'retrieve_contact_tracking_logs' and 'retrieve_contact_bounce_logs', it doesn't differentiate which log type this retrieves.
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 alternatives like 'retrieve_contact_tracking_logs'. The description does not mention context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description repeats these with 'Fetches data. Makes no changes' and includes the HTTP method/path, but adds no new behavioral details (e.g., pagination, sorting, or response structure).
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 a visual indicator and path. However, it contains minor redundancy (two sentences conveying the same read-only intent).
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 5 parameters, nested objects, and no output schema. The description does not explain the return format or pagination behavior, though annotations provide safety context. More detail on response structure 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?
The input schema has 100% description coverage, so the schema already documents all parameters. The tool description adds no additional parameter meaning beyond what is in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Retrieve' and the resource 'a contacts notes', and the title from annotations confirms this. It is specific to contact notes, but does not differentiate from sibling tools like 'retrieve_a_note' or 'retrieve_list_of_all_notes'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, nor does it distinguish from similar read tools for notes.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds the HTTP method and path ('GET /campaigns/{id}/links') and states 'Fetches data. Makes no changes,' which reinforces but does not significantly extend beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with key info (read-only, endpoint). However, it repeats the title phrase, which is slightly redundant but not wasteful.
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 read-only tool with 5 parameters and no output schema, the description covers the basics but lacks details on return format, pagination behavior, or common usage scenarios.
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 100%, so the description does not need to add parameter details. It adds no extra meaning beyond what the schema provides, meeting the baseline for high 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 retrieves links associated to a campaign, using specific verb and resource. It is distinguishable from sibling tools by its focus on campaign links, though not explicitly differentiated.
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 'retrieve_a_campaign' or other list tools. It lacks usage context 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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds 'Fetches data. Makes no changes', which reinforces but does not extend beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Contains repetitive statements ('Retrieve site tracking code' and 'Get site tracking code' are redundant). Could be more concise without losing 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?
No output schema and the description does not indicate what the endpoint returns (e.g., a code string or URL). The parameters imply a list response, but the tool's name suggests a single code—ambiguity remains.
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?
All 4 parameters have schema descriptions (100% coverage), so the description adds no additional meaning. Baseline 3 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 action ('Retrieve') and resource ('site tracking code') with a specific verb. It includes a READ-ONLY label and HTTP method, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like retrieve_site_tracking_status or enable_disable_site_tracking. The description only states it's read-only, which is implicit.
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?
Annotations indicate readOnlyHint=false and destructiveHint=false. The description adds that messages are irreversible once delivered, which is useful behavioral context beyond annotations. However, it does not disclose auth requirements, rate limits, or what happens on failure. The behavioral transparency 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, with key information front-loaded in the structured header line. The explanation is direct and avoids verbosity. Minor repetition (e.g., 'Send a WhatsApp Template' appears twice) 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?
No output schema is provided, and the description does not explain the return value or error responses. It mentions scheduling but does not detail how to schedule. For a 2-parameter tool with nested objects, the description covers the core usage but misses some contextual details like prerequisites (e.g., template must exist) and scheduling mechanics.
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 100%, so parameters are well-documented. The description restates the need for a template ID, recipient phone number, and variables, but adds little new semantic value beyond the schema. Baseline score of 3 is appropriate.
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 sends or schedules outbound WhatsApp template messages to recipients. The verb 'send' and resource 'WhatsApp Template' are specific. However, mentioning SMS alongside WhatsApp may cause slight confusion, and it does not explicitly distinguish this tool from siblings like 'create_broadcast' or 'list_whatsapp_templates'.
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 warns that messages are not reversible once delivered, advising to confirm the audience first. However, it lacks explicit guidance on when to use this tool versus alternatives, such as when to use broadcast vs. single template message, or when scheduling is needed. No comparisons to sibling tools are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds only 'READ-ONLY' and 'Makes no changes,' which duplicates the annotation. No additional behavioral details (e.g., pagination behavior, authentication, rate limits) are provided, falling short of enhancing transparency beyond structured signals.
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 metadata). The READ-ONLY indicator and HTTP method are front-loaded. However, the structure could be improved by explicitly naming the resource or adding a brief example, but it remains 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?
With 5 parameters, nested objects, and no output schema, the description provides minimal context. It confirms read-only and resource type but does not explain what 'Stripo config' contains, how pagination works, or the response format. Annotations help, but the description could be more complete for a tool with moderate complexity.
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 80% (4 of 5 parameters have in-schema descriptions). The description adds no parameter-specific information; it merely states the tool fetches config. Baseline score of 3 is appropriate since the schema does most of the documentation work.
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 fetches Stripo config data and is read-only. The READ-ONLY emoji and 'Makes no changes' clarify the action. However, it does not explicitly differentiate from siblings like 'set_config' beyond the read-only hint, leaving slight ambiguity.
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 for reading Stripo config without side effects, but lacks explicit when-to-use or when-not-to-use guidance. No alternative tools are mentioned, and the agent must infer from the read-only annotation that this is for retrieval only.
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?
Annotations already declare idempotentHint=true and destructiveHint=false, and the description echoes 'idempotent' and 'write'. However, no additional behavioral traits (e.g., required permissions, error conditions) are disclosed beyond what annotations provide, meeting the baseline with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (three lines) with no wasted text. However, the inclusion of emoji and method is slightly noisy; still, it is efficient 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?
The description covers the basic behavior (modify existing record, idempotent) but missing details like return values, error handling, or what happens if the record doesn't exist. Given no output schema, more context would be beneficial, but annotations cover safety.
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 100% (both 'id' and 'body' have descriptions). The description adds no extra meaning beyond the schema, so the baseline score of 3 is appropriate.
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 'Update a calendar feed' with the verb 'update' and resource 'calendar feed'. It distinguishes the resource type but does not differentiate from other update tools in the sibling list, which all share similar verbs.
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, nor does it mention prerequisites or scenarios to avoid. With many sibling update tools, this lack of context is a significant gap.
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?
Annotations already declare idempotentHint=true and destructiveHint=false. The description adds 'Modifies an existing record in place. Idempotent.' which reinforces idempotency and adds 'in place' context, but this is minimal extra value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and includes the HTTP method upfront, but the first line with emojis and 'WRITE' is somewhat redundant with annotations. Still, it efficiently communicates the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update tool with no output schema, the description is adequate but lacks details on return values or the effect of 'useDefaults'. It covers the essential, but more context would help the 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 100%, so the description adds no additional parameter explanation. The schema itself describes parameters well. Baseline of 3 is appropriate.
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 'Update' and resource 'custom field value for contact', and the annotation title reinforces this. While the name alone distinguishes from sibling 'update_a_custom_field_value', the description does not explicitly differentiate, so it loses some points.
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 alternatives like 'update_a_custom_field_value' or similar update tools. No prerequisites or when-not-to-use advice is given.
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?
Annotations already provide idempotentHint=true, destructiveHint=false. Description adds 'Modifies an existing record in place' and confirms idempotency, but adds no new behavioral insights beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description repeats 'Update a deal note' twice and includes optional decorative elements. It is somewhat fragmented but not overly long.
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 good schema coverage, the description lacks context about error conditions, required permissions, or what the response looks like. A mutation tool with no output schema should provide more behavioral context.
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?
Input schema has 100% description coverage for all three parameters. Description adds no additional semantic information beyond what the schema already provides, so baseline score of 3 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 updates a deal note, distinguishing it from siblings like create_a_deal_note and delete_note. The resource (deal note) and action (update) 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 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 vs alternatives like update_a_note (general note) or create_a_deal_note. Lacks prerequisites 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?
Annotations already provide idempotentHint and destructiveHint. Description adds 'modifies in place' and 'idempotent', which align, but lacks details on error behavior, partial updates, or side effects. Adds minimal value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Key info is front-loaded (method, resource, endpoint), but there is redundancy ('Update an association' repeated). Somewhat concise but could be tighter.
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?
Does not explain return value (no output schema), whether body is optional for partial updates, or error conditions. For a mutation with nested parameters, more context 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 coverage is 100%, so baseline is 3. Description adds no additional semantics for parameters beyond stating the tool updates an association.
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 updates an association (account contact), specifies the HTTP method (PUT) and endpoint, and distinguishes from siblings like create and delete 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 on when to use this tool vs alternatives. Does not mention prerequisites, when to avoid, or comparison with other update tools among siblings.
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?
Annotations already declare idempotentHint=true and destructiveHint=false. The description redundantly states 'Idempotent' and adds 'Modifies an existing record in place,' which provides minimal extra context. No mention of authorization, rate limits, or side effects beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise with a clear structure, using an emoji and HTTP method header. However, it contains slight redundancy ('Update a branding' and 'Update an existing branding resource') and could be more compact without loss of meaning.
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 lacks information about the response format, required permissions, and possible error states. The detailed body schema partially compensates, but for a write operation, more context (e.g., success/failure indicators) 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 100%, so the schema fully documents parameters. The description adds no additional meaning beyond the schema, merely repeating the update action. Baseline 3 is appropriate as the schema handles parameter 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 identifies the tool as updating a branding resource, using the verb 'Update' and specifying the resource type. It also mentions the HTTP method and idempotent behavior. However, it does not distinguish this tool from sibling update tools like update_broadcast or update_connection, lacking differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. It merely states what the tool does without context for selection among similar update 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?
Annotations already indicate readOnlyHint=false, destructiveHint=false, idempotentHint=false. The description adds that the call is not idempotent and may create duplicates, which aligns with annotations. No additional behavioral traits (e.g., auth needs, rate limits) are disclosed.
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 reasonably concise but has redundancy: 'Add domain to whitelist' appears in both the title and the body. It is front-loaded with the method and endpoint, but could be streamlined.
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 write operation with no output schema, the description provides the endpoint and idempotency note. However, it does not explain the response or error handling, which is acceptable 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 description coverage is 100%, so the schema already documents the single required parameter. The description only repeats the domain action without adding new 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 the action 'Add domain to whitelist' and the resource 'domain to site tracking whitelist'. It is distinct from siblings like 'remove_domain_from_whitelist' and 'list_all_whitelisted_domains', but does not explicitly differentiate.
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 header indicating it's a WRITE operation with the endpoint, but does not specify when to use this tool over alternatives or any prerequisites. Usage is implied by name and 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?
Description states 'Modifies an existing record in place. Idempotent.' which aligns with annotations (idempotentHint: true, destructiveHint: false). It also provides the HTTP method and endpoint (PATCH /deals/bulkUpdate), adding value beyond annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but includes non-essential formatting (emoji, bold) and repeats 'Update an existing deal' after already stating the purpose. It could be cleaner by focusing on key information without decorative elements.
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?
With annotations and schema covering safety and parameters, the description adds endpoint and idempotent note. However, it lacks mention of return values or expected response. Given no output schema, the description could be more complete by describing what the response looks like.
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 100%, so parameters are fully documented in the schema. The description does not add any additional meaning or usage hints beyond what the schema provides (e.g., that id is required, ownerId format). Adequate but no extra value.
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 'Bulk Update Deal Owners' and 'Update an existing deal', specifying the action and resource. It distinguishes from sibling tools like 'update_a_deal_new' by emphasizing bulk operation. However, it could be more precise about the scope (e.g., only updating ownerId, not other fields).
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. Sibling tools include individual deal updates and other bulk updates, but the description does not provide criteria for choosing this tool. No exclusions or prerequisites 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?
Annotations already indicate write operation (readOnlyHint=false) and non-idempotence (idempotentHint=false). The description adds the note about duplicate creation, but does not provide further behavioral details like side effects, permissions, or rate limits. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively short but contains redundancy: 'Create a deal note' appears twice, and 'creates a new record' is repeated. The structure is adequate but could be more concise by removing duplicate statements.
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 with only two parameters and no output schema. The description adequately covers the basic functionality but lacks details like what the response looks like or any prerequisites. Given the low complexity, the description is minimally 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 100%, so parameters are fully documented in the input schema. The description does not add any additional meaning or context about the parameters (e.g., 'id' is a deal ID, 'body.note.note' is the note content). Baseline score of 3 is appropriate.
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 verb 'Create' and resource 'deal note' along with HTTP method and path. However, it does not explicitly differentiate from sibling tools like 'create_a_note' (generic note creation) or 'create_an_account_note', leaving some ambiguity about when to use this specific tool.
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 mentions idempotency ('Not idempotent — calling twice may create duplicates'), which provides some guidance. However, it lacks explicit context on when to use this tool versus other note creation tools or prerequisites, such as requiring an existing deal.
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?
Annotations already provide readOnlyHint=false, idempotentHint=false. The description adds 'Not idempotent' and 'may create duplicates,' which aligns with annotations but does not reveal additional behavioral traits such as authorization needs 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentences plus a header. It front-loads the purpose and includes key metadata (WRITE, creates data, endpoint). 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?
No output schema exists, and the description does not mention return values, error conditions, or success indicators. For a creation tool with nested objects, more context about the response 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?
Input schema coverage is 100% (all parameters described in schema). The description adds no parameter-specific information beyond what is already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a schema' and mentions 'Custom Objects' and the endpoint. However, it does not distinguish this tool from sibling tools like 'create_a_child_schema' or 'create_a_public_schema', which reduces clarity for an AI agent selecting among similar options.
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 (e.g., child or public schema creation). No prerequisites or context for when it is appropriate to create a schema via this endpoint.
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?
Annotations already mark destructiveHint=true. The description adds 'Confirm with the user', enhancing safety awareness. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Relatively short but has redundancy (e.g., 'Delete a custom field value' then 'Deletes a record'). Could be more streamlined.
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?
Adequate for a simple one-parameter tool, but missing details on return values, error handling, or differentiation between account vs deal custom field values.
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 100% for the single parameter. Description adds no additional meaning beyond what the schema provides.
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?
Clearly states 'Delete a custom field value' and 'Deletes a record', identifying the action and resource. However, does not differentiate from similar siblings like delete_a_custom_deal_field_data.
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?
Only provides 'Confirm with the user before calling' as guidance. No when-to-use or comparison with alternative delete 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?
The description explicitly calls out 'DESTRUCTIVE' and 'deletes data', consistent with annotations (destructiveHint=true). It adds the safety instruction to confirm with the user. However, it does not disclose irreversibility, cascading effects, or whether a soft delete occurs. Annotations already cover the destructive nature, so the description provides marginal added value.
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 repetitive: 'Delete an account' appears twice, and 'Deletes a record.' and 'Delete an existing account' are similar. It could be tightened to one sentence. However, it is still relatively short.
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?
With one required parameter and no output schema, the description covers the destructive nature and safety confirmation. However, it lacks details on response behavior (e.g., returns success message or just 200) and whether the account is physically removed or archived. The annotations partially compensate, but completeness is adequate but not thorough.
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 100% with the 'id' parameter described as 'Account's id'. The description does not add meaning beyond the schema, which is acceptable given high coverage. No extra context like format constraints or examples is provided.
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 'Delete an account' with the verb 'delete' and resource 'account'. It differentiates from sibling delete tools (e.g., delete_a_deal) by specifying 'Accounts' in the header. However, it could be more explicit about what an 'account' represents in this context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a direct instruction: 'Confirm with the user before calling.', which is a clear usage guideline. However, it lacks details on when to use this tool versus alternatives (e.g., bulk_delete_accounts) and does not mention prerequisites like ownership or permissions.
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?
Annotations already include destructiveHint=true; the description adds a user confirmation reminder but does not elaborate on side effects like cascading deletions or idempotency. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description contains redundancy: 'Delete a pipeline' appears twice and 'Deletes a record' adds little value. Could be more concise without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with one required parameter and clear annotations, the description is adequate but could note any constraints (e.g., pipeline must exist) or return behavior.
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 100% with a clear description for the only parameter 'id'. The description does not add extra context beyond 'Pipeline's id', meeting the baseline.
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 'Delete a pipeline' and includes 'DESTRUCTIVE · deletes data · Deal Groups', making the action and resource unambiguous. It distinguishes from sibling delete tools by specifying the pipeline resource.
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 safety guideline 'Confirm with the user before calling.' However, lacks explicit guidance on when to use versus alternatives or prerequisites (e.g., pipeline must have no active deals).
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description reiterates read-only nature ('Fetches data. Makes no changes'), but adds no behavioral context beyond that—e.g., pagination behavior, rate limits, or error handling. The description does not deepen transparency beyond what annotations offer.
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 relatively brief and front-loads the HTTP method and endpoint. The repetition of 'Get broadcast recipients' and 'Fetch all contacts...' is slightly redundant, but overall it is efficient with no extraneous detail. It is structured with line breaks for 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 tool's complexity (11 parameters, nested objects, many filters, no output schema), the description is insufficient. It omits return format, pagination details, how filters interact, and the effect of engagement/deliverability parameters. An agent lacks guidance to use the tool effectively with all its options.
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 100% (all 11 parameters described), so baseline is 3. The description does not add any extra meaning beyond the schema—no parameter examples, no clarification of when to use filters, etc. It neither harms nor significantly improves parameter understanding.
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 broadcast recipients via 'Get broadcast recipients' and 'Fetch all contacts who were sent a specific broadcast'. It uses a specific verb and resource, distinguishing it from related tools like 'get_broadcast' (broadcast details) and 'export_broadcast_recipients' (export operation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates a read-only operation ('READ-ONLY', 'Makes no changes'), but it does not explicitly guide when to use this tool versus alternatives such as 'get_broadcast_metrics' or 'export_broadcast_recipients'. No direct contrast with sibling tools is provided, leaving usage context to the agent's inference.
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?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint. Description adds 'Fetches data. Makes no changes' which confirms but does not add new behavioral context beyond annotations. No mention of pagination, rate limits, or snapshot contents.
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 minimal repetition, but the emoji/HTTP line and separate 'Get broadcast snapshot' line could be merged. Still efficient 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?
Despite having good schema coverage and annotations, the description lacks explanation of what a 'snapshot' entails and does not differentiate from other broadcast retrieval tools (e.g., get_broadcast_snapshot_by_ids, get_broadcast_metrics). Missing output schema increases need for description 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 coverage is 100%, so parameters are fully documented in the schema. Description does not elaborate on parameters or provide additional context beyond what the schema already provides. Baseline 3 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?
Description clearly states it retrieves broadcast snapshot data for all broadcasts, with specific HTTP method and path. Distinguishes from siblings like get_broadcast_snapshot_by_ids by implying it returns all broadcasts rather than filtered by IDs.
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 get_broadcast, get_broadcast_metrics, or get_broadcast_snapshot_by_ids. Only states it fetches data without changes, but does not specify context 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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description reinforces that it 'Fetches data. Makes no changes' but adds no additional behavioral context beyond what the annotations provide. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively short but contains repetition (e.g., 'Get Flow Execution Contact by Id' appears twice) and an emoji/endpoint line that doesn't add useful information. It could be more 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?
For a simple tool with one parameter, no output schema, and clear annotations, the description is adequate. However, it does not describe what the fetched data contains or suggest typical use cases, leaving some 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?
The schema has 100% description coverage for the single parameter 'id', which is documented as 'A Flow Execution Contact Id to Retrive.' The description adds no further meaning or usage details 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 explicitly states 'Get Flow Execution Contact by Id' and clarifies it fetches data without making changes. It uses a specific verb (Get) and resource (Flow Execution Contact), clearly distinguishing it from sibling tools like create_flow_execution or list_flow_execution_contact.
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, nor does it mention when not to use it. It lacks any contextual advice for selection among the large set of sibling 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false; description adds 'READ-ONLY' and 'Fetches data' but doesn't expand on return structure or pagination 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?
Description is very short (one sentence plus header); could be trimmed 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?
Lacks explanation of what 'summaries' means vs full segment data, no output schema, and does not clarify pagination behavior beyond schema, especially with 8 parameters.
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 covers 100% of parameters with descriptions; description adds no additional parameter details, so baseline score of 3 applies.
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 'List Summaries for Saved Segments' and 'Fetches data', but doesn't differentiate from sibling get_saved_segment_summaries_by_id or list_all_segments.
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 context ('Fetches data. Makes no changes.') but no guidance on when to use this vs 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?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint. The description reinforces with 'READ-ONLY' and 'Makes no changes,' but adds no further behavioral details like rate limits or data freshness considerations.
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, front-loaded with an emoji indicator, resource label, and HTTP method. Every element contributes meaning 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?
For a simple read tool with one parameter and annotations, the description is adequate but lacks details about the response structure or what the summary contains. The absent output schema makes this a minor gap.
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 100% with a single 'segmentId' parameter. The description does not explain what constitutes a segment summary or the expected format of the ID beyond the schema's example. Baseline score given high 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 'Retrieve a Saved Segment's Summary' and 'Fetches data,' indicating a read operation for a specific segment. However, it does not differentiate from sibling tools like 'retrieve_a_segment' or 'get_segment_historic' which may have overlapping functionality.
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 alternatives. The description lacks context on prerequisites, use cases, or situations where other segment-related tools would 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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. Description adds 'Fetches data. Makes no changes.' which aligns but adds limited value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is short but contains redundancy: 'Retrieve a user' appears twice. Emoji and path add minimal value. Could be more 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 single parameter, annotations, and no output schema, description covers basics. However, lacks detail on returned fields, which would be helpful given many sibling retrieval tools.
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 covers 100% of parameters with description. The tool description does not add additional meaning beyond what the schema provides, so baseline 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 verb 'Retrieve' and resource 'user'. It distinguishes from sibling tools that are update/delete/create variants of user operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus other user retrieval tools like get_user_email or get_user_loggedin. The description lacks 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds 'Fetches data. Makes no changes' which reinforces annotations but doesn't add new behavioral insights beyond the endpoint path.
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 reasonably concise but includes redundant elements like the endpoint URL and emoji. Could be tightened to a single sentence without losing meaning.
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 simplicity of the operation (single required param, read-only, no nested objects, no output schema), the description adequately covers what the tool does and its single input. It doesn't describe the return format, but that is common for standard CRUD tools.
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?
Only one parameter id is required, and the description explicitly explains it is the template Id. Despite 0% schema coverage, the description compensates by stating 'Gets a WhatsApp Template by Id', clarifying the parameter's purpose.
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 'Get WhatsApp Template' and 'Gets a WhatsApp Template by Id', indicating a specific read operation. It implicitly differentiates from sibling tools like list_whatsapp_templates which lists all templates, but lacks explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like list_whatsapp_templates or send_a_whatsapp_template_message. The agent must infer usage from 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?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true. Description adds 'Fetches data. Makes no changes' which aligns but does not add extra context like pagination limits or authentication.
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: 3 short lines, front-loaded with read-only indicator and endpoint. 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?
Lacks details about the response format (no output schema) and does not clarify pagination behavior despite having pagination parameters. Minimal but functional.
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?
Input schema has 100% coverage with descriptions for all 4 parameters, so the description adds no additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'List all calendar feeds' and includes 'GET /calendars' and 'Read-only' indicators. However, it does not differentiate from the sibling 'list_all_calendar_feeds_1', 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 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 (create, update, remove, or the _1 variant). Only describes 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?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint=false. The description merely reiterates 'Fetches data. Makes no changes,' adding no new behavioral context beyond what the annotations supply. It fails to mention pagination behavior or any other traits not covered by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but contains redundancy: 'List all connections' and 'List all existing connection resources' say essentially the same thing. It could be more concise without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool, the description covers the basic purpose and safety (via annotations). However, it lacks details on pagination behavior (limit/offset) and response format (no output schema). Completeness is adequate but not thorough.
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 100% for 6 parameters, each well-described in the schema. The description does not add any parameter-specific context, so it meets the baseline of 3 for schema-covered tools.
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 'List all connections' and 'List all existing connection resources,' with a READ-ONLY label and GET /connections endpoint. It unambiguously identifies the verb (list) and resource (connections), distinguishing it from sibling tools like get_connection (single) and create_connection.
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 read-only usage with 'Fetches data. Makes no changes' but does not explicitly guide when to use this tool versus alternatives like get_connection for a single connection or create_connection for writing. Usage is implied by the resource type, but no when-not or explicit context is provided.
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?
Annotations already declare readOnlyHint and destructiveHint. Description adds that it fetches data and makes no changes, consistent but not adding significant new behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Short and front-loaded with read-only badge and HTTP method. Some redundancy between 'List all deals' and 'Retrieve all existing deals', 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?
Despite 30 parameters and no output schema, description omits pagination behavior, return structure, or any explanation of 'all deals'. Incomplete for a complex list 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?
Input schema has 100% parameter description coverage, so description adds no further meaning. Baseline 3 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?
Clearly states the tool lists deals, is read-only, and fetches data. Reinforces with HTTP method and 'makes no changes'. Distinguishes from mutation tools in sibling list.
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 alternatives like create/update/delete deal tools. No mention of 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?
Annotations already declare readOnlyHint and idempotentHint. The description adds 'Fetches data, makes no changes' and a READ-ONLY badge, which is consistent but provides no additional behavioral context beyond what annotations convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the read-only badge and title. However, 'List Variables' is repeated, and the sentence 'Fetches data. Makes no changes.' is redundant given annotations. Still concise overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite 13 parameters, the description does not explain pagination (limit/offset), sort/filter behavior, or return format. No output schema exists, leaving the agent without critical usage context for a list 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?
Input schema covers 100% of parameters with descriptions. The tool description itself adds no parameter meaning or usage context, so score is at baseline for high schema 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 the tool lists personalization variables with 'Retrieve a list of personalization variables' and includes the HTTP method. It distinguishes from sibling tools like 'list_all_contacts' by specifying the resource (variables).
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 (e.g., retrieve_variable for a single variable). The description does not mention use cases, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true and destructiveHint=false. The description adds 'Modifies an existing record in place. Idempotent.' This repeats the idempotent hint and adds 'modifies in place', which is consistent but adds minimal new context. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but includes redundant statements: 'Move tasks to another task type' appears twice. The header line is useful but could be integrated. Some repetition reduces conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward move operation with good schema and annotations, the description is adequate but lacks detail on the response or side effects. No output schema exists, and the description does not explain what happens after moving tasks, leaving some ambiguity.
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 100%, so baseline is 3. The description does not add any meaning beyond the schema for the id or body parameters. It simply restates the overall purpose without detailing parameter roles.
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 moves deal tasks to another task type, using specific verbs 'Move tasks' and 'Move tasks to a different task type'. The header indicates it's a write operation for Deal Tasktypes. This distinguishes it from sibling tools like update_a_deal_task_type (which updates the type itself) and move_deals_to_another_deal_stage (moves deals, not tasks).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not specify prerequisites, scenarios for use, or when not to use it. Lacks comparisons with sibling tools like update_a_deal_task_type.
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?
Annotations already provide readOnlyHint, destructiveHint, idempotentHint. The description reinforces these but adds no new behavioral context (e.g., pagination, rate limits, default ordering). Not contradictory.
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?
Extremely concise with emoji, endpoint, and a sentence. No wasted words, but could be slightly expanded with key details while remaining 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?
Despite having 7 parameters including pagination and filtering, the description does not mention these capabilities. The description is too minimal for a tool with this complexity.
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 100% coverage with descriptions for all 7 parameters. The tool description adds no parameter-specific information beyond the schema, so baseline of 3 applies.
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 verb 'List all tags' and specifies the resource. The emoji and 'GET /tags' add clarity. No confusion about what this tool does among 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 explicit guidance on when to use this vs alternatives like 'retrieve_a_tag' for a single tag. The description only states what it does, not when to choose it.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description reinforces this with 'Fetches data. Makes no changes' and includes the HTTP method GET. However, no additional behavioral details beyond what annotations already provide are included, so the description adds minimal value.
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, consisting of three lines including an emoji, the HTTP method, and two short sentences. Every part serves a purpose: indicating read-only state, the resource type, and the action. No unnecessary information is present.
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 read-only tool with one parameter and comprehensive annotations, the description provides adequate context. However, it does not explain what a 'score' represents in ActiveCampaign or mention potential error scenarios. Since there is no output schema, some return format expectations might be useful.
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' with full schema coverage (100%). The schema already describes it as 'ID of the score to retrieve'. The description does not add any additional parameter-specific information, so it meets the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Retrieve a score') and identifies the resource. It includes additional context like 'READ-ONLY' and the endpoint path. However, it does not distinguish this tool from siblings like 'retrieve_a_contacts_score_value' or 'list_all_scores', which may cause confusion about which tool to use for specific score retrieval needs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There are siblings like 'retrieve_a_contacts_score_value' and 'list_all_scores' that might be more appropriate in some contexts. The description lacks any when-to-use, when-not-to-use, or alternative recommendations.
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 fetches data and makes no changes, reinforcing the annotations (readOnlyHint, idempotentHint). However, it does not disclose additional behavioral traits like pagination behavior or rate limits, which would add value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, with three short sentences that convey the essential information. It is front-loaded with the read-only indicator and HTTP method, and every sentence contributes value 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?
For a simple retrieval tool, the description is adequate but lacks information about the return format or what the response contains (e.g., list of bounce logs with fields). Given no output schema, such details 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?
Schema coverage is 100% with each parameter described. The tool description does not add any additional meaning to the parameters beyond what the schema already provides, so it meets the baseline.
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 a contact's bounce logs and that it is read-only, with the HTTP method and endpoint included. It distinguishes the specific resource (bounce logs) from other contact log tools, though it does not explicitly differentiate from sibling tools like retrieve_contact_logs.
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 does not provide guidance on when to use this tool versus alternatives (e.g., retrieve_contact_logs, retrieve_contact_tracking_logs). It only states it is read-only and fetches data, but no explicit 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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description merely restates 'Makes no changes' without adding new behavioral context (e.g., pagination limits, rate limits, idempotency guarantees).
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 to the point, with front-loaded emoji summary and clear verb. However, the emoji and all-caps 'READ-ONLY' add minimal value and could be removed.
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 4 parameters for pagination and filtering, but the description does not explain how to use them or the return format. Without an output schema, the description should at least mention the response type or behavior.
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?
Input schema covers 100% of parameters with descriptions, so baseline is 3. The description adds no parameter-specific meaning beyond what the schema provides.
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 retrieves a list of all notes and is read-only. It uses specific verb + resource ('Retrieve list of all notes') and distinguishes from sibling CRUD tools for notes (e.g., create_a_note, delete_note).
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 no explicit guidance on when to use this tool vs alternatives like retrieve_a_note for single note retrieval. It does not mention filtering or pagination use cases, despite sibling tools for specific operations.
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?
Annotations already provide idempotentHint=true and destructiveHint=false. The description adds endpoint info but no further behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, with a header and two short sentences. No redundant 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 tool with nested parameters, the description is minimal. No explanation of return values or field constraints beyond schema. Adequate but could be improved.
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 100%, so the description does not need to add parameter meaning. It adds no extra semantics beyond what the schema provides.
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 a custom field and includes the HTTP method and endpoint. It is specific but does not differentiate from sibling tools like 'update_a_custom_field'.
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. Sibling tools include several update tools, but no context is provided for choosing this one.
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?
Annotations already provide readOnlyHint=false, destructiveHint=false, and idempotentHint=true. The description adds 'Idempotent' and 'PUT /tags/{id}' (HTTP method), but otherwise merely confirms write behavior without new behavioral insights.
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: two short sentences. No wasted words. Front-loaded with the operation type and resource. Efficient and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers key aspects (operation, resource, idempotence) and the schema is well-documented. However, it lacks details on return behavior, error scenarios, or prerequisites, which would be valuable for a mutation tool without 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 100%, so baseline is 3. The description does not add any additional meaning or examples beyond what the schema already provides for 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?
Clearly states the tool updates a tag and modifies an existing record in place. The verb 'Update' and resource 'Tags' are specific, but it does not differentiate from sibling tools like 'update_a_contact_tag' or 'update_a_custom_field_value' beyond the resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description lacks context on when not to use it or comparison with similar update tools in the sibling list.
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?
Annotations already provide idempotentHint=true and destructiveHint=false. Description adds HTTP method (PUT) and 'Modifies an existing record in place', but repeats idempotency already in annotations.
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?
Repetitive: 'Update a connection' appears twice, and 'Update an existing connection resource' adds no value. Could be concise with a single sentence and structured metadata.
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 or return value description. Complex nested body parameter is not explained beyond schema. Lacks error handling or field update semantics.
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 100%, so baseline is 3. Description does not add parameter-specific meaning beyond what schema already documents.
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 'Update a connection' with verb 'Update' and resource 'connection'. Distinguishes from sibling tools like create_connection, delete_connection.
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?
No explicit when-to-use vs alternatives. The verb 'Update' implies modifying an existing connection, but lacks guidance on when to prefer this over other update tools among siblings.
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?
Annotations already provide readOnlyHint=false, idempotentHint=true, destructiveHint=false. The description adds 'Idempotent' and 'in place', but lacks details on auth requirements, side effects, or response format. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose with repetition: 'Update a user' appears twice, and the emoji/method line is extraneous. Could be more concise while maintaining clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 2 parameters and no output schema, the description covers basic purpose and idempotency. However, it omits whether partial updates are allowed (body has optional fields) and any validation constraints, which could 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 100%, and both parameters (id, body) are well-described in the schema. The description does not add any extra meaning beyond what the schema provides, so baseline 3 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 'Update a user' and 'Modifies an existing record in place', with a title in annotations. The verb (update) and resource (user) are explicit, distinguishing it from siblings like create_user, delete_user, get_user.
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 update_a_contact_new or other update tools. No prerequisites or exclusions are mentioned, so the agent has no 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint, idempotentHint, destructiveHint. Description explicitly states READ-ONLY and 'Makes no changes', aligning well. It also provides the endpoint path. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is very short and includes a visual prefix. It front-loads the key read-only nature. Could be slightly more structured but is 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?
Given no output schema, the description provides basic intent but nothing about return structure. With 4 parameters and nested objects, more detail on what the response contains would improve completeness. Adequate but not rich.
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?
All 4 parameters have descriptions in the schema (100% coverage). The description does not add extra meaning beyond the schema, which is acceptable. Baseline 3.
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 fetches bulk import statuses and is read-only. The title and entity tags reinforce the purpose, though it could be more explicit about exactly which import statuses are returned.
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 alternative tools like bulk_import_status_info or bulk_import_contacts. The description does not indicate prerequisites or 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?
Annotations already indicate it's a write (readOnlyHint false), non-destructive (destructiveHint false), and idempotent (idempotentHint true). The description confirms 'Modifies an existing record in place. Idempotent.' but adds no further behavioral context beyond annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with three sentences that efficiently communicate the operation, resource, HTTP method, and key property (idempotency). 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?
Despite the tool having a nested input schema (body > array) and no output schema, the description does not explain the expected format of the request body (e.g., whether 'array' is genuinely an object or an array of objects), error handling, or return value. This lack of completeness could lead to misuse.
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 100%, with each parameter documented. The tool description adds no additional meaning about parameter usage, making it redundant. Baseline 3 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 this tool does a bulk update of custom field values for accounts, specifying the resource 'Account Custom Field Data' and HTTP method PATCH. The name differentiates it from siblings like 'bulk_update_a_custom_field_value' (for deals) and 'bulk_create_a_custom_account_field_value'.
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 lacks any guidance on when to use this tool versus alternatives like single-update or create tools. No prerequisites or scenarios are provided, leaving the agent without direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states 'Not idempotent — calling twice may create duplicates', which adds behavioral info beyond the annotations (idempotentHint: false). It also labels the tool as 'WRITE'. However, it does not disclose other traits like authentication requirements, rate limits, or what happens if a field with the same title exists. Given annotations are present, the description adds moderate value.
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 single header line with emoji and HTTP method, plus two short sentences. It front-loads the key information (create, not idempotent). However, it could be slightly more structured by separating the purpose from behavioral traits.
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 does not explain what the tool returns (e.g., the created field object or an ID). It also does not mention that this creates a contact-specific custom field, though the tool name implies it. For a creation tool with a nested input schema, the description is adequate but could be more complete by describing the response or linking to contact context.
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 100% description coverage for all parameters, so the description does not need to add extra meaning. The tool description does not highlight required fields ('title' and 'type') or clarify the nested object structure. Baseline 3 is appropriate as the schema already covers parameter 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 'Create a custom field' and uses verbs 'creates' with resource 'custom field'. The header 'WRITE · creates data · Fields' further distinguishes it from sibling tools like 'create_a_custom_field_group' or 'create_a_customfieldmeta'. The tool name explicitly includes 'contact_custom_field', making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 'create_a_custom_field_group' or 'create_a_customfieldmeta'. It does not specify prerequisites, or situations where this tool should be avoided. No exclusions or alternative tool references are given.
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?
Annotations already indicate non-read-only, non-idempotent, and non-destructive behavior. The description adds 'Not idempotent — calling twice may create duplicates,' which aligns and adds slight context, but no additional behaviors (e.g., auth, rate limits) are disclosed.
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 repetitive ('Create a deal' appears twice, plus 'Creates a new record'). While it includes a useful first line with emoji and method, it could be more concise 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's complex nested schema and no output schema, the description is too minimal. It lacks information on prerequisites, expected response, or when to use this tool over others. Annotations provide basic hints but the description does not compensate for the tool's complexity.
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 100% coverage with detailed descriptions for all parameters. The description does not add any parameter-level information beyond what the schema provides, meeting the baseline for high 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 'Create a deal' and 'Creates a new record.' It includes the HTTP method and endpoint, and the title from annotations reinforces the purpose. The tool name and description distinguish it from sibling tools like create_a_deal_note or update_a_deal_new.
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 this tool is for creating a new deal but provides no explicit guidance on when to use it vs alternatives (e.g., update_a_deal_new). It mentions idempotency but does not specify prerequisites or context for usage.
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 explicitly states 'Not idempotent — calling twice may create duplicates,' which adds value beyond the annotations (idempotentHint=false). It also clarifies it's a write operation. However, it could mention side effects or required 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 concise and front-loaded with an emoji, method, and resource. However, there is slight redundancy between the title and the first sentence. Efficient but not perfect.
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 lacks information about the return value (e.g., the created record) and any prerequisites. For a creation tool with no output schema, this is a gap. 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 100% with descriptions for listid and groupid. The description does not add any additional meaning or context for the parameters, so baseline 3 is appropriate.
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 a list group permission and provides the HTTP method and resource. However, it does not explicitly differentiate this tool from similar sibling tools like 'create_new_list' or 'create_a_group', which also create resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description does not mention prerequisites, context, or exclusions, leaving the agent with no decision support.
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?
Annotations already indicate readOnlyHint=false and idempotentHint=false. The description adds the explicit warning that calling twice may create duplicates, which is valuable. However, it does not elaborate on other behavioral aspects like 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, with a header line providing method, resource, and endpoint, followed by a clear purpose and a behavioral note. Every sentence is informative without 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?
The description lacks information about return values (no output schema), prerequisites, or error conditions. For a creation tool, failing to mention what is returned (e.g., the created address ID) leaves the agent without full context.
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 100% with descriptions for nested fields like 'country'. The description does not add any additional parameter guidance beyond what is in the schema, relying entirely on the input schema for 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 'Create an address' and 'Creates a new record', using specific verb and resource. It also distinguishes itself from update/delete siblings by emphasizing creation, and notes non-idempotence, which adds specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'update_an_address' or other creation tools. It only notes non-idempotence as a caution, but fails to explicitly state usage 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?
Annotations already indicate idempotentHint=false and readOnlyHint=false. The description adds value by explicitly stating 'Not idempotent — calling twice may create duplicates', which clarifies the real-world consequence of repeated calls. It also includes a write indication ('🟡 WRITE · creates data'). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using only three lines with clear labeling (emoji, type, endpoint). The second line 'Create a tag' is somewhat redundant with the title, but overall it is well-structured and waste-free.
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 could explain what the tool returns (e.g., the created tag object). It also lacks information about required fields or prerequisites. However, for a simple creation tool with 100% schema coverage, it provides sufficient context for basic usage.
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 100%, with each parameter having a description (e.g., 'Name of the new tag'). The description does not add any additional meaning or context beyond what the schema already provides, so the baseline score of 3 is appropriate.
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 'Create a tag' and mentions the endpoint 'POST /tags' and resource 'Tags'. It uses a specific verb+resource combination. However, it does not explicitly differentiate from sibling tools that also create entities (e.g., create_a_new_contact, create_a_new_group), missing a chance to improve sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'retrieve_a_tag' or 'update_a_tag'. There is no mention of prerequisites, context, or exclusions. The only behavioral note is about idempotency, which does not cover usage guidelines.
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?
Annotations already indicate write operation and non-idempotency. The description reiterates this but adds no new behavioral context beyond what annotations provide. No side effects or prerequisites mentioned.
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 brief but contains some redundancy (e.g., 'Create a note' and 'Creates a new record'). It is front-loaded with relevant annotations but 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 tool's simplicity, good annotations, and full schema coverage, the description covers essential aspects: operation type, idempotency, and HTTP method. Lacks details on return value but acceptable without 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 description coverage is 100%, with clear descriptions for all parameters (note, reltype, relid). The description adds no additional parameter information, so baseline 3 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 it creates a note, specifies the HTTP method POST /notes, and uses specific verbs like 'Create a note' and 'Creates a new record'. This distinguishes it from sibling tools like delete_note or update_a_note.
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 other create tools (e.g., create_a_deal_new). No context about prerequisites or exclusions. The description only mentions idempotency, which is not a usage guideline.
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?
Annotations already indicate write and non-idempotent behavior. The description adds value by explicitly stating 'creates data' and 'Not idempotent — calling twice may create duplicates', enhancing transparency beyond annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two metadata lines and two sentences. Essential information is front-loaded (WRITE indicator, endpoint), with no extraneous 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?
Despite reasonable complexity (nested schema with fields, relationships), the description omits what the tool returns on success, possible errors, or side effects. No output schema exists, so the description should compensate.
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 100% schema description coverage, the input schema already documents the body parameter and its nested properties. The description adds no additional parameter-level meaning, meeting the baseline expectation.
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 (create), resource (public schema), and includes the endpoint path. However, it does not differentiate from sibling tools like create_a_schema or create_a_child_schema, which may cause confusion about when to use this specific tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool over alternatives or what prerequisites exist. The description only states the basic purpose and idempotency, but lacks contextual usage instructions.
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 explicitly notes that the tool is not idempotent and may create duplicates, which goes beyond the annotations (idempotentHint: false). It adds value by highlighting this behavioral trait.
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 repetitive, stating 'Create a connection' multiple times. It is adequate but 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?
Despite no output schema, the description does not mention return values, error handling, or any prerequisites. For a create tool, this is insufficient for complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema documents all parameters. The description adds no additional meaning about the body or its properties beyond what the schema provides.
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 connection resource, with a specific verb and resource. It distinguishes from siblings like 'create_a_deal_new' or 'create_a_new_contact' by focusing on 'connection'.
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. No mention of context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states the tool is not idempotent, going beyond annotations which only set idempotentHint: false. It also labels the operation as 'WRITE' creating data. However, it does not disclose error behaviors, rate limits, or side effects beyond duplication.
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 with emoji and method, then the purpose, then a key behavioral note. Every sentence adds value, and there is no redundant 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?
As a creation tool with no output schema, the description should mention what the response contains (e.g., created object). It also lacks information about required fields (fieldLabel and fieldType) which are only in the schema. The description feels incomplete for an agent to understand the full effect.
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 100% with all properties having descriptions. The description itself adds no additional parameter information beyond what is already in the schema, so it meets the baseline of 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 action ('Create'), the resource ('custom field meta' for deals), and even includes the HTTP POST endpoint. It distinguishes from sibling tools like 'create_a_customfieldmeta' (generic) and 'create_custom_deal_field_value' by specifying 'deal' and 'meta'.
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. Among many sibling create tools, the description does not mention prerequisites, conditions, or comparison with similar tools like 'create_a_customfieldmeta' or 'create_custom_deal_field_value'.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds that it fetches data and makes no changes, which is consistent but not additive beyond the annotations for safety. No disclosure of rate limits or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: three short sentences with an emoji, HTTP method, and endpoint. All information is front-loaded, and no redundant or wasteful text.
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 two-parameter read operation with full annotation coverage, the description is adequate. It explains the endpoint and that no changes are made. However, lacking an output schema, a brief note on what is returned 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?
Both parameters (contactId and segmentId) are fully described in the schema (100% coverage). The description adds no additional meaning or constraints beyond the schema, providing no extra context for parameter usage.
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 fetches data via GET /segmentMatch/{segmentId}/{contactId} and makes no changes. It identifies the resource (Match One Request) and the action (create, though actually a read). The READ-ONLY label and endpoint pattern distinguish it from siblings like create_match_all_request, though not explicitly.
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 alternatives such as create_match_all_request or segment_match_check_by_external_id. The description does not mention prerequisites or typical scenarios.
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?
Annotations provide readOnlyHint=false and destructiveHint=false, but the description adds a critical non-idempotency warning ('calling twice may create duplicates'), which goes beyond the structured fields. This helps the agent understand the safe but non-idempotent nature of the operation.
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 contains repetition ('Create an order' appears twice) and an emoji line that adds little value. Though relatively short, it could be more concise and front-loaded with the core 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 high parameter complexity (nested objects, required fields) and no output schema, the description lacks guidance on response format, usage patterns, or handling of mutual exclusive fields (externalid vs externalcheckoutid). The schema covers details, but the description fails to provide a complete contextual overview.
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 100% with detailed field descriptions. The description adds no additional parameter semantics beyond what the schema already provides. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Create an order' and 'Create a new e-commerce order resource,' with a clear verb and resource. Among siblings like 'update_order' and 'delete_order,' it uniquely identifies this tool as the creation endpoint.
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 'update_order' or other create tools. The only usage hint is the idempotency warning, but it lacks explicit context for when to prefer this over sibling 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?
Annotations already indicate idempotentHint=false and readOnlyHint=false. The description adds 'Creates a new record' and 'Not idempotent', which reinforces but does not significantly extend beyond the annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with three short lines. However, the first line includes emojis and HTTP method info which may be considered clutter. It is efficient overall.
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 simplicity of the tool (one parameter, no output schema) and the presence of annotations, the description is minimally complete. It explains the action and the non-idempotent nature, but it does not explicitly mention that it copies an existing campaign or what the return value might be.
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 100% description coverage for the single parameter 'id', described as 'id of the source campaign'. The description adds no additional information about parameters beyond what the schema provides, so baseline 3 is appropriate.
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 duplicates a campaign and creates a new record. The verb 'duplicate' and resource 'Campaign' are visible. However, it does not explicitly say that it copies from an existing campaign, which would differentiate it from create_campaign.
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 warning about non-idempotence, which is useful. However, it does not provide explicit when-to-use or alternatives compared to create_campaign or edit_campaign. The context from sibling tools is not leveraged.
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 adds value beyond annotations by noting that the tool uses a POST method that returns data, does not change account records, and may create a short-lived cached result-set. This aligns with the readOnlyHint and idempotentHint annotations, providing useful context about its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the purpose. It uses a clear header line with emoji and method, followed by a simple explanation. 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?
Given there is no output schema, the description does not explain what the snapshot contains, which could be important for the agent. It mentions the caching behavior but lacks details on the return value 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 description adds meaning to the 'body' parameter by stating it expects 'specified broadcast IDs'. The schema lacks a description for the 'ids' property, so the description compensates. However, it does not clarify the format or constraints beyond what the schema provides.
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: 'Get broadcast snapshot' and 'Returns snapshot for specified broadcast IDs'. It specifies the verb ('Get') and resource ('broadcast snapshot'). However, it does not explicitly differentiate from sibling tools like 'get_broadcast_snapshot' or 'get_broadcast_metrics', 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 guidance is provided on when to use this tool versus alternatives, such as get_broadcast_snapshot or get_broadcast_metrics. There is no mention of prerequisites, exclusions, or 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?
Annotations already provide readOnlyHint=true and destructiveHint=false. The description adds the HTTP method and path, but doesn't disclose additional behavioral traits beyond what annotations convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with emoji and path. However, it repeats 'Retrieve an order' twice.
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 read operation with one parameter and comprehensive annotations, the description provides sufficient context: purpose, read-only nature, and HTTP details.
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 100% with a clear description for ecomOrderId. The description adds no additional parameter 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 the tool retrieves an order and is read-only, using specific verb 'Retrieve an order' and resource. However, it does not explicitly distinguish from sibling tools like 'list_all_orders' which also fetch order data.
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 (e.g., list_all_orders). The description only states what it does, not the context for its 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds the confirmation 'Makes no changes' and the HTTP method 'GET'. This is consistent but does not disclose additional behavioral details like pagination behavior 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—three lines including a visual icon, endpoint, and a clear statement of purpose. Every sentence adds value without redundancy. It is front-loaded with key 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?
While the description clearly indicates a read-only list operation, it omits details about the response structure, pagination behavior, or how the returned data is shaped. With no output schema, the agent must guess the response format. Given the tool's complexity (4 parameters, nested objects), the description is 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?
The input schema has 100% coverage with descriptions for all four parameters (limit, offset, orders, filters). The description does not elaborate on these parameters beyond what the schema provides, so it meets the baseline but adds no extra meaning.
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 'List all addresses' and 'Fetches data. Makes no changes to your ActiveCampaign account.' The title 'List all addresses' and the READ-ONLY badge provide a specific verb and resource, distinguishing it from sibling tools like 'list_all_contacts' or 'list_all_accounts'.
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 mention exclusions (e.g., 'for filtered addresses use search_*') or contrasting with other listing tools. The user must infer that this is the generic address listing tool.
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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds the HTTP method (GET) and endpoint path, providing useful behavioral context beyond annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise—three lines with no extraneous text. It is front-loaded with the read-only indicator and purpose. Efficient, though slightly more detail could be added.
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 is provided. The description explains the tool lists automations and is read-only, but does not describe the return structure (e.g., fields of an automation object). For a list tool with pagination parameters, this 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?
Input schema has 100% description coverage for its four parameters (limit, offset, orders, filters). The tool description adds no additional parameter details beyond what the schema provides.
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 'List all automations' and 'Fetches data. Makes no changes,' establishing a specific verb and resource. However, it does not explicitly distinguish from sibling list tools (e.g., list_all_contacts, list_all_deals), though the 'all' qualifier implies a broad scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description lacks 'when-not-to-use' or recommended contexts, relying solely on the readOnlyHint annotation.
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 annotations already include readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well-covered. The description adds basic confirmation ('Fetches data. Makes no changes') and the endpoint path, but does not disclose any additional behavioral traits beyond what annotations provide. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the emoji and key labels. It conveys the purpose in one sentence and confirms safety in two more. Every sentence adds value with no fluff, though the structure could be improved by separating purpose from safety notes more clearly.
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 (list all) and the presence of annotations and schema descriptions, the description is minimally complete. However, with no output schema, it would benefit from mentioning what is returned (e.g., 'returns a list of custom field meta objects'). It is adequate but leaves room for improvement.
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 100% parameter description coverage, with each parameter (limit, offset, orders, filters) clearly documented. The description does not add any parameter-specific meaning; it only states the overall purpose. Therefore, the description meets the baseline but does not enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all custom fields' and specifies it's for Account Custom Field Meta, with GET endpoint. It distinguishes from sibling tools like create_a_customfieldmeta or retrieve_a_custom_field_meta, but could be more explicit about the scope (e.g., 'list all custom field meta' instead of 'custom fields').
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 indicates it's a read-only operation ('Fetches data. Makes no changes') and provides a READ-ONLY emoji, which implies safe usage. However, it lacks explicit guidance on when to use this tool versus alternatives like retrieve_a_custom_field_meta or list_all_custom_field_values, and no mention of 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description's claim of 'Makes no changes' is consistent but adds little. The description does not disclose pagination behavior, rate limits, or what 'All' means in terms of scope. Given strong annotations, the additional value is modest.
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 a clear safety indication. However, the first line repeats information found in the title and annotations, making it slightly redundant. It is efficient but could be more streamlined.
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 lacks context about what group limits are, how the data is structured, or any scoping rules. The openWorldHint suggests no user filtering, but this is not explained. Without an output schema, the return format is not described.
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 100%, so the baseline is 3. The description adds no additional meaning beyond the schema; it does not explain parameter usage or common combinations.
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 identifies the tool as listing all group limits, with a specific verb ('List') and resource ('Group Limits'). It distinguishes from the sibling 'list_all_groups' by specifying 'limits'. The inclusion of the HTTP method and safety indicator reinforces the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'list_all_groups' or other list tools. There is no mention of prerequisites, use cases, or scenarios where this tool is appropriate.
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?
Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds value by explicitly stating 'Fetches data. Makes no changes' and confirms pagination. This reinforces the read-only nature and provides behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with three sentences, each adding distinct value: the HTTP method and icon, the core action, and the pagination/filtering aspect. It is front-loaded with the read-only indicator and method, making it efficient and well-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?
Despite having 10 parameters and no output schema, the description does not explain the response format, pagination details (like limit, offset), or sorting options. It only mentions 'paged list' and 'optional filtering'. For a tool with this complexity, the description is incomplete and leaves the agent without critical context.
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 10 parameters with 100% description coverage, so the schema itself documents each parameter thoroughly. The tool description only generically mentions 'optional filtering' without adding any new semantics or format details. Baseline 3 is appropriate since the description does not compensate 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 identifies the tool as retrieving all broadcast messages with a specific verb and resource ('Get all broadcast messages'). It is distinct from 'get_broadcast' which retrieves a single broadcast, but does not explicitly differentiate from siblings. The purpose is clear and well-stated.
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 only mentions 'optional filtering' but provides no guidance on when to use this tool over alternatives like 'get_broadcast' or 'list_broadcast_lists'. No when-to-use or when-not-to-use information is given, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate write operation (readOnlyHint=false) and non-idempotent (idempotentHint=false). Description reinforces the idempotency warning and specifies database insertion, adding some context. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is brief and front-loaded with the core action. Minor redundancy ('Local Events' appears both as title and in description). Overall well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should ideally mention return format or success indicators. It also lacks prerequisites or error scenarios. Adequate but not comprehensive for a write 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 100% with clear property descriptions. Description does not add any additional parameter semantics beyond what the schema provides. Baseline 3 is appropriate.
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 creates a new record (local event) via POST /localevent and inserts into production database. However, among many sibling create tools, no differentiation is provided, so it's not a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Includes a non-idempotency warning, which is useful. But no explicit guidance on when to use this tool vs alternatives (e.g., other create tools listed as siblings). Usage context is implied but not clarified.
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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the description's addition of 'Fetches data. Makes no changes' is redundant. It adds the HTTP method and a visual indicator (🟢 READ-ONLY), but no further behavioral details like pagination limits 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: three short lines with a clear hierarchy (icon, title, action statement). No fluff or 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?
Despite no output schema, the description fails to mention that results are paginated or support filtering/sorting via the provided parameters. For a tool that can return many lists, this omission leaves the agent without key usage details.
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 7 parameters with full descriptions (100% coverage). The tool description adds no additional meaning beyond the schema, so the baseline of 3 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 'Retrieve all lists' and includes a read-only indicator and HTTP method. It explicitly says 'Fetches data. Makes no changes to your ActiveCampaign account.' This precisely identifies the action and resource, distinguishing it from write operations and single-list retrievals.
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 'retrieve_a_list' or 'list_all_accounts'. The description only states it retrieves all lists, but without context on use cases, prerequisites, or comparisons to sibling 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?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint. The description reinforces these with 'Fetches data. Makes no changes.' but adds no additional behavioral traits beyond what annotations already declare. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (three lines) and front-loaded with key info. It could be slightly more concise by removing the emoji, but overall it's efficient with 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?
Given the simple tool (1 param, no output schema, no nested objects), the description is adequate but could be improved by mentioning the response format or common error cases. With annotations covering safety, it's minimally 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 100%, and the schema already documents the 'id' parameter. The description does not add any extra meaning or usage context for the parameter, so baseline 3 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 verb 'Retrieve' and resource 'message', and distinguishes from siblings like 'list_all_messages' by specifying a single message retrieval. The read-only emoji and endpoint further clarify.
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. There is no mention of when to use this tool versus alternatives like list_all_messages or other retrieve tools. The description lacks context for agent decision-making.
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?
Annotations already provide readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description reinforces 'Fetches data. Makes no changes' and adds the endpoint path, but does not disclose additional behavioral traits like rate limits or error handling. Since annotations cover key traits, the description adds minimal value.
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 front-loaded with the emoji and endpoint. However, it repeats 'Retrieve an association' (title and first sentence). Minor redundancy 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 tool is simple with one parameter, but there is no output schema and the description does not explain what data is returned (e.g., fields of the association). For a retrieval tool, knowing the response structure would help. Still, basic context is present.
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 100% for the single parameter 'id', which already has a description. The description does not add any additional meaning beyond what the schema provides, so baseline score of 3 applies.
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 explicitly states it is a read-only operation to retrieve an association, with the HTTP method (GET) and endpoint pattern. It clearly distinguishes from sibling tools that create, update, delete, or list associations.
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 given on when to use this tool versus alternatives like list_all_associations_1. There is no mention of prerequisites, use cases, or prohibitions.
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?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint, destructiveHint. Description adds 'Fetches data. Makes no changes.' which aligns with annotations but adds little beyond them.
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?
Concise and front-loaded with emoji and endpoint. Two clear sentences. Minor redundancy with name and annotations but 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?
Simple tool with one parameter and no output schema. Description is minimal but sufficient for a read-only retrieval. Could mention return type or segment 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?
Schema has 100% coverage for the single parameter 'id' with description 'ID of the segment to be retrieved'. Description does not add any further meaning.
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 'Retrieve a segment' and 'Fetches data. Makes no changes.' It uses a specific verb-resource pair and distinguishes from sibling retrieval tools like retrieve_a_tag.
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 alternatives. Among many retrieve siblings, there is no mention of prerequisites or context for choosing this 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?
The description repeats what annotations already state: read-only, idempotent, non-destructive. It adds the explicit 'Fetches data. Makes no changes' and the HTTP method/endpoint. However, it does not disclose additional behavioral traits such as pagination details, rate limits, or the structure of the response, which are not covered by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using front-loaded emoji, HTTP method, path, and a one-line explanation. Every sentence is necessary, and there is no redundancy or filler text.
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 5 parameters, nested objects, and no output schema, the description is insufficient. It does not explain what 'account contacts' are, how pagination works, or how filters and orders affect the results. The agent lacks context to anticipate the response format or behavior beyond the 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 description coverage is 100%, so the input schema already documents all 5 parameters with descriptions. The tool description adds no extra meaning beyond what the schema provides, meeting the baseline but not exceeding it.
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 'Retrieve', the resource 'a contacts account contacts', and provides the endpoint path. It distinguishes from sibling tools that retrieve other contact-related data (e.g., deals, notes) by explicitly naming 'account contacts'. The read-only indication and 'no changes' further clarify purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like retrieve_contact_deals or retrieve_contact_notes. There is no mention of prerequisites, context, or exclusion criteria, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds redundant but non-contradictory 'READ-ONLY' and 'Fetches data. Makes no changes.' It does not disclose additional behaviors like authorization requirements or response structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (3 lines), uses emoji and bold for visual clarity, and front-loads the action. Every segment adds value without 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?
Despite 5 parameters and no output schema, the description provides minimal context. It does not explain what geo-ips are, typical use cases, or pagination behavior. Schema documents parameters well, but the tool's purpose and output remain vague.
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 100%; all parameters are documented in the schema. The description adds no extra meaning or usage context for the parameters. Baseline score of 3 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 action: 'Retrieve a contacts list of geo-ips'. It includes the HTTP method, endpoint, and emphasizes that it is read-only. This distinguishes it from sibling tools that retrieve other contact data (e.g., notes, deals).
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. The description does not mention prerequisites, context, or when not to use it. With many sibling tools for contact data, more direction is needed.
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?
Annotations already set readOnlyHint, idempotentHint, and destructiveHint=false. The description reinforces that the tool is read-only and makes no changes. It also adds the HTTP method and endpoint path. No contradictions found. However, it does not disclose potential behavior like pagination limits or rate limits beyond what parameters suggest.
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 short sentences and a header line. It is front-loaded with an emoji and method hint. No redundant details. However, it could be slightly more informative without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters (including pagination and sorting) and no output schema, the description lacks explanation of what the response contains (e.g., an organization object). It does not address why pagination is needed for a single contact's organization or how filters apply. Thus, completeness is adequate but not thorough.
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 100%, so each parameter (id, limit, offset, orders, filters) is described in the schema. The description adds no additional meaning or context for these parameters, such as how to use sorting or filtering specifically for retrieving a contact's organization. Baseline 3 applies; no extra value provided.
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 'Retrieve a contacts organization' and 'Fetches data. Makes no changes.' The verb 'Retrieve' and resource 'contacts organization' are specific. However, it does not clarify what 'organization' means in the ActiveCampaign context (e.g., company details) nor distinguishes it from similar sibling tools like 'retrieve_contact_data'.
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 'get_contact', 'retrieve_contact_data', or other contact-related retrievals. There are no prerequisites, conditions, or exclusions 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?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds 'Fetches data. Makes no changes' but does not detail pagination behavior or other runtime 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?
Short and front-loaded with the key action. The emoji and 'READ-ONLY' are redundant but not harmful. Could be slightly more 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?
Given 5 parameters and no output schema, the description omits expected return structure. For a list tool, it's acceptable 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 description coverage is 100%, so the baseline is 3. The description adds no param-specific meaning; it only repeats 'List all custom fields'.
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 'List all custom fields', identifying a specific verb and resource. This distinguishes it from siblings like 'retrieve_a_custom_field_meta' which retrieve individual field metadata.
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 (e.g., retrieving a single field or field values). No mention of context 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds 'Makes no changes', which aligns but adds minimal new behavioral insight beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (three lines) and front-loaded with key information. The emoji and HTTP method are slightly extraneous but do not detract significantly. It earns its length.
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 (single parameter, no output schema) and annotations that cover safety, the description is adequate for an agent to understand its basic function. However, it could hint at the return format (e.g., 'Returns the segment object') for 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?
The input schema has 100% coverage with a description for segmentId, albeit minimal. The description does not add any additional meaning or context for the parameter beyond what the schema provides, so the baseline 3 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 action ('Retrieves'), the resource ('a Segment'), and its effect ('Fetches data. Makes no changes'). It uses a specific verb and resource, distinguishing it from list or update 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?
The description provides no guidance on when to use this tool versus alternatives like 'list_all_segments', 'get_segment_historic', or 'update_segment'. It does not mention context or exclusions.
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?
Annotations already declare idempotentHint=true and destructiveHint=false. The description adds value by explicitly stating 'WRITE · updates data', the HTTP method (PUT), and reinforcing idempotency. This provides context beyond annotations, though it could mention side effects like overwriting fields.
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 includes key details (operation type, HTTP method, idempotency). However, it mixes formatting with icons and line breaks, which may be noisy. Still, it is front-loaded and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic action but omits return value information (no output schema provided). For a write tool, agents might need to know what the response contains (e.g., updated note object). With 2 parameters and nested objects, more context on behavior and output 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?
Schema coverage is 100% (both parameters described in input schema). The description does not add any extra information about parameters, such as the meaning of 'reltype' or 'relid'. Baseline 3 is appropriate since schema handles the burden.
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 'Update a note' and 'Modifies an existing record in place,' specifying the verb (update) and resource (note). However, it does not differentiate from sibling tools like update_a_deal_note or update_a_account_note, which could lead to confusion if the agent needs to choose between them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Given sibling tools like update_a_deal_note and update_a_account_note, the description should clarify scope or context (e.g., 'for notes not associated with a specific entity'). Without this, an agent may misuse the 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?
The description adds 'idempotent' which aligns with the idempotentHint annotation. It also includes a visual indicator ('WRITE · updates data'). However, it does not disclose additional behavioral traits beyond what annotations already provide, such as authorization requirements 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentences and a metadata line. It is front-loaded with the action type, HTTP method, and resource path. Every piece of text 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's simplicity (update an existing record, no output schema), the description covers the core purpose and idempotency. It could mention the return value or error scenarios, but for a straightforward update, 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 100%, so the schema already documents both parameters (id and body with nested fields). The description does not add any further meaning or context beyond what the schema provides, so baseline 3 is appropriate.
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 'Update a saved response' and 'Modifies an existing record in place.' It identifies the verb (update) and resource (saved response). However, it does not explicitly distinguish from sibling update tools, though the resource type 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 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., create_a_saved_response or other update tools). There is no mention of prerequisites, exclusions, or context for 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 notes non-idempotency and potential duplicates, which adds value beyond the annotations that already indicate idempotentHint=false. However, it does not disclose other behaviors like error handling or constraints.
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 short lines: a summary line with emoji and HTTP method, a one-line purpose statement, and a sentence about idempotency. 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?
The description covers basic purpose and idempotency but does not mention response format, error states, or prerequisites. Given no output schema, some additional context would be helpful, though the nested object structure is already clear in the 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 100%, so the schema fully documents parameters. The description adds no additional semantic meaning beyond what is already in the input 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 explicitly states 'Bulk create a custom account field value' and includes the HTTP endpoint. The verb 'create' and resource 'custom account field value' are clear, distinguishing it from similar tools like 'bulk_create_a_custom_deal_field_value'.
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 'create_a_custom_field_value' for single creation or 'bulk_create_a_custom_deal_field_value' for deals. The description lacks context on selection 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?
The description confirms the write operation and idempotency, which are already indicated by annotations (idempotentHint=true, destructiveHint=false). It adds minimal behavioral context beyond what annotations provide, such as the HTTP method and the resource 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 very concise, using a single line with emoji, path, and verb, followed by two short sentences. No unnecessary words, and key 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?
While the schema provides parameter details and annotations cover safety, the description lacks clarity about the bulk nature (says 'Modifies an existing record' singularly) and does not explain the return value. Given the nested body structure, more context would be beneficial.
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 descriptions cover all parameters with details (id, fieldValue with currency note, fieldCurrency). The tool description does not add any additional parameter meaning, so it meets the baseline for high schema 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 the tool performs a bulk update of a custom field value, specifically for Deal Custom Field Data, with the HTTP method and path provided. It distinguishes itself from singular update tools among 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 explicit guidance on when to use this tool versus alternatives like 'update_a_custom_deal_field_value' or other bulk operations. The description does not mention prerequisites or scenarios.
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?
Annotations already indicate it's a write operation (readOnlyHint=false) and not idempotent (idempotentHint=false). The description adds the valuable warning: 'Not idempotent — calling twice may create duplicates.' This goes beyond annotations by explicitly stating the duplicate risk. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences plus a header. Front-loads the operation type and resource. No unnecessary words or repetition. Every element 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?
The tool has a nested object parameter with required fields, and no output schema. The description is minimal but combined with the schema and annotations it provides adequate context for a simple create operation. However, it lacks details about response format, error conditions, or any special behaviors beyond idempotency. Could be more 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 100%, so the input schema fully describes the parameter 'body' and its nested properties like fieldLabel, fieldType, etc. The description adds no additional meaning or context about the parameters; it merely restates the purpose. Baseline 3 is appropriate as the schema does the heavy lifting.
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 a custom field ("Create a custom field") and specifies "Account Custom Field Meta" in the header. This distinguishes it from sibling tools like create_custom_deal_field_meta and create_a_contact_custom_field, though not explicitly. The purpose is clear but could be more explicit about the account scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. Nothing about prerequisites, scenarios, or when not to use it. The description only states what it does, not when or why to choose it over siblings.
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 explicitly labels the tool as 'WRITE', mentions it sends or schedules outbound messages to real recipients, and warns about irreversibility. This adds behavioral context beyond the annotations (which only indicate readOnlyHint=false and destructiveHint=false). No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but somewhat repetitive (e.g., 'Create a new broadcast message' appears twice). The use of emoji and HTTP method is helpful but could be more streamlined.
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 main purpose and irreversibility but misses details about scheduling, segmentation, MMS, and return values. Given no output schema, it should hint at what the response contains.
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 100% with descriptive parameter names and some descriptions (e.g., 'SMS message content', 'Name of the broadcast'). The tool description does not add additional parameter semantics beyond what the schema provides, meeting the baseline.
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 a broadcast message for SMS/WhatsApp. It distinguishes itself as a broadcast tool, but does not explicitly differentiate from siblings like 'create_campaign' or 'create_a_new_message'.
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 warning about irreversibility ('Not reversible once delivered — confirm the audience first.'), providing some usage guidance. However, it does not specify when to use this tool over alternatives like 'create_aibroadcast' or mention prerequisites.
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?
Annotations already declare destructiveHint=true and readOnlyHint=false. The description adds the HTTP method (DELETE) and the explicit warning to confirm with the user, which enhances transparency. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively short but includes redundant phrases like 'Delete a stage' twice and 'Deletes an existing stage' similar to the first. The emoji and URL provide useful context but could be more streamlined.
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 simple tool (1 param, no output schema), the description covers the basic action. However, it lacks information on errors, side effects (e.g., what happens to associated deals), or prerequisites, which leaves some 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?
With 100% schema coverage, the input schema already documents the single parameter (id). The description does not add meaningful semantic context beyond the schema's 'Deal stage's id'.
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 'Delete a stage' and 'Deletes an existing stage', making the verb and resource clear. However, it does not differentiate from sibling tools like delete_a_deal or delete_a_pipeline, and contains slight redundancy.
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 advises 'Confirm with the user before calling', which provides some usage guidance. However, it lacks when-not-to-use contexts, such as whether the stage should be empty or if there are prerequisites, and no comparison to 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?
Annotations already indicate destructiveHint=true, so the description's repetition of '🔴 DESTRUCTIVE' adds little value. It includes a note to confirm, which adds some behavioral context beyond annotations, but otherwise does not disclose additional traits like irreversibility 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 concise, front-loading key info (destructiveness, HTTP method) and using emoji for quick scanning. Every sentence adds value, though the emoji could be considered extraneous.
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 destructive tool with one parameter and no output schema, the description adequately covers the purpose and cautions. It would benefit from mentioning the expected response or confirmation object, but overall 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?
Schema coverage is 100% with the parameter 'id' already described as 'ID of the group to be deleted'. The description does not add any semantic information beyond what the schema provides, so baseline score of 3 is appropriate.
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 'Delete a group' and 'Deletes a record', specifying the action and resource. However, it does not differentiate from other delete tools among many siblings, which would help an agent select the correct one.
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 guideline to 'Confirm with the user before calling', which is useful for safe usage. However, it does not provide when-not-to-use or alternative tools, limiting 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?
Explicitly declares destructive nature and requires confirmation. Annotations already indicate destructiveHint=true and idempotentHint=true. No contradiction. Adds value with confirmation advice.
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?
Short, front-loaded with destructive indicator. Two sentences plus emoji line. Could be slightly more concise but 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?
For a simple destructive tool with one parameter, description covers purpose, behavior, and user confirmation. No output schema, but return value is implied. Adequate given annotations.
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 covers the single required parameter 'id' with full description. Description does not add extra meaning beyond schema. Baseline 3 is appropriate.
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?
Clearly states it deletes an address group with verb 'delete' and resource 'AddressGroups'. Emoji and HTTP method add clarity. Does not differentiate from sibling delete tools but purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Only guideline is to confirm with user before calling. No context on when to use vs alternatives, 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?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the description's 'DESTRUCTIVE' and 'deletes data' are redundant but consistent. Adds 'Confirm with the user before calling' as a behavioral guideline not in annotations.
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 repetitive, stating 'Delete a secondary contact' three times. It includes a header with emoji and HTTP method, which adds some structure but is not 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?
For a simple deletion tool, the description covers purpose and a confirmation guideline. It lacks details on idempotency (though annotation says true), cascade effects, or response, but is minimally 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?
Schema coverage is 100%, so baseline is 3. The description does not add any additional context about the 'id' parameter beyond the schema's description of 'Secondary Contact's 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 explicitly states 'Delete a secondary contact' multiple times, clearly identifying the verb and resource. It distinguishes from sibling delete tools like delete_a_contact by specifying 'secondary contact'.
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 instruction to confirm with the user before calling, which is a usage guideline. However, it does not specify when to use this tool versus alternatives such as delete_a_contact for primary contacts or other delete 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?
Annotations already declare idempotentHint=true, destructiveHint=false, and readOnlyHint=false. Description adds 'Idempotent' and 'Modifies in place,' but these are redundant with annotations. No additional behavioral context like required permissions, side effects, or error states disclosed.
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 somewhat verbose with emoji, HTTP path, and repeated phrases like 'Edit a Variable' and 'Edit a personalization variable.' Could be streamlined to a single clear sentence.
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?
Tool has a nested object parameter and no output schema. Description does not explain the response behavior or error conditions. Schema covers parameters but the description lacks operational context.
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?
Both parameters have 100% schema description coverage, so the schema already explains them. Description adds no further parameter-specific meaning beyond the schema's field-level 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?
Description clearly states the tool edits/modifies a variable (personalization) with 'Edit a Variable' and 'Modifies an existing record in place.' The HTTP path and entity name 'Personalizations' make the resource explicit. Distinguishes from create_variable and delete_variable among siblings.
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?
Description implies use when updating an existing variable due to 'Modifies an existing record in place.' Lacks explicit guidance on when to use this tool vs alternatives like create_variable or other update tools. No 'when-not' or prerequisite conditions stated.
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?
Annotations already provide readOnlyHint=false, idempotentHint=true, destructiveHint=false. The description repeats idempotency and adds 'WRITE · updates data', which is consistent but adds little beyond what annotations indicate. It does not disclose potential side effects or authorization needs.
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 short but contains some redundancy (e.g., 'Enable/disable' appears twice). It could be more concise by removing the first line or combining sentences. However, it is not overly verbose.
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 boolean parameter, annotations present, no output schema), the description covers the basic purpose and idempotency. However, it lacks information about the response format or any associated side effects. Without an output schema, this gap may hinder the agent's understanding of the result.
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 100% with the 'enabled' parameter described as 'Whether site tracking should be enabled'. The description only says 'Enable/disable', which adds no additional meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Enable/disable' and the resource 'site tracking'. It also mentions 'PUT /siteTracking' which aligns with the HTTP method. This distinguishes it from read-only tools like retrieve_site_tracking_status and from event tracking variants.
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 mentions 'Modifies an existing record in place. Idempotent.' which gives some behavioral guidance but does not explicitly state when to use this tool versus alternatives (e.g., retrieve_site_tracking_status or enable_disable_event_tracking). No when-not or prerequisites are provided.
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?
Annotations already provide readOnlyHint=true and destructiveHint=false. The description adds context that it runs a POST that returns data, changes no account records, and may create a short-lived cached result-set, which provides useful behavioral disclosure beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise but includes an emoji and multiple sentences explaining the POST nature and output. It could be tighter without losing clarity, but it is structurally 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?
The description lacks output schema and does not explain the subfields of 'body' parameter sufficiently. It only states output is 'CSV including full contact records', leaving unclear what fields are included or how to handle errors. Completeness is minimal.
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 100% for parameter names/types but the description does not add meaningful explanation for the parameters. For example, it doesn't clarify what 'order', 'search', 'engagement', or 'deliverability' accept. The description adds no 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 'Export broadcast recipients' as a CSV, with the verb 'Export' and resource 'broadcast recipients'. It distinguishes from siblings like 'get_broadcast_recipients' by emphasizing CSV output and search/report behavior.
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 for exporting recipient data as CSV but does not explicitly specify when to use this tool over alternatives like 'get_broadcast_recipients' or 'export_broadcast_metrics'. No when-not or alternative guidance is provided.
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?
Description adds valuable behavioral context beyond annotations by noting that the tool may create a short-lived cached result-set. This helps an agent understand side effects. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences plus a header. Every element provides value: the emoji and labels give quick context, and the sentences explain behavior and side effects 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 the complex nested input schema and no output schema, the description is minimal. It does not explain what the result-set contains (e.g., contact IDs) or how to interpret the response. For a query tool, more detail on return format 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?
Schema coverage is 100%, so parameters are fully documented in the schema. The description does not add extra meaning about specific parameters; it only mentions the endpoint and request type. Baseline 3 is appropriate.
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 runs a search/report that returns data and does not modify records. It identifies the endpoint and read-only nature. However, the name 'find_contact_id_by_ac_playload' suggests a specific purpose (finding contact IDs), but the description does not mention contacts or IDs, creating slight ambiguity.
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 'create_match_all_request', 'create_match_one_request', or 'segment_match_check_by_external_id'. The description provides no context for choosing this tool over 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?
Annotations already provide readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds that it retrieves 'full details for one broadcast message,' which is consistent and provides additional scope. However, no new behavioral traits beyond what annotations cover.
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 mostly concise with a clear structure, including an emoji for read-only status, HTTP method, and endpoint path. It front-loads key information, though there is minor redundancy (mentions 'Get broadcast message' twice).
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 read-only tool with one parameter and no output schema, the description provides sufficient context: it states the action, the resource, and that it retrieves 'full details.' Annotations cover safety. No additional information is critically missing.
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 100% coverage with a single 'id' parameter described as 'Broadcast ID.' The description does not add any additional meaning or context to the parameter beyond what the schema already provides.
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 'Get broadcast message' and 'Fetches data. Makes no changes to your ActiveCampaign account.' It uses a specific verb and resource, and the read-only nature is emphasized. The title also says 'Get broadcast message,' which aligns well with the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives like list_broadcasts or get_broadcast_metrics. The description only indicates it is read-only but does not provide context for selection 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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description reinforces read-only by stating 'READ-ONLY' and 'Makes no changes', but adds no significant behavioral details beyond the HTTP method. It does not disclose pagination behavior, rate limits, or error conditions, which would be valuable. Since annotations cover safety, the description adds minimal value.
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 brief but contains redundancy: 'Get Contact's Tracking Logs/Events' appears twice, and 'Fetches data. Makes no changes to your ActiveCampaign account' is somewhat redundant with the read-only annotation. It could be more concise without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters including nested objects (orders, filters) and no output schema, yet the description does not explain the response format or how to use pagination/filtering effectively. While the tool is simple, additional context on results structure or iteration 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?
Schema description coverage is 100%, so the schema already describes parameters adequately. The description does not add any extra meaning or usage tips for parameters like limit, offset, orders, or filters. Baseline of 3 is appropriate as the description adds no additional 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 verb and resource: 'Get Contact's Tracking Logs/Events'. It directly says 'Fetches data' and 'Get a log of events for a Contact', making the purpose unambiguous. Among siblings, many are read operations on contacts, but this one is specific to tracking logs/events, distinguishing it adequately.
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 indicates it is read-only and makes no changes, but does not explicitly state when to use this tool versus alternatives like retrieve_contact_tracking_logs or retrieve_contact_logs. Usage context is implied through the resource name but lacks explicit when-to-use or 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds the HTTP method (GET) and states 'Makes no changes', which is consistent but adds minimal new behavioral insight beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using two sentences to convey purpose and safety. However, the title 'Get Custom Field Group by ID' is repeated, and the structure could be more streamlined without the duplicate.
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 read-by-ID operation with comprehensive annotations, the description covers the essential purpose and safety. It lacks mention of return format or error scenarios, but the absence of an output schema and the presence of rich annotations make this acceptable.
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 100%, so the baseline is 3. The description does not elaborate on parameters, adding no extra meaning beyond the schema's minimal descriptions ('Group ID', 'Request body (application/json).').
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 'Get' and the resource 'Custom Field Group by ID', making the operation unambiguous. It differentiates from sibling tools like 'get_all_custom_field_groups' by specifying retrieval by a single 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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that this is for retrieving a single group by ID, nor does it contrast with list or mutation tools for custom field groups.
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?
Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds valuable context about partial readiness (is_ready flag), error conditions (expired IDs return 404), and that sorting is unsupported. This goes beyond the annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and uses emoji and bold for clarity. However, it contains incomplete sentences (e.g., 'This endpoint can be used to…') and a stray backtick, reducing professionalism. It could be more concise by removing redundant phrases like 'Makes no changes to your ActiveCampaign account.'
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 key response attributes (is_ready, run_id_end) and error handling, but lacks details about pagination behavior (how page and page_size affect results) and the full response structure. Given no output schema, more completeness is expected for a data retrieval 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?
Input schema covers 100% of parameters with descriptions. The description adds the fact that segmentId and runId are path parameters and can expire, but does not provide additional meaning beyond the schema for page and page_size. Baseline 3 is appropriate given high 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 tool returns a 'Match Some result-set' and specifies it is read-only via emoji and text. It includes the HTTP method and endpoint path, which helps identify its function. However, it does not explicitly distinguish it from the sibling tool 'get_result_set_by_id', missing an opportunity for differentiation.
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 guidance on when to retry or alert support based on response attributes, and notes sorting is unsupported. However, it does not explain when to use this tool versus alternatives like get_result_set_by_id or other segment-related tools, leaving usage context implicit.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. Description reinforces 'READ-ONLY' and 'Makes no changes.' It adds minimal extra behavioral context (e.g., pagination hinted via parameters but not described). No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is short and front-loaded with key info. Uses visual marker (🟢) and clear categorization. Could be more structured (e.g., bullet points) but sufficiently 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?
Despite having 32 parameters and no output schema, the description does not explain pagination, response format, rate limits, or how to handle large result sets. Agent may need additional context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 32 parameters have descriptions in the schema (100% coverage). Description only provides examples of searching by email, list, account, adding marginal value beyond schema. Baseline 3 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?
Description clearly states 'List, search, and filter contacts' with specific verb and resource. The emoji and 'READ-ONLY' text immediately convey the action. Distinguishes from sibling tools by explicitly targeting contacts.
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?
Description gives examples of use cases (search by email, list, account) but does not specify when not to use or contrast with alternatives like get_contact or retrieve_contact_data. Implies usage for general listing and filtering.
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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds minimal context ('Fetches data. Makes no changes.') which is consistent but does not disclose additional behaviors like rate limits or result set size. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: three short lines with an emoji indicator, bold READ-ONLY label, and clear statement of operation. Every sentence adds value 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?
Despite good annotations and schema, the description does not explain what the response contains (e.g., each custom field value's structure) or warn about potential large datasets. It omits pagination details beyond schema, making it somewhat incomplete for a listing tool with nested parameters.
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 100%, so the schema already documents all 6 parameters with meanings. The description adds no extra parameter information, meeting the baseline of 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 'List all custom field values' and explicitly labels it as READ-ONLY with the HTTP method GET. It distinguishes from siblings like 'retrieve_a_custom_field_value' (singular) and 'list_all_custom_field_values_2' (variant) by its scope and naming.
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 'list_all_custom_field_values_2' or 'retrieve_a_custom_field_value'. The description lacks context for selecting it over siblings, such as pagination behavior or performance considerations.
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?
Annotations already provide readOnlyHint, idempotentHint, and openWorldHint. The description adds 'Fetches data. Makes no changes' which aligns but does not disclose additional behavioral traits like pagination limits, response structure, or error cases. It provides no new context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: three short lines plus the path. No wasted words. Front-loaded with read-only indicator and HTTP method. 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?
With six parameters (including nested objects) and no output schema, the description is too brief. It lacks information about what an email activity is, response structure, or pagination behavior. Adequate but could be more 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 description coverage is 100%, so the tool description does not need to add parameter details. It includes none, which is acceptable since the schema fully documents the six parameters. Baseline 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 'List all email activities' and reinforces with 'Fetches data. Makes no changes.' The name and HTTP path are included, making the purpose unambiguous. It distinguishes from siblings like list_all_deal_activities or list_contact_activities by specifying email activities.
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., list_contact_activities for contact-specific activities, or list_all_deal_activities for deal-related ones). The description does not mention exclusions, prerequisites, or comparison to siblings.
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?
Annotations already provide readOnlyHint, idempotentHint, destructiveHint. Description adds 'Fetches data. Makes no changes.' and 'names only', consistent with annotations. Adds endpoint info and scope, providing extra context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is short but slightly repetitive (mentions 'names only' twice). The header with emoji and endpoint is useful but not essential. Could be more concise without losing 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 no output schema, description does not explain return format (e.g., array of objects with name). It confirms list of names but lacks detail on pagination behavior or result structure, leaving gaps 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 100%, so parameters are fully documented. The description adds no additional semantic meaning for parameters; baseline 3 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?
Description clearly states it lists all events (names only) via GET /eventTrackingEvents. It uses specific verb 'List' and resource 'events', with scope 'names only', distinguishing it from create/remove event 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 vs alternatives like create_a_new_event_name_only or retrieve_event_tracking_status. No when-not-to-use or context for choosing over sibling 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds 'Fetches data. Makes no changes' which is consistent but adds minimal value beyond annotations. No additional behavioral traits like rate limits or auth requirements are disclosed. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using three short lines. The first line includes a read-only indicator and HTTP method, which is front-loaded. Every sentence adds value: purpose, read-only nature, and HTTP path. No extraneous 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?
Given there is no output schema, the description does not hint at the return structure or fields. The tool has complex parameters (orders, filters) but the description ignores them. For a simple retrieval, the context is adequate but could be improved by mentioning the response 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?
Schema coverage is 100%, so description carries no burden to explain parameters. The description does not add any meaning beyond what the schema property descriptions already provide, such as details on pagination or filtering. Baseline score of 3 is appropriate.
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 retrieves a contact's geo IP address using a specific HTTP GET endpoint. The verb 'Retrieve' and resource 'contacts geo IP address' are explicit. However, it does not differentiate from the sibling tool 'retrieve_contact_geo_ips' (plural), which likely lists all geo IPs, while this one retrieves a single one by ID.
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 'Fetches data. Makes no changes' which implies this is a read-only operation. However, it does not provide when to use this tool versus alternatives like 'retrieve_contact_geo_ips' or other retrieval tools. No explicit context for 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?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint. The description adds 'Fetches data. Makes no changes to your ActiveCampaign account.', reinforcing the read-only behavior consistently.
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?
Contains some redundancy (e.g., 'Retrieve a pipeline' appears twice). The first line with method and endpoint is useful but overall could be more 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?
For a simple tool with one parameter and no output schema, the description is adequate but lacks return value hints. Could be improved by mentioning what data is returned.
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 100% with the parameter 'id' described as 'Pipeline's id'. The description does not add any additional meaning or 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?
Clearly states the verb 'retrieve' and resource 'pipeline'. The description mentions 'Fetches data' and 'Makes no changes', distinguishing it from create/update/delete 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 explicit guidance on when to use this tool versus alternatives like list_all_pipelines or other retrieval tools. The description lacks context on when to prefer this over similar 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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds the HTTP method, path, and explicit 'Fetches data. Makes no changes.' No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four lines with emoji, path, and two sentences. Every piece adds value: the emoji indicates safety, path gives REST context, and sentences confirm read-only nature. 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?
No output schema exists, and the description does not explain the structure of tracking logs or pagination behavior. While the schema covers limit/offset, the default limit and response format are unclear. Adequate but not rich.
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 100% with adequate descriptions for all 5 parameters. The description does not add further parameter information, so baseline 3 is appropriate.
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 'Retrieve a contacts tracking logs' with verb and resource, and the read-only emoji and path add clarity. However, it does not distinguish from sibling tools like 'get_contacts_tracking_logsevents' 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 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. The description does not mention any prerequisites or exclusions, leaving the agent without context for appropriate usage.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description reinforces 'Fetches data. Makes no changes' and adds that it gets enabled/disabled status. However, it does not elaborate on response format or additional behavior beyond what annotations cover.
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 redundant, repeating 'Retrieve Event Tracking Status' and 'Get event tracking status'. The emoji and endpoint info add minor value. Could be more concise without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides basic info for a simple status retrieval, but lacks output format details (no output schema). It suffices for the tool's simplicity, but an agent might need to infer the exact structure of the status response.
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 100%, so baseline 3. The description adds no additional meaning to parameters like limit, offset, orders, or filters. It does not explain how pagination or sorting applies to status retrieval.
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 retrieves event tracking status using the verb 'Retrieve' and specific resource 'Event Tracking Status'. It distinguishes from sibling mutation tools like 'enable_disable_event_tracking' by emphasizing read-only nature, and from 'retrieve_site_tracking_status' by focusing on event tracking.
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 for reading status but lacks explicit guidance on when to use this tool versus alternatives like 'enable_disable_event_tracking' or 'retrieve_site_tracking_status'. No when-not or exclusion statements are provided.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description reiterates 'Makes no changes' and provides the HTTP method (GET), which aligns but adds minimal new behavioral insight beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear emoji prefix, endpoint, and two explanatory sentences. It is well-structured for quick scanning, though slightly redundant in repeating 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 6 parameters including nested objects and no output schema, the description does not explain return format, pagination behavior, or required parameter relationships. This leaves the agent with incomplete information for correct usage.
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 100% and each parameter has a clear description in the schema. The tool description adds no additional meaning or usage context for the parameters, so baseline 3 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 uses specific verb 'Retrieve' and resource 'inaccessible pipelines', clearly distinguishing it as a specialized read operation for pipelines a user lacks access to. It also provides the endpoint path and category ('Deal Groups').
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 states the tool is read-only and fetches data, but does not explicitly guide when to use this tool over other pipeline-related tools in the sibling list. Some context is implied via the unique resource, but no exclusions or alternatives are provided.
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 adds 'Modifies an existing record in place' beyond the annotations (which already provide idempotentHint=true and destructiveHint=false). However, it does not disclose additional behavioral traits such as error conditions, rate limits, or effect on related data. The added value over annotations 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a header line and two brief sentences, but it contains redundancy: 'Update a task type' and 'Update an existing task type'. The content could be condensed into a single clear sentence.
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 a nested input schema and no output schema. The description covers the basic purpose and idempotency but does not explain return values, side effects on other entities, or error responses. Given the moderate complexity, additional context 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?
The input schema has 100% description coverage, so each parameter already has a description. The tool description does not add any additional meaning or context about the parameters beyond what the schema provides. For example, it does not explain the uniqueness constraint on title, even though the schema does.
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 explicitly states 'Update a task type' and 'updates data', which clearly identifies the verb and resource. The tool name, title, and description are consistent with the action. Among siblings like create_a_deal_task_type and delete_a_deal_task_type, this tool is distinctly for updating.
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 mentions 'Modifies an existing record in place' and 'Idempotent', but does not provide explicit guidance on when to use this tool versus alternatives like creating or deleting task types. There is no mention of prerequisites or caveats.
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?
Annotations already indicate idempotentHint=true and destructiveHint=false. The description adds 'Idempotent' and 'Modifies an existing record in place,' which aligns with annotations. However, no additional behavioral context like authorization needs, error handling, or side effects is disclosed.
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 a summary line. However, 'Update a customer' appears twice, which is slightly redundant. Overall, it is efficient with minimal 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?
For a simple update tool with good annotations and high schema coverage, the description covers the essential behavior. No output schema exists, but the return value is likely the updated customer. The description is adequately 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 100% with descriptions for all parameters (id and body nested fields). The description does not add any extra meaning beyond what the schema provides. Baseline 3 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 'Update a customer' and 'Update an existing e-commerce customer resource.' The verb 'update' and the resource 'customer' are specific. The HTTP method PUT and path are provided. Among siblings, there is a separate 'create_customer', so the purpose is distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, conditions, or when not to use. With many sibling tools, this lack of guidance could confuse an AI agent.
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 write operation, reversible, and linking records, consistent with annotations (readOnlyHint=false, destructiveHint=false). Adds HTTP method but no additional behavioral details beyond annotation hints. Schema includes a warning about re-subscription, which is not in description.
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 includes some noise (emoji, URL path) and could be more streamlined. It is functional but not 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?
Covers the main action adequately given the tool's simplicity (one nested parameter, no output schema). However, lacks mention of return values or behavior in edge cases.
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 100% with detailed parameter descriptions. Description adds minimal value beyond summarizing subscribe/unsubscribe actions. Baseline 3 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?
Description clearly states 'Update list status for a contact' and elaborates with specific actions: subscribe/unsubscribe. It distinguishes from sibling tools like create_new_list or create_contact_tag by focusing on modifying membership status.
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 usage instructions: subscribe or unsubscribe a contact. Mentions reversibility. However, lacks explicit when-not-to-use or alternatives among the many sibling 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?
Annotations already provide idempotentHint and destructiveHint. The description adds 'in place' and repeats idempotency, adding marginal value. No contradictions. Without annotations, would be lower, but here baseline is 3.
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: a header line and two sentences. No redundancy, though the endpoint details could be omitted. Efficient for the core 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 complex input schema with nested objects and no output schema, the description is too sparse. It does not guide on required fields or behavior beyond a basic update. More context is needed for a complex mutation 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 100%, so baseline is 3. The description does not add any parameter details beyond what the schema provides.
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 'Update a Segment' and 'Modifies an existing record in place', using a specific verb and resource. It distinguishes from siblings like create_segment and delete_segment by implication.
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 explicitly state when to use or when not to use this tool. No alternatives are mentioned. Usage is implied by the name and action, but no explicit guidance is provided.
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 adds behavioral insight beyond annotations by warning 'Not idempotent — calling twice may create duplicates.' This complements the idempotentHint=false annotation. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with key information front-loaded. Each sentence adds value: method, purpose, and idempotency warning. 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?
No output schema exists, and the description does not hint at the return value (e.g., created schema details). For a create operation, this leaves agents guessing about the response 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?
Schema coverage is 100%, so the description does not need to add parameter details. It does not add extra meaning beyond what the schema provides. Baseline score of 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 explicitly states 'Create a child schema' with the HTTP method and endpoint. It clearly defines the action on a specific resource, distinguishing it from many other create 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 on when to use this tool vs alternatives. It does not mention prerequisites or context for choosing this over other create 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?
The description explicitly states 'Not idempotent — calling twice may create duplicates', which adds practical behavioral context beyond the idempotentHint=false annotation. The 'WRITE' badge also clarifies mutability. However, it does not discuss permissions or side effects beyond duplication.
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 with two short sentences plus a header line. It front-loads the key information (WRITE, create, not idempotent) and avoids unnecessary words, though it could benefit from structured sections for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple create operation but lacks information about response format or return value. Given no output schema, the agent may need to know what is returned (e.g., ID of created group). The nested 'body' object is noted but not explained further.
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 100% schema description coverage, the input schema already documents all parameters. The description adds no additional parameter details beyond the HTTP method and resource path, so it provides no added semantic value beyond the schema baseline.
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 a custom field group, with a '🟡 WRITE' badge, 'creates data' label, and explicit 'Create a Custom Field Group' heading. It distinguishes from sibling tools like 'create_a_customfieldmeta' by specifying the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, typical scenarios, or when not to use it, leaving the agent to infer from the name only.
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 adds value beyond annotations by stating it is a write operation ('creates data') and explicitly noting non-idempotency with potential duplicate creation. This complements the annotations (readOnlyHint=false, idempotentHint=false) without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loading an indicator emoji and a brief statement. It uses only two sentences with minimal waste, though slightly more structure could improve 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?
For a tool with a nested JSON body and no output schema, the description is somewhat minimal. It does not describe the response or success behavior, leaving some gaps. However, the schema covers parameters well.
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 100% coverage of parameter descriptions, so the description does not need to add parameter-level detail. It adds no extra meaning beyond the schema, earning a baseline score of 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 verb 'Create' and the resource 'custom field value'. It also includes a write indicator and specifies that it creates a new record. The tool name and description make it distinct from sibling tools like bulk_create versions.
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 explicit guidance on when to use this tool versus alternatives. It only mentions non-idempotency but does not specify prerequisites, context, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare non-idempotent (idempotentHint: false) and readOnlyHint: false. The description adds 'Not idempotent — calling twice may create duplicates,' which aligns with annotations but does not provide new behavioral insights beyond what is already structured. With annotations, the description adds minimal extra value.
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-loaded with a symbolic summary, endpoint, and clear purpose. Every sentence contributes: it states the action, the resource, the HTTP method, and a key behavioral note. No wasted 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 simplicity of the tool (one parameter, no output schema), the description is nearly complete. It covers the non-idempotent behavior, which is critical. It does not explain what a deal role is, but that is domain knowledge. With annotations providing safety traits, the description 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?
The input schema has 100% description coverage for its single parameter (body with title described as 'Title for the new deal role'). The description does not add additional meaning or constraints beyond the schema, so baseline score of 3 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 creates a deal role, with the action 'Create a deal role' and the resource 'Deal Roles'. It also includes the HTTP method and endpoint, making the purpose precise. The tool name itself is unambiguous, distinguishing it from siblings like 'create_a_deal_new' which creates a deal.
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 over alternatives. While it mentions non-idempotency, it does not specify prerequisites, filters, or context. Among many sibling create tools, there is no differentiation provided.
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 adds behavioral context beyond annotations by explicitly stating the tool is not idempotent and may create duplicates, which aligns with the idempotentHint=false annotation. Annotations already indicate readOnlyHint=false and destructiveHint=false, so the description provides useful warning about repeated calls.
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 relatively short and front-loaded with important context (WRITE, Custom Objects, endpoint). However, it redundantly states 'Create or update record' and 'Creates a new record' in close proximity, which could be tightened.
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 basic purpose and idempotency, but lacks explanation of upsert behavior (given the name implies update), how to use the 'id' field, or any examples. With no output schema and a nested object parameter, more detail would be beneficial for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters having descriptions in the schema. The tool description does not add any additional parameter-level guidance or examples, so it meets the baseline but does not exceed 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 ('Creates a new record') and the resource ('record' for Custom Objects), including the HTTP method and endpoint. However, the name 'create_or_update' implies both operations, but the description only mentions creation, creating a minor contradiction that could confuse an agent.
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 mentions 'Custom Objects' which helps differentiate from sibling tools for other entities, but it does not explicitly state when to use this tool versus alternatives like 'create_a_new_contact'. No when-not or conditional guidance is provided.
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?
Annotations already declare destructiveHint: true. Description adds a confirmation requirement and visual destructive indicator. Does not contradict annotations. Additional context about user confirmation is valuable.
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 repeats 'Delete a task type' and includes redundant lines. Could be more concise. First line is a mixed header. Not severely wordy but could be improved.
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?
Description lacks context about consequences, such as cascading deletion or need to reassign tasks of this type. Given the destructive nature and presence of sibling 'move_deal_tasks_to_another_deal_task_type', this is a notable omission.
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?
Single parameter 'id' has full schema coverage. Description adds no extra meaning beyond schema's 'Deal task type's id'. Baseline 3 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?
Description clearly states it deletes a deal task type, using specific verb and resource. Repetition doesn't harm clarity. Distinguishes from sibling create/update and other delete 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?
Provides a guideline to confirm with user before calling, but no explicit when-to-use/alternatives. Usage is implied as 'when you want to delete a task type', but no exclusion or comparison with other tools like moving tasks.
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 includes a destructive warning and the HTTP method, adding value beyond the annotations which already mark destructiveHint=true. It also explicitly requires user confirmation.
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 redundant with repeated phrases like 'Delete a note' and 'Deletes a record.' The banner-style first line could be integrated more concisely.
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 single-parameter destructive tool, the coverage is adequate: it states the purpose, the HTTP method, and the need for user confirmation. It could mention idempotency but that is already in annotations.
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?
All parameters (id only) are fully documented in the input schema. The description adds no extra information about the parameter beyond what the schema provides.
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 explicitly states it deletes a note. However, with sibling tools like 'delete_a_note' also present, it does not differentiate itself beyond the entity type 'note'.
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?
It advises confirming with the user before calling, but lacks guidance on when not to use or alternatives (e.g., other delete tools or soft-delete options).
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?
Annotations already mark destructiveHint=true and readOnlyHint=false. The description adds the behavioral note 'Confirm with the user before calling' and includes a 'DESTRUCTIVE' prefix, providing practical guidance on required user confirmation beyond what annotations convey. It does not mention other side effects, but for a simple delete this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is redundant, stating 'Delete a user' twice and including an extra line 'Delete an existing user'. The prefix with emoji and method info is extraneous. It could be condensed into a single clear sentence. The redundancy wastes space without adding clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple destructive tool with one parameter and annotations present, the description covers the basic action and a safety requirement. However, it lacks information about return values, authorization requirements, or potential errors, which would improve completeness. The output schema is absent, so the description could provide more context.
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 already describes the only parameter 'id' as 'ID of the user you wish to delete' with 100% coverage. The description does not add any additional parameter context or formatting details, so it meets the baseline without adding extra 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 'Delete a user' and 'Delete an existing user', using a specific verb and resource. It unambiguously identifies the action, distinguishing it from other delete tools by resource name, even without explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes the important guideline 'Confirm with the user before calling', but does not specify when to use this tool versus other delete tools (e.g., delete_contact, delete_account). The context of use is implied by the resource type, but no explicit alternatives or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds 'Fetches data. Makes no changes.' which confirms these but does not add new behavioral details. With rich annotations, the description adds minimal extra transparency. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: three compact lines with an emoji, title, HTTP method, and a one-sentence summary. It is front-loaded with key identifiers and contains zero wasted text. Perfect for a simple list tool.
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 tool is a read-only list with well-annotated behavior, comprehensive schema, and no output schema to document. The description covers the core purpose and safety. It does not mention pagination or response format, but the schema handles pagination parameters, and the return value is implicit for a list. Adequate for the complexity.
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 100% description coverage, so the schema already documents all parameters (limit, offset, orders, filters). The description does not mention any parameters, and no additional meaning is provided beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all forms' and includes 'Fetches data. Makes no changes.' The verb 'list' and resource 'forms' are specific, and the read-only hint reinforces the purpose. However, it does not explicitly distinguish from sibling tools like list_all_accounts or list_all_contacts, but the form-specific focus 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (list forms) and that it is read-only, but it provides no guidance on when not to use or alternatives. Given the straightforward nature of the tool, the implied usage is adequate but lacks explicit exclusions or context with siblings.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds useful context: it may create a short-lived cached result-set. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is relatively concise and front-loaded with the main purpose. However, the header line ('🟢 READ-ONLY · query · Sms · POST...') is redundant with annotations and takes space.
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, the description only broadly states it 'Returns metrics'. It does not specify the format, whether results are paginated, or behavior for missing IDs. Completeness is adequate but not thorough.
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?
Input schema provides full descriptions for all three parameters (body, start_date, end_date), so the description adds no additional parameter details. Baseline of 3 is appropriate.
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 broadcast metrics via a POST request. However, it presents conflicting scope: 'Get all broadcast metrics' vs. 'for specified broadcast IDs', causing minor ambiguity.
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?
Notes that it is a read-only operation (POST that returns data) and does not change records. No explicit guidance on when to use this over siblings like get_broadcast, export_broadcast_metrics, or get_broadcast_snapshot.
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?
Annotations already provide readOnlyHint=true and destructiveHint=false. The description adds 'Fetches data. Makes no changes' which is redundant. The HTTP method and path pattern are useful but do not disclose additional behavioral traits like rate limits 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 somewhat repetitive ('Retrieve a connection' appears twice) and includes decorative emoji. Could be streamlined into fewer sentences without losing 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?
For a simple single-parameter retrieval tool with comprehensive annotations and no output schema, the description provides sufficient context. It lacks details on return format but is otherwise 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?
Schema coverage is 100% with a single parameter 'id' described as 'The id of the connection to retrieve'. The description adds no extra meaning beyond the schema, meeting the baseline for high 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 'Retrieve a connection' and emphasizes it is read-only. It distinguishes from sibling tools like list_all_connections and create_connection by focusing on a single resource 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 for retrieving a specific connection by ID but does not explicitly state when to use this over list_all_connections or other tools. No guidance on prerequisites 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?
Annotations already declare readOnlyHint=true and idempotentHint=true, and the description confirms 'Fetches data. Makes no changes'. However, it adds no further behavioral details (e.g., pagination, rate limits, or response format) beyond what annotations and schema provide.
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 relatively concise, starting with key markers ('READ-ONLY', endpoint) and stating the purpose. However, it repeats 'Get Contact By Event ID' and includes line breaks that could be streamlined. Each sentence adds value, but slight 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 the tool has 5 parameters (including nested objects) and no output schema, the description is minimally adequate. It explains the core function but omits details about return structure or pagination behavior. The annotations cover safety, but the description does not fully inform an agent about expected results.
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 100%, so baseline is 3. The description mentions only 'eventId' implicitly via the tool name, but does not elaborate on optional parameters (limit, offset, orders, filters) or their 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 the verb ('Get') and the resource ('contact by event ID'), specifying the input (event ID) and the output (contact involved in an event). It distinguishes from sibling tools like 'get_contact' by focusing on event association.
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 you have an event ID and need the associated contact, but it does not explicitly mention when not to use it or compare to alternatives like 'get_contact' or 'retrieve_contact_data'. No explicit usage boundaries are provided.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds behavioral context beyond annotations by explaining the read-only nature ('Makes no changes') and pagination behavior (50 result limit, epoch-based pagination). This adds value, though it does not cover all edge cases like rate limits 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with 3 sentences and a header line. It front-loads key information (read-only, endpoint). However, the header repeats information from the first sentence, and the structure could be improved for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain the return format. It mentions 'result counts' and pagination but does not describe the response structure (e.g., fields, data types). Given the complexity (5 params, nested objects), the description is incomplete, though the pagination guidance is 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?
Input schema coverage is 100%, so each parameter is documented with descriptions. The description does not add new meaning beyond the schema; it only references 'segmentId' implicitly. The pagination info mentions a response field (timestamp) not a parameter, so parameter semantics remain at baseline.
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 retrieves result counts for a specific segment without additional criteria, using the verb 'Retrieve' and specifying the resource. However, it does not differentiate from sibling tools like get_count_history_with_timestamp or get_recent_count_history, which limits clarity for distinguishing between similar 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 guidance (read-only, no changes) and pagination details (up to 50 results, next page with epoch timestamp). However, it lacks explicit when-to-use vs alternatives, and does not mention exclusions or prerequisites for using this tool over others.
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?
Annotations already state readOnlyHint, idempotentHint, destructiveHint. The description reinforces these with 'Fetches data. Makes no changes' and adds the HTTP method and route. No contradictions. Adds useful context that it's for 'Deal Tasks'.
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 mostly clear but contains redundancy: 'Retrieve a task' appears twice, and 'Fetches data. Makes no changes' is already implied by annotations. Could be trimmed without losing meaning.
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 read tool with one parameter and no output schema, the description covers the essential context (task retrieval, read-only, endpoint). It omits what the response looks like, but that's acceptable given no 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 100% with a single parameter 'id' described as 'The ID of the task'. The description adds no additional parameter info beyond the schema, so baseline 3 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 retrieves a task, is read-only, and uses GET. The verb 'Retrieve' and resource 'task' are explicit. The sibling tools include create_task, delete_task, update_task, and list_all_tasks, so this tool's purpose is distinct.
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 does not specify when to use this tool over alternatives like list_all_tasks or other retrieval tools. There is no guidance on prerequisites, context, or exclusions. The only hint is the parameter 'id', implying you need a specific task ID.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description redundantly states 'Fetches data. Makes no changes to your ActiveCampaign account' but adds no new behavioral insights beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is repetitive with 'Retrieve a user by email' appearing twice. While front-loaded with a label and endpoint, the redundancy makes it less concise than ideal.
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 read-only tool with one parameter, the description covers the essential purpose and safety. It lacks mention of the response structure, but given no output schema and the low complexity, the context is 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?
Schema description covers 100% of parameters with 'Email address of the user you want to view'. The description adds no additional semantics beyond confirming the email lookup, which is already in the 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 retrieves a user by email. The verb 'retrieve' and resource 'user by email' are specific. Among sibling tools like get_user and get_user_loggedin, it is distinct by focusing on email lookup.
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?
No explicit guidance on when to use this versus alternative user retrieval tools (e.g., get_user by ID). The name implies email usage, but the description does not outline when not to use or mention alternatives, leaving room for ambiguity.
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?
Provides the HTTP method and path (GET /webhooks/{id}) and states 'Makes no changes', aligning with readOnlyHint=true annotation. Adds endpoint context beyond annotations, though no rate limits or side effects are described.
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?
Contains repetition ('Retrieve a webhook' appears twice) and is not fully concise, but remains short overall. The emoji and path line adds some structure but could be streamlined.
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 read-only retrieval tool with no output schema, the description is minimal. It does not explain return values or fields, leaving the agent without expected output structure. Adequate for simple usage 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 coverage is 0% and the description does not explain the 'id' parameter beyond implying its necessity. Lacks format, source, or constraints, failing to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Retrieve a webhook' and 'Fetches data', specifying the verb (retrieve) and resource (webhook). Distinguishes from siblings like create_webhook, delete_webhook, update_webhook, and get_a_list_of_webhooks by focusing on retrieving a single webhook by ID.
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 usage for retrieving an existing webhook via ID, but lacks explicit when-to-use or when-not-to-use guidance. Does not mention alternatives like get_a_list_of_webhooks for listing.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false. Description adds 'Fetches data. Makes no changes,' which is consistent but does not disclose pagination behavior or response format beyond what schema provides.
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 three lines, including a visual indicator and HTTP method. It is front-loaded and efficient, though could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks details on pagination behavior, response structure (no output schema), and filtering usage beyond schema. For a tool with 7 parameters and nested objects, more guidance 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 100%, so parameters are well-described in the schema. The description adds no extra meaning to parameters, meeting the baseline for high 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?
Description clearly states 'List all campaigns' and 'Fetches data. Makes no changes.' It specifies the HTTP method and resource path, which distinguishes it from mutation tools like create_campaign or edit_campaign.
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?
Description implies read-only listing but does not explicitly state when to use this versus other campaign tools (e.g., retrieve_a_campaign for a single campaign) or when not to use it. No alternatives 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description adds that it is read-only and makes no changes, which is consistent but adds no extra behavioral detail beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat repetitive (e.g., 'List all deal activities' appears twice) and could be more streamlined. It is functional but not optimally 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?
Despite good annotations and schema, the description fails to explain the return structure or pagination behavior. With 8 parameters and no output schema, the description should provide more context on what the tool returns.
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 100% (8 parameters all with descriptions). The description adds no parameter-level context; it does not mention any parameters or how to use them. Baseline 3 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 'List all deal activities' and explicitly mentions the GET endpoint and read-only nature. It distinguishes from a specific alternative endpoint for a single deal's activities, clarifying scope.
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 that this tool lists all deal activities and mentions a specific alternative endpoint for filtering by deal ID. However, it does not explicitly state when to use this tool versus other sibling tools like list_all_deals or retrieve_a_deal.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description reinforces the read-only nature and mentions HTTP method, but does not disclose additional behaviors like pagination limits or rate limiting.
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 emoji and endpoint info, but contains redundancy—'List all task outcomes' is stated twice. Otherwise, it is 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 tool with five optional parameters and no output schema, the description is minimally adequate but lacks details on pagination behavior or expected response format, leaving some 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 100% with descriptions for all five parameters. The description adds no parameter-specific details beyond the schema, so it meets baseline but does not enhance understanding.
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 explicitly states it lists all task outcomes, with a clear verb 'List' and resource 'task outcomes'. It distinguishes from sibling tools like list_all_tasks or retrieve_a_task_outcome by specifying the exact resource.
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 context (read-only, GET endpoint) but does not advise when to use this tool versus alternatives like retrieve_a_task_outcome or other list tools. No explicit when-not 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Reinforces read-only nature beyond annotations (e.g., 'Fetches data. Makes no changes') and specifies HTTP method. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise with a clear header, but could be better structured. Every sentence adds value, though the search example is somewhat redundant with schema.
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?
Lacks explicit mention of pagination or response format, but given high schema coverage and no output schema, the description is adequate for a simple list 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 high (93%), so minimal extra parameter description needed. The description adds context for the search parameter but does not significantly enhance schema details.
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 lists WhatsApp templates and is read-only. It distinguishes from the single template retrieval tool (get_whatsapp_template) but not from other list 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?
Provides some guidance on searching by name and status, but does not explicitly state when to use this tool versus alternatives like get_whatsapp_template or other channel list 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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. Description adds 'Fetches data. Makes no changes,' which aligns with annotations but does not provide additional behavioral context such as permissions 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loading key details (read-only indicator, endpoint, purpose). No wasted sentences, but the parameter description inconsistency in the schema slightly detracts.
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 read operation with one parameter and no output schema, the description is mostly complete. However, it lacks any description of the return value structure, which would help an agent understand what is retrieved.
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 100% with a description for the 'id' parameter. The tool description does not add new semantics beyond the schema; it merely restates the purpose. Note: schema parameter description says 'dealCustomFieldData', which may be inconsistent with the tool's account focus.
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 retrieves a custom field value for an account, with a specific verb and resource. It distinguishes from sibling 'retrieve_a_custom_deal_field_value' by specifying 'Account Custom Field Data'.
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 for reading account custom field data but lacks explicit guidance on when to use versus alternatives like 'retrieve_a_custom_deal_field_value'. No when-not-to-use criteria provided.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds a 'Fetches data. Makes no changes' statement which aligns but is redundant. No additional behavioral traits (e.g., rate limits, permissions) are disclosed. With annotations fully covering the behavioral profile, the description adds limited value.
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 front-loaded with the HTTP method and endpoint, but it repeats 'Retrieve a deal' twice and includes a line about fetching data that is redundant with annotations. It is not overly long but 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?
For a simple retrieval tool with one parameter and rich annotations, the description is sufficient. It explains the operation, readonly nature, and endpoint. No output schema exists, but the agent can infer the return structure from the tool name and typical deal objects. It is complete enough for an AI agent to use correctly.
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 100%: the single 'id' parameter has a description. The tool description does not add any extra meaning beyond the schema, such as constraints or format hints. Given the simplicity of the parameter, this is 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 'Retrieve a deal' and specifies it fetches data without making changes. The verb 'Retrieve' and resource 'deal' are specific, and among siblings like 'list_all_deals', this tool's purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives. However, the name and description imply it is for retrieving a single deal, and siblings like 'list_all_deals' suggest alternative use cases. This is adequate for a simple retrieval tool.
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?
Annotations already include readOnlyHint and idempotentHint. The description adds plain-language confirmation ('Fetches data. Makes no changes') and the HTTP method, providing additional clarity beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with an emoji and URL, but contains redundancy: 'Retrieve a task type' appears twice. Could be more concise without losing meaning.
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 read-only tool with one parameter and no output schema, the description provides adequate context: HTTP endpoint, safety, and operation. Missing a brief note on the return type, but acceptable.
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 100% with a clear description of the 'id' parameter. The description does not add any extra semantic info beyond the schema, so baseline 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 'Retrieve a task type' with 'READ-ONLY' and 'Fetches data' and 'Makes no changes', making the purpose unambiguous. It distinguishes from sibling tools like list, create, update, 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?
The description provides no guidance on when to use this tool versus alternatives such as list_all_deal_task_types or update_a_deal_task_type. It lacks any context about prerequisites or use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds 'Fetches data. Makes no changes.' which reinforces the annotations but adds minimal new behavioral context beyond what is already structured.
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 with only three lines, front-loading the key information (read-only, endpoint, purpose). 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's simplicity (1 required param, no output schema, comprehensive annotations), the description provides sufficient context. It covers the purpose and safety profile, though it does not detail return format or error cases, which are less critical here.
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 only parameter 'id' is fully described in the schema as 'ID of the Address to retrieve' (100% coverage). The description does not add any extra meaning beyond the schema, so baseline score of 3 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 it's a read-only operation to retrieve a single address by ID, with the HTTP method and path provided. It distinguishes itself from siblings such as list_all_addresses and create_an_address.
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 use for fetching a specific address by ID but does not explicitly state when to use this tool over other retrieval tools like list_all_addresses or search alternatives. No when-not or alternative guidance is provided.
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?
Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds 'GET /contactDeals/{id}' and 'Fetches data. Makes no changes', which aligns with annotations. It doesn't provide deeper behavioral context beyond what annotations supply, but it does confirm the HTTP method.
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 repetitive, stating 'Retrieve a secondary contact' twice. It includes emoji and line breaks, which add visual structure but also redundancy. It could be more concise by removing duplicate phrasing.
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 is simple (one parameter, no output schema) and annotations cover safety, the description is adequate. It provides the endpoint and confirms read-only behavior. However, it does not explain the return format or error handling, but for a straightforward read operation, completeness is acceptable.
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 100% with a single parameter 'id' described as 'Secondary Contact's id'. The description does not add any additional semantic information beyond what the schema already provides. Baseline is 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 states 'Retrieve a secondary contact' and 'Fetches data. Makes no changes to your ActiveCampaign account.' The verb 'retrieve' and resource 'secondary contact' are specific. The context of sibling tools includes 'list_all_secondary_contacts' and mutation tools, so this tool is clearly distinguished as a single-item read.
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 explicitly state when to use this tool versus alternatives like 'list_all_secondary_contacts'. It only says 'Retrieve a secondary contact', which implies use when you need a specific record by ID. No exclusions or alternative guidance is provided, but the purpose is clear enough for an agent to infer basic usage.
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?
Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds 'READ-ONLY' and 'Makes no changes', which aligns but doesn't add new behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but contains redundancy, repeating 'Retrieve a task type - outcome relation' twice. It could be more concise without losing clarity.
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 simplicity of the tool (1 required parameter, no output schema), the description is adequate. It clearly states the purpose and safety, though it could mention the expected return 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 100% coverage with a clear description for the single parameter. The description does not add any additional meaning beyond what the schema already provides.
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 retrieves a task type-outcome relation, with a specific verb and resource. It differentiates from siblings like list_all_task_type_outcome_relations and delete_a_task_type_outcome_relation.
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 you have an ID and need a single relation, but provides no explicit guidance on when not to use it or alternatives like list_all for retrieving multiple relations.
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?
Description indicates write operation and idempotence, matching annotations (readOnlyHint=false, idempotentHint=true). Constraint on non-numeric segment IDs is added. Could elaborate on consequences of revert but overall consistent.
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?
Reasonably concise, though includes an emoji and URL path that are not essential. 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?
Covers key aspects: write operation, idempotence, constraint on segment IDs. No output schema, so missing return value description, but not critical for a revert 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 100% with basic descriptions. Description adds little beyond schema (e.g., timestamp as 'point in time'). Adequate but not enhanced.
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 verb 'Revert' and resource 'Segment', including that it reverts to a historic definition using a timestamp. Constraint on segment ID type is noted. However, it does not explicitly distinguish from siblings like update_segment or get_segment_historic.
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?
No explicit when-to-use or when-not-to-use guidance. Idempotent hint and segment ID constraint are given but no comparison to 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?
Annotations already provide destructiveHint: false, idempotentHint: true. The description adds 'Idempotent' and 'Modifies an existing record in place', which reinforces the annotations but does not disclose additional behavioral traits beyond what annotations already state.
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 write emoji and method. However, it redundantly repeats 'Update a group' after the title. Overall, it is concise with minimal waste.
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 nested body with many fields, the description is minimal. It lacks explanation of partial vs full updates (though idempotentHint suggests PUT semantics). Absence of output schema is acceptable but more context on update behavior would be 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?
All parameters (id and body) have descriptions in the input schema, so schema coverage is 100%. The tool description does not add further meaning or examples for the parameters. Baseline score of 3 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 'Update a group' and 'Modifies an existing record in place', with the verb 'update' and resource 'Groups'. It distinguishes from siblings like create_a_new_group and delete_a_group_1 by specifying modification of an existing record.
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 for updating an existing group via 'Modifies an existing record in place', but does not provide explicit when-to-use or when-not-to-use guidance compared to other update tools among siblings. 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint false, idempotentHint true, destructiveHint false. Description repeats 'Idempotent' and adds 'Modifies an existing record in place', but lacks details on side effects, auth needs, or error 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?
Very concise, two sentences plus a header. Front-loaded with 'WRITE' indicator. However, the emoji and caps are slightly distracting but not harmful.
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, but description doesn't indicate what the response includes (e.g., updated object vs status). For an update tool, this is a notable gap. Annotations fill some safety context but not return 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?
Schema covers both parameters with full descriptions. Description adds no extra meaning beyond what's in the schema, so baseline 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?
Clearly states it updates an exclusion, with verb 'update' and resource 'exclusion'. Distinguishes from sibling read operations like 'exclusions_retrieve_a_list'.
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?
No explicit guidance on when to use this tool vs alternatives. Only states idempotence but not when to prefer this over create or delete operations.
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?
Annotations already declare readOnlyHint=true, etc. The description adds 'READ-ONLY' and 'Makes no changes' but does not disclose additional behavioral traits (e.g., response structure, pagination behavior beyond schema). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (a few lines) with front-loaded info (emoji, HTTP method). However, it redundantly repeats 'List all brandings' twice. Could be slightly more efficient but overall well-structured.
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 (list all, read-only) and full schema coverage, the description is adequate. It lacks explicit mention of pagination but parameters handle that. No output schema, but the return type is inferable.
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?
All 5 parameters have descriptions in the input schema (100% coverage). The description adds no additional meaning beyond what the schema provides, so baseline 3 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 'List all brandings' and 'List all existing branding resources,' specifying the verb (list) and resource (brandings). It implicitly distinguishes from sibling tools like 'get_branding' (singular retrieval) and 'update_branding' (modification).
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 when to use (to list all brandings) but does not explicitly state when not to use or mention alternatives. It lacks guidance like 'for a single branding, use get_branding' or context about pagination.
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?
Annotations indicate a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds that messages are sent to real recipients and are irreversible once delivered, providing behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat repetitive (e.g., 'Create AI-generated broadcast' appears both in title and text). It front-loads key info but could be more concise. The warning is helpful but adds length.
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 purpose and a warning, but lacks details about return value (no output schema), rate limits, or cost implications. For a write tool sending messages, more completeness would be beneficial.
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 describes each parameter (prompt, tone, source) with brief descriptions. The tool description adds no additional parameter-level meaning. With 100% schema coverage, baseline 3 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 creates or schedules an AI-generated outbound message (SMS or WhatsApp). The title and content explicitly mention 'AI-generated broadcast', distinguishing it from non-AI broadcast tools like 'create_broadcast' among siblings.
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 for AI-driven broadcasts and includes a warning to confirm audience before sending, but it does not explicitly specify when to use this tool versus alternatives (e.g., create_broadcast for non-AI broadcasts). Usage context is implied but not explicit.
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 adds useful behavioral context beyond annotations: it labels the operation as a WRITE, shows the HTTP method/endpoint, and explicitly states reversibility. No contradiction with annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=true).
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 compact, using a structured format with emoji indicator, HTTP verb, and endpoint. Every sentence adds value, though the initial line could be slightly more streamlined. Overall, it's efficient and front-loaded.
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 simple nature of the tool (one parameter, no output schema), the description is fairly complete. It explains the action, its reversible nature, and provides an example. It could briefly mention that no return value is expected, but that is acceptable.
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 provides 100% coverage for the single parameter, describing it as 'Field relationship ID to be deleted'. The description does not add any additional meaning or clarification beyond the schema, meeting the baseline expectation.
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 custom field relationship to list(s), and provides an example of its effect (e.g., untagging a contact). While distinct from many siblings, it does not explicitly differentiate from other deletion tools, but the specificity is sufficient.
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 notes the operation is reversible and does not delete underlying records, giving context on when to use. However, it lacks explicit guidance on when not to use or alternatives, such as pointing to other update or delete tools for different scopes.
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?
Annotations already mark destructiveHint=true. The description reinforces this with a red warning emoji and 'DESTRUCTIVE', and adds the important instruction to confirm with the user. However, it does not mention idempotency (despite idempotentHint=true) or what happens if the ID does not 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 short and front-loaded with the warning. It includes all essential information with minimal redundancy, though the first line repeats the action stated later.
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, the description provides the core purpose, destructive nature, and a safety instruction. It does not explain return behavior (no output schema), but this is acceptable given the tool's simplicity.
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 100%, so the schema fully describes the only parameter 'id'. The description adds no further semantic detail beyond what the schema provides.
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 'Delete' and the resource 'deal role', and specifies the HTTP method. It distinguishes itself from sibling delete tools by focusing on deal roles.
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 delete_a_deal or delete_a_deal_stage. The only usage hint is 'Confirm with the user before calling,' which is a safety reminder, not a selection criterion.
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 reinforces the destructive nature with '🔴 DESTRUCTIVE · deletes data' and 'Deletes a record,' adding clarity beyond the annotations (destructiveHint=true). It also instructs user confirmation. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a header line (emoji, HTTP method) and a brief statement. Some redundancy exists between 'Delete a custom field' and 'Deletes a record,' but overall it is 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?
For a simple delete-by-ID tool, the description provides the necessary warnings (destructive, confirm with user) and identifies the resource. It is adequate given no output schema and a single required parameter.
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 covers the parameter 'id' with 100% coverage, describing it as 'ID of the field option to delete.' The description does not add additional meaning about the parameter, so baseline 3 is appropriate.
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 'Delete a custom field' and includes 'Fields' in the header, making the resource clear. However, it also says 'Deletes a record,' which could be slightly misleading, and there is a sibling tool 'delete_a_custom_field' that may overlap.
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 explicitly says 'Confirm with the user before calling,' which provides a usage guideline. However, it does not specify when to use this tool versus alternatives (e.g., delete_a_custom_field) 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?
Annotations already indicate destructiveHint=true and idempotentHint=true. The description adds the explicit warning to confirm with the user, which is valuable behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but contains redundancy (e.g., 'Delete a contact' repeated), and the header line is somewhat noisy. It could be more concise while retaining the warning.
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 destructive tool, the description provides the essential purpose and a safety warning. However, it lacks details about cascading effects, soft vs. hard delete, or what happens to associated data, which 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 100% for the single 'id' parameter, and its description in the schema is sufficient. The tool description does not add extra meaning beyond what the schema provides.
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 contact, with explicit mention of the HTTP method and endpoint. It distinguishes from sibling delete tools by focusing on contacts.
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 crucial safety instruction to confirm with the user before calling, but does not provide guidance on when to use this vs. alternative delete tools (e.g., bulk delete or secondary contact delete).
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?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description adds 'Fetches data. Makes no changes.' but this is redundant with annotations. No extra behavioral context beyond what annotations offer.
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 with three sentences. The first line includes an emoji and HTTP method which is slightly redundant with the title, but overall efficient and front-loaded.
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 read-only operation with two parameters and no output schema, the description covers the essential purpose and behavior. It could mention return format or edge cases, but given low complexity and rich annotations, it is 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?
Schema coverage is 100% with both parameters documented. The description does not add meaning beyond the schema, which is sufficient given high coverage. Baseline 3 applies.
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 gets a record by external id, with a specific verb, resource, and notes read-only behavior. The tool name also distinguishes from siblings like 'get_a_single_record' (internal ID) and 'delete_a_record_by_external_id' (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 implies usage (when you have the external ID), but does not explicitly state when to use this tool versus alternative methods like get_a_single_record. No exclusion or alternative scenarios are 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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, which cover the safety profile. The description adds the HTTP method and endpoint path, but reiterates the read-only nature already present. No additional behavioral traits (e.g., pagination, rate limits) are disclosed. The description does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise (5 lines) and front-loaded with the purpose and endpoint. It uses visual cues (emoji, bold) for clarity. Minor redundancy exists (two sentences about retrieving a customer), but overall it is efficient and well-structured.
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 read-only tool with no output schema, the description covers the essential purpose (retrieve customer), idempotency (read-only), and endpoint. It does not describe the return format, but given the lack of output schema, this omission is acceptable. The tool is simple enough that the description feels 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 100% with a single required 'id' parameter described in the schema. The description does not add any further meaning about the parameter (e.g., format, example). Baseline is 3 because schema covers parameters, but the description contributes no extra semantic 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 'Retrieve' and the resource 'customer' (e-commerce customer). It includes the HTTP method and endpoint path, making the purpose unambiguous. Among siblings, it is distinct as the only tool for retrieving a single customer by ID.
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 indicates it is a read-only operation that does not modify the account. However, it does not provide explicit guidance on when to use this tool over alternatives like 'list_all_customers' or 'get_contact'. The context implies use for a specific customer ID, but lacks clear when-to-use or 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description echoes these ('READ-ONLY', 'Makes no changes') but adds the API endpoint and category. No additional behavioral traits (e.g., auth needs, rate limits) are disclosed beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is mostly concise with a clear emoji and API path. However, it contains redundancy ('Retrieve a user by username' appears twice, and 'Fetches data. Makes no changes.' could be merged). Still, it's compact and front-loaded.
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 low complexity (1 param, no output schema), the description covers the core functionality and safety. It lacks mention of error conditions or response structure, but the tool is simple enough that the description 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?
Schema coverage is 100% with a clear parameter description ('Username of the user you want to view'). The description does not add extra meaning beyond the schema, which is sufficient for a single, self-explanatory 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 tool retrieves a user by username, using specific verb 'Retrieve' and resource 'user by username'. It distinguishes from siblings like get_user (likely by ID) and get_user_email (by email), providing clear scope.
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 indicates read-only usage ('READ-ONLY', 'Fetches data. Makes no changes'), implying safe use without side effects. However, it does not explicitly guide when to use this tool over siblings like get_user or get_user_email, nor mention prerequisites 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?
Annotations already provide readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false. The description adds the HTTP method and endpoint path ('GET /accountCustomFieldData'), and reinforces safety ('Fetches data. Makes no changes.'), which is helpful beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentences plus a header. It front-loads key information (read-only, endpoint) with a visual emoji for quick recognition. 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?
Given good annotations and a fully described input schema, the description is adequate but not complete. There is no output schema, and the description does not explain what the returned data structure looks like (e.g., array of objects with field/value pairs). A brief note on the response format 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?
The input schema has 100% schema description coverage, so the baseline is 3. The description does not add any parameter meaning or usage details beyond what the schema already provides.
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 lists all custom field values and is read-only. However, it does not differentiate from the similarly named sibling 'list_all_custom_field_values' (presumably a different version or scope), leaving ambiguity.
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 emphasizes the tool is read-only ('Fetches data. Makes no changes'), which signals safe usage. But it lacks explicit guidance on when to use this tool versus alternatives like 'list_all_custom_fields_meta' or other listing tools, and no when-not-to-use conditions.
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?
Annotations already provide readOnlyHint, idempotentHint, destructiveHint. Description repeats these with 'READ-ONLY' and 'Makes no changes' but does not add new behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is very concise: one emoji line, two short sentences. No wasted words, front-loaded with core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description covers basic read-only purpose but lacks details on pagination, sorting, or output format. Given no output schema and 4 optional params, more context would help.
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 100%, so parameters are fully documented. Description adds no parameter-specific meaning beyond what the schema provides.
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 'List all saved responses' and adds 'Fetches data. Makes no changes.' This distinguishes it from sibling tools like 'get_a_savedresponse' and 'update_a_saved_response'.
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?
Description implies usage as a list-all operation but does not explicitly mention when to use it vs alternatives or any exclusions. No 'when-not' 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?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description reaffirms 'READ-ONLY' and 'Makes no changes' but adds no new behavioral traits beyond these annotations. The HTTP method 'GET' is a minor addition.
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, with three short lines. Every sentence adds value: the first line provides quick visual cues, the second states the core action, and the third confirms safety. 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?
While the description covers the basic purpose, it lacks details on pagination, output structure, or filtering behavior. Given the absence of an output schema, the description could be more informative about what the agent should expect.
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?
Input schema covers all 4 parameters with descriptions (100% coverage). The description does not add any extra meaning or context for parameters, so baseline 3 applies.
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 'List all segments', specifying the verb and resource. It distinguishes itself from sibling tools like retrieve_a_segment (single) and create_segment/delete_segment (mutations) by implying a listing operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing all segments but does not explicitly contrast with alternatives like retrieve_a_segment for single segments or segment-related summaries. No when-not or exclusion guidance is provided.
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?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description adds minimal behavioral context (HTTP method, resource path) but does not disclose additional traits like rate limits or data format. Since annotations carry most burden, description adds limited value.
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 short but contains redundancy ('List all whitelisted domains' appears twice). It is front-loaded with the READ-ONLY indication but could be more concise without repeating the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no output schema, the description explains it fetches data and makes no changes, but does not describe the return format (e.g., what fields are returned). Parameters are well-covered by schema, so completeness is adequate but not enhanced by the description.
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 100%, so the baseline is 3. The description does not add any parameter-level details beyond what the schema already provides (e.g., pagination or filtering 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 'List all whitelisted domains' and 'List of all whitelisted site tracking domains', directly conveying the action and resource. It distinguishes itself from siblings 'add_domain_to_whitelist' and 'remove_domain_from_whitelist' by focusing on listing.
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 marks the tool as 'READ-ONLY' and states it 'Makes no changes', implying it is safe for read-only operations. However, it does not explicitly mention when not to use it or compare to other list tools, missing a clear instruction for usage 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?
Annotations already declare destructiveHint=true and readOnlyHint=false. The description reinforces this with a red warning and 'deletes data', and adds the important behavioral cue to confirm with the user, which goes beyond annotations. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with a warning. It includes both the HTTP endpoint and usage instruction without unnecessary fluff. Could be slightly tighter by removing the HTTP line, 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?
Given the tool has one parameter, no output schema, and destructive behavior, the description covers the action, the need for confirmation, and the destructive nature. It is sufficient 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with a description for 'id'. The tool description adds no additional meaning beyond what the schema provides, so a baseline score of 3 is appropriate.
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 calendar feed, matching the name and providing the HTTP method and endpoint. It distinguishes from siblings by being specific to calendar feeds, though it doesn't contrast with other delete 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 advises confirming with the user before calling, which is a usage guideline. However, it does not specify when to use this tool versus other delete tools (e.g., list_all_calendar_feeds or update_a_calendar_feed) or provide context for prerequisites.
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?
Annotations already indicate destructiveHint=true and readOnlyHint=false. Description adds important context: 'Deletes a record. Confirm with the user before calling.' and a red icon emphasizing destructiveness. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is short but slightly redundant (repeats 'Delete event (name only)' and 'Remove an existing event tracking event (name only)'). Includes useful warning structure but could be more 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?
Covers essentials: destructive, confirm, event name. However, lacks information about success response, preconditions (e.g., event must exist), or idempotency implications, which would be helpful given no 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 100% with one parameter 'eventName' described in schema. Description only mentions 'name only', adding no additional semantics beyond what schema provides. Baseline 3 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?
Description clearly states 'Delete event (name only)' and 'Remove an existing event tracking event (name only)'. It specifies the action (delete/remove) and the resource, distinguishing it from many other delete tools for different entities (e.g., delete_a_deal, delete_contact).
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?
Description warns 'Confirm with the user before calling' and highlights destructiveness, but does not specify when to use this tool versus alternatives or provide clear usage context beyond deletion.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. Description adds 'Fetches data. Makes no changes' which is redundant and does not provide additional behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is extremely concise, front-loading key information (read-only, endpoint), with no unnecessary words.
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 retrieval tool with one parameter and comprehensive annotations, the description adequately covers what the agent needs to know.
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 covers the single parameter 'id' with description. Description adds no additional parameter information beyond what the schema provides, so baseline of 3 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?
Description clearly states 'Retrieve a campaign' and specifies it is read-only, fetching data without making changes. This distinguishes it from sibling tools like list_all_campaigns and other retrieve actions for different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when needing to get a single campaign's data, but does not provide explicit guidance on when not to use it or alternatives among the many retrieve 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?
Annotations provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds the HTTP method 'GET' and endpoint path, plus 'Fetches data. Makes no changes.' This is consistent and adds some value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with only two lines, including an emoji header and endpoint. Every part is useful and front-loaded, no 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?
No output schema exists, and the description does not explain the return value or structure. For a simple read tool, it's 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all parameters described. The description does not add new parameter information, so baseline score of 3 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 'Retrieve a contact's score value' with a specific verb and resource. It distinguishes itself from sibling tools like 'retrieve_a_score' by specifying it's for a particular contact.
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 'retrieve_a_score' or 'list_all_scores'. The description lacks context on when this tool is 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?
Annotations already declare readOnlyHint and destructiveHint. The description adds the HTTP method and endpoint path, providing minor additional context. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences and a header, front-loading key information without any 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?
For a simple read-only tool with one parameter and no output schema, the description is adequate but could be improved by hinting at the response structure (e.g., what metadata is returned).
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 100%, so the schema fully documents the 'id' parameter. The description adds no further meaning beyond what the schema provides.
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 purpose: 'Retrieve a custom field' and 'Fetches data'. It is distinct from siblings like create, update, delete tools, and the HTTP method is 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 implies usage by stating it is read-only and fetches data, but does not explicitly guide when to use this tool over alternatives like list or other retrieve 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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds context beyond annotations by stating 'Fetches data. Makes no changes to your ActiveCampaign account' and specifying the HTTP method and endpoint. This reinforces the non-destructive nature without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively short but contains some redundancy (e.g., two sentences about fetching data and making no changes). The use of emoji and labels adds visual structure, but the content could be more streamlined.
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 status retrieval tool with full annotation coverage and well-documented schema, the description is adequate. However, lacking an output schema, it would benefit from describing the response structure (e.g., 'returns {siteTracking: enabled/disabled}').
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 100% with descriptions for all 4 parameters, so the description does not need to add parameter details. No additional meaning is provided, but the baseline is adequate.
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 explicitly states 'Get site tracking status (enabled or disabled)', clearly identifying the resource and action. It distinguishes from siblings like 'retrieve_event_tracking_status' and 'retrieve_site_tracking_code' by specifying 'site tracking status' and including 'READ-ONLY' and 'GET /siteTracking'.
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 use for checking site tracking status but provides no explicit guidance on when to use this tool versus alternatives such as 'enable_disable_site_tracking' or 'retrieve_event_tracking_status'. No when-not-to-use or prerequisite information is given.
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?
Annotations already provide write (readOnlyHint=false), idempotent (idempotentHint=true), and non-destructive (destructiveHint=false). Description repeats 'Idempotent' and 'updates data' but adds no new behavioral insight like permissions, error cases, 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?
Concise with two short sentences plus a header line. Front-loads key info (verb, resource, endpoint). The emoji and 'WRITE' label are slightly extraneous but not harmful.
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 update tool, the description covers resource type, idempotency, and HTTP method. No output schema exists, so return value is omitted. Lacks prerequisites or error handling, but sufficient for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description does not elaborate on parameters (id, body) beyond what the schema provides, adding no additional semantics.
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 updates a custom field value, with resource 'Account Custom Field Data' and HTTP method PUT. The description distinguishes it from sibling tools like update_a_custom_field_value_for_contact by specifying account context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for account custom field values via 'Account Custom Field Data', but no explicit guidance on when to use this tool over alternatives like update_a_custom_field_value_for_contact or bulk updates. Lacks 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?
Annotations already indicate idempotentHint=true and destructiveHint=false. The description adds 'Idempotent' and 'Modifies an existing record in place', which are consistent. However, it does not elaborate on side effects or behavioral nuances beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using only two brief sentences and a header line. It front-loads the action with 'WRITE · updates data · Messages' and every sentence adds value 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 the tool has 2 parameters with complete schema documentation and no output schema, the description covers the basic update action and idempotency. However, it does not mention return value or any constraints, which would be 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 100%, so the schema fully documents parameters. The description adds no additional meaning about parameters beyond the schema, thus baseline score of 3 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 verb 'update' and resource 'a message', explicitly saying 'Update a message' and 'Modifies an existing record in place'. It distinguishes itself from sibling tools like create_a_new_message and delete_a_message by specifying it's an update operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives. It implies usage when updating a message, but lacks context on prerequisites, exclusions, or comparisons to other update methods.
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?
Annotations already provide idempotentHint: true, destructiveHint: false, and readOnlyHint: false. The description adds 'Idempotent' which repeats the annotation, and 'modifies in place' which is minimal context. No additional behavioral details beyond what annotations offer.
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 with a front-loaded header and two short sentences. No unnecessary words, and the structure efficiently conveys the tool's purpose and key trait (idempotency).
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 a complex nested body parameter, and no output schema is provided. The description does not explain what the response looks like or success/error behavior. While schema covers parameters, the lack of output information leaves some gaps for the 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 100% and the input schema already describes parameters (e.g., id, body fields). The description does not add any parameter-level meaning, meeting the baseline for high 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 'Update an address' and specifies the HTTP method (PUT) and resource. It distinguishes from siblings such as create_an_address and delete_an_address by focusing on modification of existing records.
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 for updating existing address records, but does not explicitly state when to use versus alternatives like update_a_contact_new. It lacks guidance on 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?
Annotations already provide idempotentHint=true and destructiveHint=false. Description adds 'in place' and repeats idempotent, but no additional behavioral traits like auth requirements 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is slightly repetitive, with multiple lines conveying the same intent (update an order). Could be more concise by consolidating.
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 complex update tool with nested object parameters and no output schema, the description is adequate but does not clarify partial vs full update behavior or return 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?
Schema coverage is 100%, so description adds no extra meaning beyond what's in the schema. Baseline 3 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?
Clearly states 'Update an order' and 'Modifies an existing record in place.' Distinguishes from sibling tools like create_order and delete_order by focusing on modification of an existing resource.
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 context: it's a write operation for ecommerce orders, using PUT method. Implicitly indicates when to use (modify existing order) but lacks explicit exclusions 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?
Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false. The description adds 'Modifies an existing record in place. Idempotent.' which aligns but does not provide additional behavioral details beyond annotations. No mention of auth requirements 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but contains redundancy: 'Update a task' and 'Update an existing task' are repetitive. The first line with emoji and HTTP method is useful, but the overall structure could be more concise. It is not optimally 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 nested input schema and no output schema, the description provides adequate context for a simple update operation. However, it does not clarify that the body is optional or that only provided fields are updated. Sibling tools like create_task and get_task provide contrast.
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 100% coverage with descriptions for all parameters. The tool description does not add extra meaning beyond what is already in the schema (e.g., it doesn't summarize or clarify the optionality of the body). Baseline 3 for high schema 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 'Update a task' and specifies it applies to 'Deal Tasks' with HTTP method PUT. This distinguishes it from sibling tools like create_task, delete_task, and other update tools (e.g., update_a_deal_note). The verb 'update' and resource 'task' 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 implies usage for modifying existing tasks but does not explicitly state when to use this tool over alternatives. However, the resource type 'Deal Tasks' and the operation 'update' provide clear context. 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states 'Not idempotent — calling twice may create duplicates', which aligns with the idempotentHint=false annotation. It also labels the operation as a write ('🟡 WRITE · creates data'). No contradictions with annotations. Adds value beyond annotations by clarifying duplicate risk.
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 (2-3 lines) and front-loaded with the purpose. However, it includes redundant formatting (emojis, HTTP path) that could be merged. Still, every sentence contributes directly to understanding.
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 complexity (nested objects, callback, batching limits), the description is minimal. It does not mention batching behavior, callback details, or error handling. However, the input schema is richly detailed, partially compensating. Could provide more high-level context.
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 main description does not add any parameter semantics beyond what the input schema already provides. Since schema description coverage is 100% for all nested properties, the description does not need to compensate. Baseline 3 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 'Bulk import contacts' with a verb ('Import') and resource ('contacts'). It distinguishes itself from siblings like 'create_a_new_contact' by implying bulk operation. The mention of HTTP method and endpoint adds further clarity.
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 explicitly state when to use this tool vs alternatives. However, the input schema mentions a minimum of 10 contacts, directing users to contact/sync for fewer. No explicit when-to-use or when-not-to-use guidance is provided in the main description.
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?
Description adds behavioral context beyond annotations: explicitly states 'creates data', 'Not idempotent — calling twice may create duplicates', and mentions HTTP method. Aligns with annotations (readOnlyHint=false, idempotentHint=false). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is highly concise: header with purpose and path, then a brief sentence on behavior. No redundant information, and key details are front-loaded.
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 full schema coverage and annotations, the description sufficiently covers purpose, behavior, and idempotency. Omits output details, but no output schema exists, so this is acceptable. Slightly higher than baseline due to completeness within its scope.
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 100% with detailed parameter descriptions (e.g., required fields: fromname, email, reply2). Description does not add additional parameter meaning beyond what the schema provides, so baseline score of 3 applies.
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 a message' and includes the HTTP endpoint 'POST /messages'. It specifies the resource (message) and action (create), distinguishing it from sibling tools like update_a_message or delete_a_message.
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. Lacks prerequisites, exclusions, or recommended context for use. The non-idempotence note is a behavioral warning but not a usage guideline.
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?
Annotations already declare idempotentHint=false, and description reinforces that with explicit duplication warning. No contradictions. Adds behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: 3 lines covering action, endpoint, and key behavior (non-idempotent). Front-loaded with emoji and clear verb. 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?
For a simple create tool with nested input and no output schema, the description is adequate. It covers purpose and idempotency, though it lacks details on response or prerequisites.
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 100%, so baseline is 3. Description adds no additional meaning to parameters beyond what the schema already provides.
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 'Create a custom field value' and 'Creates a new record', with endpoint and write indication. However, it does not differentiate from closely related siblings like create_a_custom_field_value, 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 mentions non-idempotency and potential duplicates, but provides no guidance on when to use this tool versus the many other create tools among siblings.
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 adds the confirmation requirement beyond the annotations (destructiveHint=true). It reinforces the destructive behavior, but could mention idempotency or permanence.
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 repetitive, stating 'Delete a deal' three times and including unnecessary duplication. A more concise version would improve clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with one parameter and no output schema, the description covers the core action and user confirmation. However, it omits details about soft/hard delete or response 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?
Parameter schema has 100% coverage, so baseline is 3. The description does not add any extra detail about the 'id' parameter beyond what the schema already provides.
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 that the tool deletes a deal, using a specific verb and resource. The emoji and 'DESTRUCTIVE' label further distinguish it from create, update, and retrieve siblings.
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 an explicit instruction to 'Confirm with the user before calling,' which provides a clear when-to-use guideline. However, it does not compare to alternatives or specify 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, but the description adds value by using a warning icon and explicitly stating 'deletes data' and 'Deletes a record.' It also instructs to confirm with the user, which goes beyond the annotation.
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 slightly repetitive, stating 'Delete a task type - outcome relation' multiple times. While it is front-loaded with the destructive warning, the redundancy reduces 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 delete tool with one required parameter and no output schema, the description covers the essential aspects: what it does, destructive nature, and a usage caution. It is adequately complete given the tool's simplicity.
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 has 100% coverage for the single required parameter 'id' with a clear description. The tool description does not add any additional semantics or context about the parameter, so it does not improve upon 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 explicitly states 'Delete a task type - outcome relation' and uses the verb 'Delete' with a specific resource. It is distinct from sibling delete tools due to the unique 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 includes 'Confirm with the user before calling' as a safety guideline, but does not provide any guidance on when to use this tool versus other delete tools (e.g., delete_a_task_outcome). No explicit when-to-use or alternative comparisons.
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?
Annotations already declare idempotentHint=true and destructiveHint=false. The description adds 'Idempotent' and 'Modifies existing record,' which are redundant with annotations. No additional behavioral traits (e.g., permissions, side effects) are disclosed.
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 and front-loaded with key information (icon, HTTP method, purpose). It is efficient but could be slightly more concise without losing meaning.
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 write operation with many parameters, the description lacks information about return values, error handling, or optional parameters. Annotations compensate for idempotency, but completeness is average.
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 50%; most body parameters have descriptions in the schema. The description adds no further detail about parameters, relying on the schema. The 'id' parameter is not described but is implied by 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 edits/modifies an existing campaign, using 'Edit campaign' and 'Modifies an existing record in place.' It distinguishes itself from create or delete tools among siblings.
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 indicates the tool is for modifying an existing campaign, and mentions idempotency. It does not explicitly state when not to use it or provide alternatives, but the context of sibling tools makes the purpose clear.
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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds value by specifying the READ-ONLY nature, pagination (up to 50 results), the exclusive timestamp semantics, and the HTTP method. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise, with clear sections: emoji/prefix, purpose, pagination detail. It is front-loaded, though the repeated 'READ-ONLY' and emoji could be streamlined.
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 the description should clarify the return format. While it mentions 'result counts', it does not specify the structure of the response (e.g., array of objects with count and timestamp). This leaves ambiguity for the 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 100% with both parameters described in detail. The description restates the schema's info about exclusive timestamp and page size, but does not add new meaning beyond the structured data.
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 'retrieve', the resource 'result counts for the given segment', and the constraint 'without an AdditionalCriteria'. It distinguishes this tool from siblings like get_count_history_by_segment_id.
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 mentions pagination and exclusive timestamp, but does not explicitly state when to use this tool vs alternatives like get_count_history_by_segment_id or get_recent_count_history. Usage context is implied but not clearly differentiated.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds 'Fetches data. Makes no changes to your ActiveCampaign account' and reveals the HTTP method GET, providing extra context. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat repetitive with two similar sentences ('List all task type - outcome relations' and 'Retrieve all existing task type - outcome relations'). It could be more concise, but the front-loading with emoji and method is good.
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 4 optional parameters (limit, offset, orders, filters) and no output schema, the description adequately covers the operation's purpose and safety. It could explain pagination behavior or the concept of relations, but it is sufficiently complete for a list 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 100%, so parameters are already described. The description does not add additional meaning beyond what is in the schema. Baseline score of 3 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 'List all task type - outcome relations' and 'Retrieve all existing task type - outcome relations', specifying the exact resource and action. It distinguishes from siblings like 'retrieve_a_task_type_outcome_relation' (singular) and other relation 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 implies usage for listing all relations, but does not explicitly mention when to use this tool over alternatives. It lacks guidance on when not to use it or differentiation from the singular retrieve tool.
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?
Annotations already provide readOnlyHint and destructiveHint. The description adds context that data is generated from contact retrieval and that no changes are made, aligning with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat verbose with emoji and multiple paragraphs. It conveys necessary info but 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?
With no output schema, the description fails to explain the return structure or specific fields of activities, leaving a gap for an agent to understand how results are formatted.
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 descriptions cover 100% of parameters with details. The description adds no extra parameter-level meaning beyond high-level usage, so a baseline of 3 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 it lists a contact's activities, uses a read-only indicator, and explains the context (after retrieving a contact). It distinguishes from siblings by focusing on activities generated from contact 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 specifies when to use the tool (after retrieving a contact) and its usefulness for searching contacts. However, it does not explicitly exclude alternative tools or provide 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, and idempotentHint. The description confirms it fetches data and makes no changes, but does not add behavioral traits beyond annotations. No pagination or filtering behavior details are added beyond what the schema provides.
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, front-loading key details (READ-ONLY, Custom Objects, HTTP endpoint) in a single line, followed by a brief summary. 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?
For a simple list operation with well-defined schema and annotations, the description is sufficient. It identifies the operation type, resource, and safety properties. However, it does not explicitly state that it returns multiple records or describe the response format, which could be inferred but is not stated.
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 100%, so baseline is 3. The description does not add any parameter-specific meaning beyond what the input schema already describes (e.g., limit, offset, filters). It only references the schemaId implicitly through the tool purpose.
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 lists records by schema, uses specific verb 'List', identifies resource type 'Custom Objects', HTTP method 'GET', and explicitly notes it is READ-ONLY and makes no changes. This differentiates it from siblings like 'get_a_single_record' (single record) and 'list_all_schemas' (schemas).
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 explicitly state when to use this tool versus alternatives like 'get_a_single_record' or 'list_all_schemas'. While the name implies usage for listing records of a specific schema, no exclusion criteria or alternative suggestions are provided.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds 'Makes no changes' and the HTTP method, reinforcing but not significantly expanding beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using a single line with emoji and method, followed by two short sentences. Every part contributes purpose without wasted 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's simplicity (one parameter, no output schema, and comprehensive annotations), the description is adequate. It lacks mention of the return format, but the context of a retrieval tool makes this acceptable.
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 only one parameter 'id' with a clear description in the schema. The description does not add any additional meaning or format details beyond what the schema provides.
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 'Retrieve' and resource 'a contact automation', with the HTTP method and path. It distinguishes from siblings like 'list_all_contact_automations' (list) and 'create_new_contactautomation' (create) by specifying it's a single 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 for retrieving a specific contact automation by ID but does not explicitly state when to use this versus listing or creating. No alternative names 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and destructiveHint. The description repeats that it makes no changes, which is consistent but adds no new behavioral context beyond what annotations offer. The HTTP method is mentioned, but that's minimal extra value.
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: three lines with an icon, HTTP method, and clear statement. No wasted words, and the most important info is front-loaded.
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 one parameter and no output schema, the description adequately covers the action and idempotency. It could mention return format or error handling, but the tool's simplicity makes this acceptable.
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 100% with a description for the 'id' parameter. The tool description does not add any additional information about the parameter beyond the schema, so baseline score of 3 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 verb 'Retrieve' and resource 'a note', includes a visual indicator for read-only, and specifies the HTTP method and endpoint. This distinguishes it from sibling tools like create_a_note or update_a_note.
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 indicates read-only functionality but does not explicitly guide when to use this tool over alternatives like 'retrieve_list_of_all_notes'. No exclusions or context for selection are provided.
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?
Annotations already declare readOnly and idempotent. The description adds the HTTP method (GET), states 'Fetches data. Makes no changes', and explains the behavior of the showFields parameter (e.g., deleted fields show 'status: marked_for_deletion'). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly concise with two main parts: a header and a usage tip. There is slight repetition of 'Retrieve a schema' but overall it is well-structured and not overly verbose.
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, the description covers the main behavior and parameter usage. However, it lacks details about error responses, output structure (no output schema), or edge cases. Adequate but not exhaustive.
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 100%, so baseline is 3. The description adds a usage tip for showFields but does not add new semantic meaning beyond the schema descriptions. For the id parameter, no additional context is provided.
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 a schema by ID. The verb 'retrieve' and resource 'schema' are specific, and it distinguishes from sibling tools like list_all_schemas (list all) and create/update/delete schemas.
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 usage tip for the showFields parameter but does not provide guidance on when to use this tool versus alternative tools like list_all_schemas. Basic usage is implied but no explicit when-to-use 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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description confirms 'Fetches data. Makes no changes.' but adds no further behavioral traits such as rate limits or error handling, so it adds minimal value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two short sentences plus an endpoint line. It is front-loaded with the endpoint and purpose. No unnecessary text, but the emoji and formatting add slight overhead.
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 read tool with one parameter and comprehensive annotations, the description is complete. It clearly states the resource, action, and safety profile. No output schema exists, so description does not need to explain return values.
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 100% with a clear description for the 'id' parameter. The description adds no extra meaning beyond what the schema provides, matching the baseline for high 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 'Retrieve a tag' with a specific verb and resource. It is distinct from sibling tools like create_a_new_tag or update_a_tag. The inclusion of 'READ-ONLY' and 'GET /tags/{id}' further clarifies the 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 indicates the tool is for retrieving a tag and that it makes no changes, but it lacks explicit guidance on when to use this tool versus alternatives. No when-not or exclusion criteria are provided.
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?
Annotations already provide readOnlyHint and destructiveHint. Description adds value by explicitly stating 'READ-ONLY', 'Fetches data. Makes no changes.', and revealing the HTTP method and endpoint structure, which goes beyond annotation content.
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 succinct with two distinct sections: an emoji-labeled header and a brief action statement. No redundant or unnecessary 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?
For a simple retrieval with one parameter and robust annotations, the description covers the core need. It lacks information about return format or pagination, but given the tool's simplicity, this is acceptable.
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?
Input schema covers 100% of parameters with a description for 'id'. Description does not add any new semantic information beyond the schema, so baseline 3 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?
Description clearly states 'Retrieve a template' and includes 'Templates' label and HTTP method. It specifically targets templates, distinguishing it from many sibling retrieval tools for other resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies use when needing template data but provides no explicit guidance on when to use this tool versus alternatives like retrieve_a_campaign or retrieve_a_deal. No exclusions or when-not-to information.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds a green 'READ-ONLY' label, HTTP method (GET), and endpoint path, which provide minor additional context beyond annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two clear sentences plus a formatted line for the HTTP method. No filler content, though the emoji and formatting are minimal and acceptable.
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 is adequate for a simple list retrieval tool with a required contact ID. It does not describe the response format or pagination behavior, but these are partially inferable from parameters (limit, offset). No output schema exists to supplement.
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 100% description coverage, so the schema already documents all parameters. The tool description does not add any additional parameter-level details beyond what is in 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 'Retrieve a list of contact's deals' and 'Fetches data. Makes no changes.' The verb 'retrieve' and resource 'list of contact's deals' are specific, and the tool name includes 'contact_deals_list', distinguishing it from sibling tools like 'list_all_deals' which retrieves all deals.
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 implies usage for retrieving deals of a specific contact via the required 'id' parameter. However, it does not explicitly state when to use this tool versus alternatives (e.g., 'list_all_deals' for all deals), nor does it mention any exclusions or prerequisites.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, fully covering the safety profile. The description reinforces this with 'Fetches data. Makes no changes' and adds the HTTP method/path, providing additional context beyond annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the purpose and route. It uses a clear structure: emoji indicator, section label, HTTP path, then purpose. However, the route notation is somewhat technical and may not be essential for an AI agent. Overall efficient but could be slightly trimmed.
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, and the description does not specify what the tool returns (e.g., boolean, match status, response fields). For a simple check tool, the agent might infer a boolean or status, but explicit return information is missing. Given the rich annotations and complete schema, the description 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 100% and each parameter has a basic description (e.g., contactId: 'ContactId'). The description adds no extra meaning or constraints beyond the schema. While the schema is complete, the description does not enhance parameter understanding, earning a baseline 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 checks if a Contact matches a Segment using an externalId. The verb 'Check' and the resource 'Contact matches a Segment' are specific. This distinguishes it from other segment-related sibling tools like get_segment or create_segment, as no other tool performs this exact externalId-based match check.
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 for verification ('Check to see if a Contact matches a Segment'), but provides no explicit when-to-use, when-not-to-use, or alternatives. Given the many sibling tools, guidance on when to choose this over other segment tools would improve clarity.
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?
Annotations include idempotentHint=false and destructiveHint=false; the description explicitly states 'Not idempotent' and 'Creates data', adding value beyond annotations. It also includes a warning label ('🟡 WRITE · creates data'). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using three lines: an emoji/label line, a one-line description, and a caution sentence. It is front-loaded and contains no filler.
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 a nested input schema and no output schema. The description clarifies idempotency and write nature, but does not mention return values, error behavior, or success criteria. Gaps exist for a bulk 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 100%, so the schema already fully documents parameters. The description adds no additional parameter details, resulting in baseline score of 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 'Bulk create a custom deal field value' and 'Creates a new record', identifying the action (bulk create) and resource (custom deal field value). The sibling set includes a singular create tool, distinguishing this as the bulk version.
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 usage caution: 'Not idempotent — calling twice may create duplicates.' However, it does not explicitly state when to use this tool versus alternatives like the singular create_custom_deal_field_value.
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?
Annotations already indicate destructiveHint=true, but the description adds useful behavioral context by emphasizing the high blast radius and the need for confirmation. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise but includes some repetition (e.g., 'Bulk Delete Variables' and 'Bulk delete personalization variables'). It is front-loaded with critical information (destructive hint, endpoint). Each sentence adds value, though minor redundancy exists.
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 delete tool with no output schema, the description sufficiently covers purpose, caution, and resource type. It lacks mention of idempotency (though annotation says idempotentHint=true), but overall it is complete enough for the agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single 'ids' parameter, which the schema describes as 'List of variables to be deleted, ie: 1,2,3'. The description does not add further semantics beyond what the schema provides, so baseline score of 3 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 'Bulk Delete Variables' and 'Deletes many records in a single call', providing a specific verb and resource. It distinguishes from sibling tools like 'delete_variable' (single delete) and other bulk operations.
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 cautionary note 'High blast radius — always confirm before calling', which gives usage guidance. However, it does not explicitly compare to alternatives (e.g., when to use delete_variable instead), so the guidance is implicit.
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?
Annotations confirm creative, non-idempotent, non-destructive behavior. The description reinforces this with 'creates data' and adds the duplicate warning, providing behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description includes repetitive phrases ('Create a secondary contact' appears twice) and a redundant header line. It could be more concise without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has nested objects and no output schema. The description provides basic purpose and a non-idempotency note but lacks prerequisites, response details, or relationship to other tools, making it only somewhat 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?
Input schema has 100% coverage with descriptions for all parameters (deal and contact). The description adds no extra meaning beyond what the schema provides, meeting baseline but no more.
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 'Create a secondary contact' and 'Create a new secondary contact for a deal', with the verb 'create' and resource 'secondary contact'. It distinguishes from siblings like 'create_a_new_contact' and 'update_a_secondary_contact'.
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 notes the operation is write (creates data) and explicitly states 'Not idempotent — calling twice may create duplicates', guiding usage. However, it does not compare with other create tools 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark destructiveHint: true. The description adds the confirmation requirement and shows the HTTP method, providing behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief at three sentences, but includes redundant phrases ('Delete a custom field value' and 'Deletes a record') and an emoji. Could be slightly tighter, 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?
For a single-parameter delete tool with annotations and no output schema, the description covers the action, destructiveness, and user confirmation. Lacks prerequisites or permissions, but 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?
Schema coverage is 100%, so baseline is 3. The description does not add meaning beyond the schema; the schema's parameter description says 'to retrieve' which is inconsistent with deletion, but description does not correct or clarify.
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 explicitly states 'Delete a custom field value' and 'Deletes a record', with the HTTP method and path. The resource ('Deal Custom Field Data') distinguishes it from other delete tools among siblings.
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 instructs to 'Confirm with the user before calling', which is a caution for destructive actions, but does not provide explicit when-to-use or alternatives compared to similar delete 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?
Annotations already set destructiveHint=true and readOnlyHint=false. The description adds '🔴 DESTRUCTIVE · deletes data' and 'Confirm with the user before calling,' which reinforces the destructive nature and imposes a procedural requirement beyond the annotation hints.
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, front-loaded with the destructive warning, and includes actionable instruction. It could omit the HTTP method path as it adds little value for agent invocation, but overall it is efficient and 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?
Given the tool's simplicity (single parameter, no output schema, annotations present), the description provides sufficient context: purpose, destructive nature, and user confirmation requirement. No critical gaps are apparent.
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 100% and the parameter 'id' is described as 'ID of the field to delete' in the input schema. The tool description adds no additional meaning beyond this, so baseline score of 3 is appropriate.
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 'Delete a custom field' and 'Deletes a record,' indicating the verb (delete) and resource (custom field meta). While it does not explicitly distinguish from sibling delete tools, the name 'delete_a_custom_deal_field_meta' is specific enough to avoid 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 explicitly instructs 'Confirm with the user before calling,' providing clear guidance on when and how to use the tool. It does not explicitly mention alternatives or when not to use, but the destructive warning and confirmation requirement are strong contextual cues.
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?
Annotations already indicate a non-destructive write operation (destructiveHint=false, readOnlyHint=false). The description adds value by confirming the operation is reversible and does not delete underlying records, clarifying that it only removes the association. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise but includes some repetition (e.g., 'Delete an association' appears twice). The inclusion of the emoji, HTTP method, and URL provides quick orientation. It could be slightly more streamlined.
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 purpose, effect, and reversibility. It does not discuss error conditions or prerequisites, but these are not critical for a straightforward delete operation. The context about Account Contacts and endpoint is 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?
The sole parameter 'id' is described in the schema as 'Association's ID'. The tool description adds no additional meaning or constraints beyond what the schema provides. With 100% schema coverage, the baseline score of 3 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 removes an association between records, specifying it is reversible and does not delete underlying records. This distinguishes it from other delete tools that may permanently delete records, such as 'delete_contact' or 'delete_a_deal'. The URL and context ('Account Contacts') provide specific scope.
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 the tool should be used to unlink records without destroying them, but it does not explicitly compare it to alternatives or state when not to use it. Among many sibling delete tools, clearer guidance on when to choose this over others would improve the score.
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 explicitly marks the tool as destructive and advises user confirmation, adding behavioral context beyond the annotations (which already include destructiveHint=true). It does not contradict any 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, front-loading the destructive marker and endpoint, but contains slight redundancy ('Delete a record by id' followed by 'Deletes a record'). It efficiently conveys the 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?
For a simple delete tool with annotations, the description adequately explains the action and provides a warning. It does not discuss return values (no output schema) or idempotency, but these are covered by annotations and the simplicity of the 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?
The input schema covers both parameters with clear descriptions ('ID of record', 'ID of schema'), and schema coverage is 100%. The description adds no additional parameter meaning, so a baseline score of 3 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 deletes a record by id, specifies the HTTP method and endpoint, and includes a destructive marker. It distinguishes itself from sibling tools by focusing on 'Custom Objects' records, as indicated by the endpoint path.
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 warning to 'Confirm with the user before calling,' which provides some usage guidance. However, it does not explain when to use this tool versus alternatives like 'delete_a_record_by_external_id' or other delete tools for different entities.
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 adds behavioral context beyond annotations by flagging the tool as 'DESTRUCTIVE' and including the HTTP DELETE method and endpoint. It also reiterates the destructive nature, which, combined with annotations, gives a clear safety profile.
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 repetitive, stating 'Delete a customer' multiple times and including the redundant phrase 'Deletes a record.' While it front-loads the destructive warning and HTTP path, the overall length could be reduced without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a single parameter and no output schema. The description covers the purpose and usage guidelines but does not mention what the tool returns upon success or failure. Given its simplicity, the description is adequate but could be more complete with a note on return behavior.
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 only parameter 'id' is documented in the schema with a description. The tool's description does not add any additional meaning or context beyond what the schema already provides. Since schema coverage is 100%, a score of 3 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 identifies the action as 'delete' and the target resource as 'e-commerce customer', distinguishing it from other delete tools for different resources. The inclusion of the HTTP method and path further clarifies the specific operation.
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 an explicit instruction to confirm with the user before calling, which is a crucial usage guideline for a destructive operation. While it does not mention alternatives or when not to use, the guidance provided is sufficient for safe invocation.
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?
Annotations already indicate destructiveHint=true, but the description reinforces this with '🔴 DESTRUCTIVE · deletes data' and adds the important behavioral detail to confirm with the user. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is repetitive: 'Delete an order', 'Deletes a record', 'Delete an existing e-commerce order resource.' could be consolidated. The tag line adds context but occupies space. Could be more concise without losing meaning.
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 simplicity (single param, no output schema), the description covers the essential action and safety warning. However, it lacks any indication of return value or confirmation behavior, which would be 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?
The input schema already describes the single parameter (ecomOrderId) with a clear description. Schema coverage is 100%, so baseline 3 is appropriate. The description adds no additional parameter semantics.
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 ('Delete an order', 'Delete an existing e-commerce order resource') and the resource type ('Ecom Orders'). It is specific and distinguishes from sibling tools like create_order, update_order, get_order.
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 'Confirm with the user before calling', which is a critical usage guideline for a destructive tool. However, it does not elaborate on when to use versus alternatives like bulk operations or alternative deletion 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?
Annotations already indicate readOnlyHint and destructiveHint=false; the description reinforces that it is read-only and makes no changes. It adds context about the HTTP method, SMS scope, and return data (grouping and counts).
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 (5 lines) and front-loaded with a read-only indicator, SMS, and HTTP method. 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.
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 core purpose, it does not mention pagination, filtering, or other parameter capabilities. Given the 7 parameters, it could be more complete, but the openWorldHint reduces the need for exhaustive details.
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 100% so the schema itself documents all parameters. The description does not add extra meaning beyond what the schema provides, thus baseline score of 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 that the tool retrieves broadcast failure details and returns 'grouping and counts of failures'. This distinguishes it from related tools like get_broadcast_metrics or get_broadcast_recipients.
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 for retrieving failure details but does not explicitly mention when to use it over alternatives or provide exclusions. It lacks guidance on 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and idempotentHint. The description adds valuable context: the response includes an 'is_ready' attribute, error conditions (404 for expired IDs), caching behavior, and sort order preservation. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and key details. It is fairly concise but includes minor formatting (emoji, bold) and some redundancy. Every sentence adds value, though it could be slightly shorter.
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 5 parameters (2 required) and no output schema, the description explains error states and readiness behavior well. It covers key aspects but lacks details on pagination and full response structure. Schema descriptions partially compensate.
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 100%, so baseline is 3. The description adds minimal extra meaning beyond the schema, only briefly touching on sort order. It does not elaborate on page, page_size, or the exact meaning of runId and segmentId beyond what's already in 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 'Return Match All result-set', specifies it is READ-ONLY, and fetches data without making changes. It distinguishes from siblings by referencing the specific API endpoint and parameters (segmentId, runId).
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 for retrieving match-all result sets after a prior request, but does not explicitly tell when to use this tool vs alternatives like create_match_all_request or get_result_set_by_run_id. No exclusions or alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description reinforces a read-only behavior ('Makes no changes') and adds context about returning 'current period's sms credit usage and remaining balance', which enhances transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise and uses a clear structure with headings and bullet-like statements. However, it contains some redundancy (two similar sentences about retrieving credit data) that could be streamlined.
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 annotations (readOnly, idempotent) and no output schema, the description adequately explains what the tool returns (usage and remaining balance). It does not detail pagination behavior, but the parameter schema provides that information.
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 100%, so the baseline is 3. The description does not add parameter-specific details beyond what is already in the schema, such as how limit/offset affect pagination or how filters/orders work.
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 gets SMS credit use data, specifies it's read-only, and mentions the endpoint path. It uniquely identifies a specific resource (SMS credits) among many sibling read 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 indicates this tool is for fetching SMS credit data but does not provide explicit guidance on when to use it versus alternatives or when not to use it. Context implies using it when SMS credit info is needed.
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 adds context beyond annotations: it specifies 'Fetches data. Makes no changes', mentions 'paged list', and indicates SMS channel. Annotations already declare readOnlyHint and idempotentHint, so description complements them.
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 (about 5 lines) and includes essential info like read-only, HTTP method, and purpose. It is well-structured but could be slightly more 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?
Given the moderate complexity (5 params, no required, no output schema), the description covers key aspects: it returns a paged list, is read-only, and belongs to SMS channel. Missing details about what broadcast lists are, but sufficient for a simple list 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 100%, with all five parameters having descriptions. The description does not add extra meaning beyond what the schema provides, so baseline score of 3 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 verb 'Get' and the resource 'broadcast lists', and differentiates from siblings like 'list_broadcasts' by specifying SMS channel. The title 'Get all broadcast lists' reinforces this.
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?
While it mentions read-only and HTTP GET, it does not explicitly state when to use this tool versus alternatives like 'list_broadcasts' (for email broadcasts) or other list tools. Usage context is implied but not explicit.
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?
Annotations already declare readOnlyHint and idempotentHint. The description adds the HTTP method (GET) and explicit statement 'Fetches data. Makes no changes,' reinforcing the read-only 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 short and front-loaded with the HTTP method and resource. However, the sentence 'Retrieve a custom field value' is redundant with the annotation title, slightly reducing efficiency.
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 tool with one parameter and no output schema, the description sufficiently conveys purpose and safety. It could mention the response structure, but the context is 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?
Schema coverage is 100% with a description for the `id` parameter. The description does not add further meaning beyond the schema, so baseline 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 states it retrieves a single custom deal field value by ID, specifying the resource and action clearly. It distinguishes from siblings like `retrieve_a_custom_deal_field_meta` (metadata) and `retrieve_a_custom_field_value` (contact field).
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?
Usage is implied: to retrieve a custom deal field value by its ID. However, no explicit guidance on when to use vs alternatives (e.g., list endpoints) or prerequisites is provided.
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?
Annotations already provide readOnlyHint, destructiveHint, and idempotentHint. The description reinforces these by stating it fetches data and makes no changes, but does not add significant new behavioral information beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using a few lines including emojis and endpoint. It is front-loaded with the read-only indicator and contains no 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?
The description lacks details about the return value structure or pagination behavior, which would be helpful given there is no output schema. It is adequate but missing context for an agent to fully understand the tool's output.
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 100%, so parameters are well-documented in the schema. The description does not add any additional meaning for parameters, meeting the baseline without improving understanding.
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 'List all custom fields' with a specific endpoint and indicates it is for deal custom field meta. The tool name and endpoint distinguish it from siblings like create, delete, update, and singular retrieve.
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 'READ-ONLY' and notes it fetches data without changes, implying safe usage for reading. However, it lacks explicit guidance on when to use this versus retrieving a single field or other list operations.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds confirming context ('Fetches data. Makes no changes to your ActiveCampaign account.') and specifies the HTTP method and path, but does not significantly expand beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise, though it repeats the title 'Retrieve a Variable' within the body. The inclusion of the emoji and endpoint adds useful structure without excessive verbosity.
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 single-retrieve tool with one required parameter and no output schema, the description adequately conveys purpose, safety, and required input. It could mention return format, but given common patterns and annotations, it is sufficiently 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 100% with the variableID parameter already described as 'ID (int) of variable'. The description does not add additional semantic detail about the parameter beyond what the schema provides.
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 a single personalization variable. It uses specific verb ('Retrieve') and resource ('Variable'), and the use of 'individual' distinguishes it from listing operations like 'list_variables'.
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 context ('READ-ONLY', 'Personalizations', 'GET /personalizations/{variableID}') and indicates the tool makes no changes. It implicitly communicates that it is for fetching a single variable by ID, though it does not explicitly exclude alternatives like list_variables.
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?
Annotations indicate write operation and non-destructive. Description adds that it is reversible, which is valuable context. No contradictions; additional behavior like return value not disclosed.
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 includes cluttered elements (emoji, multiple lines) and repeats 'Create an association'. Could be more concise, but overall length is reasonable.
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 creation tool without output schema, it explains the operation and gives examples. Missing return value description, but sufficient for basic understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for each field. Description does not add significant meaning beyond schema, but provides usage context. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates an association between records, specifically for account contacts. It distinguishes from sibling tools like create_an_account_new by focusing on linking records rather than creating an account itself.
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 examples (tags a contact, adds to list/automation) and notes reversibility, implying when to use. However, does not explicitly compare with alternative tools for similar operations.
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?
Annotations already mark destructiveHint=true, so the description's 'DESTRUCTIVE' warning is redundant but reinforces. The addition of 'Confirm with the user' adds behavioral context beyond annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, using a single line plus a bolded warning and endpoint path. Every part adds value, 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?
While the description covers the basics, it lacks details on what happens upon success (e.g., no response body) or error conditions. The idempotency hint is not mentioned. For a destructive tool with no output schema, more context 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 100%, so the baseline is 3. The description does not add any additional meaning or examples for the parameters beyond what the schema provides.
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 explicitly states 'Delete a record by external ID' and uses 'Deletes a record', clearly indicating the verb and resource. It differentiates from sibling delete tools like `delete_a_record` by specifying the external ID method.
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 the instruction 'Confirm with the user before calling', which is a clear guideline for safe usage. 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true. The description adds the destructive emoji and a safety instruction, reinforcing the behavior. No contradiction, but limited extra beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: a single line with emoji and path, followed by two short sentences. Front-loaded with the destructive warning, no wasted 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 with one parameter, the description adequately covers the action, resource, and safety confirmation. Lacks details on irreversibility but implied by destructive nature.
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 100% with one parameter 'id' described. The description does not add any additional meaning beyond the schema, meeting the baseline.
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 schema, identifies the resource as 'Custom Objects', and provides the HTTP method and path. It distinguishes from sibling delete tools by focusing on schemas.
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 confirm with the user before calling, which is a clear usage guideline. Does not specify when not to use or compare to alternatives, 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide destructiveHint=true and readOnlyHint=false. The description adds the emoji 'DESTRUCTIVE' and the phrase 'deletes data', reinforcing the destructive nature. It also instructs to confirm with the user, which adds context beyond annotations. No contradictions are present.
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, consisting of a single emoji line and two short sentences. Every element serves a clear purpose: the emoji signals destructiveness, the HTTP method indicates the endpoint, and the instruction to confirm is actionable. 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?
For a simple tool with one parameter and no output schema, the description covers the core purpose, parameter name, and a safety instruction. It does not mention return values or error handling, but given the tool's simplicity and the annotations, it is largely 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?
The input schema has 100% coverage with a single 'id' parameter described as 'ID of the tag to remove'. The description does not add any additional meaning or format details beyond the schema. Since schema coverage is high, a baseline of 3 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 'Delete a Tag' and 'Deletes a record', specifying the verb and resource. The emoji and HTTP method prefix reinforce the destructive action, making the purpose unambiguous. While it doesn't explicitly differentiate from siblings like 'remove_a_contacts_tag', the name and description make the tool's specific function distinct.
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 advises 'Confirm with the user before calling', which provides a safety guideline for usage. However, it does not mention when to use this tool versus alternatives (e.g., 'remove_a_contacts_tag') or provide exclusions. The implied context is that it's for deleting tags directly, but no explicit comparisons to siblings are given.
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?
Adds user confirmation requirement beyond annotations. Annotations already indicate destructive and idempotent. No mention of 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Contains some redundancy (repeats 'Delete a task outcome' twice). Brief but 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?
Sufficient for a simple delete operation. Includes confirmation guidance. No output schema 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 covers all parameters with descriptions. Description adds no additional parameter information 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?
Clearly states 'Delete a task outcome' with verb and resource. Distinguishes from siblings like create/update/retrieve counterparts.
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 instruction to confirm with user before calling, indicating when to use a destructive operation. Lacks guidance on alternatives like update.
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?
The description explicitly states 'Performs a soft-delete on the requested message,' which adds significant behavioral context beyond the annotations (destructiveHint, idempotentHint). It also marks the tool as destructive upfront. There is no contradiction with the provided annotations.
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, consisting of a header line, a one-line summary, and two short sentences. It is front-loaded with the destructive warning and uses clear language. Every element serves a purpose: specifying the HTTP method, endpoint, resource type, deletion nature, user confirmation requirement, and deletion method.
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 details about the return value or output format, which is important given there is no output schema. It also does not mention any prerequisites, permissions, or scope (e.g., who can delete a broadcast). While soft-delete is noted, the agent may need more information to use the tool correctly, such as what happens upon success or if the broadcast must be in a certain state.
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 one parameter 'id' with description 'Broadcast ID', and the schema coverage is 100%. The tool description does not add further detail about the parameter's constraints, format, or relationship to other entities. Therefore, it meets the baseline but does not provide extra semantic 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 'Delete broadcast message' and specifies it performs a soft-delete on a broadcast message. The header includes 'Sms' and the endpoint, making the target resource unambiguous. It distinguishes itself from many other delete tools by focusing on broadcast messages.
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 the important instruction to 'Confirm with the user before calling,' which is a safety guideline for destructive operations. However, it does not provide explicit guidance on when to use this tool versus alternatives (e.g., other delete methods) or when not to use it. The usage context is implied but not fully elaborated.
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 adds context beyond annotations: it specifies that the deletion includes historic versions and requires user confirmation. Annotations already indicate destructiveHint=true, but the description elaborates on the scope and safety protocol.
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 with three distinct parts: a structured header with emoji, the core action, and a usage instruction. Every sentence serves a purpose 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?
For a simple delete operation with one parameter, the description covers the essential behavioral aspects (version deletion, confirmation). It does not describe the return value, but the absence of an output schema makes that optional. Nearly 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?
The input schema describes the single parameter 'segmentId' with an example and short description. Since schema description coverage is 100%, the description does not need to add parameter details, and it does not. Baseline score of 3 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 verb 'Delete', the resource 'Segment', and the scope 'including its historic versions'. The prefix '🔴 DESTRUCTIVE · deletes data · Segments' immediately conveys the action, distinguishing it from other delete tools among siblings.
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 an instruction to 'Confirm with the user before calling', which provides a usage precaution. However, it does not compare this tool to alternatives (e.g., when to delete vs. archive, or other delete endpoints). The guidance is basic but present.
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?
Beyond annotations (destructiveHint=true), the description adds a clear warning with the red emoji and 'destructive' label, and explicitly says to confirm with user, which is helpful. It also mentions the HTTP method and path.
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 repetitive, stating 'Delete a Variable' three times. The initial line with emoji and HTTP method is good, but the repetition reduces 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 delete operation with one parameter and no output schema, the description covers the destructive nature and the need for user confirmation. It lacks details on error handling or success response, but is mostly 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?
Schema coverage is 100% and the description only restates that variableID is the ID of the personalization variable, adding little new meaning beyond the schema. The HTTP path context is marginally useful.
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 deletes a single personalization variable, using a specific verb and resource, and distinguishes it from siblings like bulk_delete_variables and edit_variable.
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 confirm with the user before calling, providing a clear usage guideline. However, it does not explicitly state when not to use it (e.g., for multiple variables use bulk_delete_variables).
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 aligns with annotations (readOnlyHint, destructiveHint, idempotentHint) and adds context: mentions HTTP GET method, zero side effects, and data retrieval. No additional behavioral traits beyond annotations, but adds value with method and safety emphasis.
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?
Extremely concise: five short sentences including emoji and method hint. No waste, front-loaded with purpose, and structured clearly.
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 read-status tool with one required parameter and no output schema, the description is adequate. It explains what it retrieves (status) and its effect (none), leaving minimal ambiguity.
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 100% and the single parameter 'Id' is clearly described as 'Request ID from AI broadcast creation'. The description does not add meaning beyond the schema, so baseline 3 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 verb ('Get') and resource ('AI broadcast request status'), with explicit clarification that it fetches data and makes no changes. It distinguishes itself from sibling tools like 'create_aibroadcast' and 'update_aibroadcast'.
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?
Usage is implied as checking status after creating an AI broadcast, but no explicit when-to-use or when-not-to-use guidance is given. No alternatives are mentioned among the many sibling 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?
Annotations already provide readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds HTTP method and path, plus reassurance 'Makes no changes.' Adds limited value but confirms safe behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one line with icon and path, two short sentences. No redundant information. Front-loaded with key context.
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 tool is simple (key-based retrieval). Description covers purpose, safety, and HTTP details sufficiently. Could optionally mention response includes record fields.
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 100% with basic descriptions. Description adds no further explanation of parameter formats or constraints. Baseline 3 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?
Specifically states 'Get a record by id' and 'Fetches data. Makes no changes.' Identifies resource (Custom Objects) and HTTP method (GET). Distinguishes from sibling tools like get_a_single_record_using_external_id.
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?
Clear context: READ-ONLY, Custom Objects, GET endpoint. Implies when to use (retrieve record by internal ID) versus alternatives. No explicit exclusions or prerequisites, but adequate for a simple read operation.
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?
Annotations already provide readOnlyHint, idempotentHint, destructiveHint=false. The description reinforces 'READ-ONLY' and 'Makes no changes,' but adds no new behavioral context beyond the structured 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 brief and front-loaded with the endpoint and behavior. It has a minor redundancy (repeating 'Get Flow Execution') but is otherwise efficient and well-structured.
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 read tool with one parameter and full annotations, the description is complete. No missing information needed for correct invocation.
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 100% with a clear parameter description. The tool description adds no extra meaning beyond the schema, so baseline 3 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 'Get Flow Execution by Id' and includes the endpoint pattern. It distinguishes from siblings like list_flow_execution and create_a_flow_execution.
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 'READ-ONLY' and 'Fetches data. Makes no changes.' It implies safe read-only usage, but doesn't explicitly contrast with listing or creation tools, though sibling names make it clear.
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?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint, destructiveHint. Description adds the HTTP method and path, reinforcing read-only behavior. No contradictions, but does not discuss pagination or rate limits beyond the schema.
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 extremely concise: a compact emoji-and-URL summary, a clear purpose statement, and a safety note. Every line 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?
For a simple list tool, the description combined with the input schema covers functionality and parameters. Missing output schema is not critical here, but the return format is not described. Still sufficiently complete for a straightforward read 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?
Input schema has 100% coverage with descriptions for all 5 parameters. The tool description does not add additional meaning beyond what the schema already provides, so baseline of 3 applies.
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 'List all automations the contact is in', clearly identifying the action (list) and resource (automations for a contact). The inclusion of HTTP method and path adds clarity and distinguishes from sibling tools like list_all_automations.
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?
Description notes that it 'Fetches data. Makes no changes,' implying safe usage, but lacks explicit guidance on when to use this tool versus alternatives like retrieve_contact_automation_entry_counts. Usage is implied by name but not spelled out.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds 'GET /groups' and 'Fetches data. Makes no changes.' which aligns with annotations and provides the HTTP method, adding extra context beyond the structured 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 three lines, front-loaded with a clear READ-ONLY indicator and endpoint. Every sentence is necessary and concise with no wasted 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 list tool with good annotations and no output schema, the description adequately states the purpose and behavioral traits. It could mention pagination behavior (though parameters cover pagination), but overall 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?
Schema coverage is 100%—all parameters have descriptions in the schema. The description does not add additional meaning beyond what the schema already provides, so baseline of 3 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 explicitly states 'List all groups' and distinguishes from the sibling tool 'retrieve_a_group' which likely fetches a single group. The verb 'list' and resource 'groups' are clear.
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 indicates the tool is for fetching data and making no changes, but lacks explicit guidance on when to use it versus alternatives like 'retrieve_a_group' or other list tools. No 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this by stating 'Makes no changes'. It adds value by explaining the behavior of the `showFields` parameter and the `status: marked_for_deletion` attribute for deleted fields, which goes beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, front-loaded with key info (read-only, endpoint, purpose), and every sentence contributes. It uses an emoji for quick recognition and is well-structured 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?
For a read-only listing tool with no output schema, the description covers purpose, behavioral guidance, and parameter hints. It lacks explicit mention of pagination (though limit/offset are in schema) and response structure, but given the tool's simplicity and annotation coverage, 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?
The input schema covers all 5 parameters with descriptions (100% coverage). The description offers a hint about using `showFields=all` but does not add significant meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all schemas' and specifies it fetches data from the GET /customObjects/schemas endpoint, making no changes. It distinguishes the tool from its many sibling tools by focusing on Custom Objects schemas, and includes a read-only indicator.
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 usage tip about leveraging the `showFields=all` parameter for programmatic field creation, but does not explicitly discuss when to use this tool versus alternatives (e.g., retrieve_a_schema) or when not to use it. The guidelines are present but not comprehensive.
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?
Annotations already declare readOnlyHint and destructiveHint; the description confirms read-only nature with 'Fetches data. Makes no changes.' and specifies the HTTP method and endpoint, adding useful context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: three lines with emoji, endpoint, and a clear sentence. Every element 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?
Annotations cover safety, schema covers parameters, and description adds endpoint and read-only confirmation. Missing output format description, but acceptable for a read-only list 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 100%, and the description adds no extra meaning to the parameters. Baseline of 3 applies.
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 lists EcomOrderProducts for a specific order, using a specific verb and resource. Distinguishes from sibling 'list_ecomorderproducts' by being order-specific.
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 usage for listing products of a specific order, but provides no explicit guidance on when to use this versus sibling tools 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?
The annotations already indicate non-destructive behavior, but the description adds value by stating the action is reversible and does not delete underlying records. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description includes helpful front matter but is slightly repetitive (e.g., 'Remove a tag from a contact' and 'Delete a contact tag object'). It is adequate but not maximally 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?
For a simple tool with one parameter and no output schema, the description covers the action, effect, reversibility, and lack of destructiveness. It is sufficiently complete for selection and invocation.
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 has 100% coverage with a clear description of the 'id' parameter. The description does not add additional meaning beyond what the schema provides, so baseline 3 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 removes a tag from a contact, using verbs like 'remove', 'unlinks', and 'delete'. It specifies the resource (contact tag association) and distinguishes from siblings like 'delete_a_tag' by noting it does not delete underlying records.
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 for when to use the tool (to unlink records without deleting them) and mentions reversibility. However, it does not explicitly compare to alternative tools like 'create_contact_tag' or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reaffirms read-only behavior, consistent with annotations (readOnlyHint, idempotentHint, destructiveHint). However, it adds minimal beyond annotations, lacking details on response format or potential limitations.
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 three short lines, front-loading the read-only indicator and method. No wasteful sentences.
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 single-parameter read-only tool without output schema, the description adequately covers functionality and safety. Slight gap in explaining what the response contains.
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 100% for the single 'id' parameter with a clear description. The tool description adds no extra 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 'Retrieve a group' with the specific verb and resource, includes HTTP method 'GET', and explicitly says it fetches data without changes. This distinguishes it from sibling tools like create_a_new_group or delete_a_group_1.
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 implies use when needing to retrieve a group by ID and emphasizes it is read-only, but does not explicitly state when not to use it or mention alternatives like list_all_groups.
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?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint=false. Description adds 'Fetches data. Makes no changes.' and the HTTP method, but this is not substantial additional behavioral information.
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?
Extremely concise with no wasted words. Includes a header line and emojis for quick recognition. Every sentence earns its place.
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 high schema coverage and annotations, the description is sufficient for a read-only list tool. It could mention pagination but that is covered in the 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?
Input schema has 100% coverage with descriptions for all 5 parameters. The description adds no new semantic information beyond what the schema already provides.
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 'Retrieve a contact's list memberships' with a specific verb and resource. The name itself differentiates it from siblings like retrieve_contact_deals.
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 indicates read-only and no changes, but does not explicitly compare to alternatives. However, the tool's name and context signal that it is specific to list memberships.
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 adds the behavioral detail 'Not idempotent — calling twice may create duplicates', which complements the annotations (idempotentHint false). It also indicates a write operation (readOnlyHint false). No contradictions; useful context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, front-loaded with a method hint and emoji, and every sentence adds value. No redundant or wasted content.
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 adequately explains the purpose and idempotency behavior. It could mention response format or error conditions, but it is sufficient for a standard create 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 100% (all parameters documented in schema). The description does not add additional meaning or context to the parameters, but the schema already provides detailed descriptions. Baseline 3 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 'Create a saved response' and 'Creates a new record', with specific verb (create) and resource (saved response). It distinguishes itself from sibling tools like get_a_savedresponse (read) and update_a_saved_response (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?
Usage is implied through the name and description, but there is no explicit guidance on when to use this tool versus other siblings like update or retrieve. The 'not idempotent' warning is helpful but does not provide alternatives or exclusions.
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 adds behavioral insight beyond annotations: 'Not idempotent — calling twice may create duplicates.' This addresses a key behavioral trait not fully covered by annotations (idempotentHint=false).
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 header. It is front-loaded with the purpose. However, the header includes redundant emoji and formatting that could be streamlined.
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 create operation with no output schema, the description is adequate. It covers the action and non-idempotency. However, it could mention response details or behavior on duplicate attempts.
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 100%, so baseline is 3. The description does not add parameter-specific details beyond what the schema already provides (e.g., email required, phone, etc.).
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 'Create a contact' and specifies it is a write operation that creates a new record. It also distinguishes from siblings like 'update_a_contact_new' and 'delete_contact'.
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 header '🟡 WRITE · creates data · Contacts · POST /contacts' and the description provide clear context for when to use this tool. However, it does not explicitly exclude alternative creation methods or provide 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?
Annotations indicate readOnlyHint=false (write operation) and destructiveHint=false (non-destructive). The description adds that it is 'Reversible' and provides examples of the association types, which provides behavioral context beyond the annotations. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a header line (emoji, HTTP method, endpoint), a clear purpose statement, and context. It is front-loaded with essential info. Minor redundancy at the end ('Create a contact tag object') but still concise overall.
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 simplicity of the tool and no output schema, the description is sufficiently complete. It explains the action, notes reversibility, and provides examples. It could mention prerequisites (existing tag and contact IDs) but the schema handles that.
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 100%, so the input schema already documents the parameters 'tag' and 'contact' with descriptions. The description does not add extra semantic meaning beyond what the schema provides, meeting the baseline for high 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 the verb 'Add a tag to contact' and specifies the resource as an association between a contact and a tag. It provides examples like 'tags a contact, adds a contact to a list/automation,' which differentiates it from sibling tools like 'create_a_new_tag' (creates a tag) and 'remove_a_contacts_tag' (removes an association).
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 the HTTP method and endpoint, and notes that the action is reversible. It gives examples of when to use it (tagging a contact, adding to a list/automation), but does not explicitly state alternatives or when not to use it. The context is clear enough for an agent to decide.
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?
Annotations already declare readOnlyHint and destructiveHint, and the description adds valuable behavioral details: it creates a short-lived cached result-set, has a 24-hour TTL, a 4-second timeout, and requires polling. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise (4 sentences) and front-loaded with key information. However, it could be slightly more compact without losing clarity.
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?
Despite no output schema, the description explains the asynchronous behavior, polling mechanism, and returned segmentId and runId. This is sufficient for a complex tool, though more detail on the response format would help.
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 100%, so the parameters are well-documented in the schema. The tool description does not add extra meaning to parameters, which is acceptable. Baseline score 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 action 'Create a Match All Request for a new Segment' and the resource. The title and emoji reinforce the read-only nature. It distinguishes from the sibling 'create_match_all_request_with_segment_id' by emphasizing 'new Segment'.
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 explains when to use this tool (to find all Contact IDs matching a new segment), but does not explicitly mention when not to use it or compare with alternatives like create_match_one_request or using an existing segment ID. The polling guidance is helpful but not a full usage guideline.
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?
Annotations already declare readOnlyHint and idempotentHint. The description adds meaningful behavioral context: 'Makes no changes,' 'One result per segment,' 'Pagination not supported,' and 'SegmentIds... will simply be ignored.' This goes beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a header line with emoji and endpoint, followed by two sentences. It front-loads the purpose and constraints. The emoji adds no information but does not hurt. Every sentence 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?
The tool has 5 parameters and no output schema. The description covers return behavior (one result per segment), constraints (max 100, no pagination), and error handling (ignored nonexistent ids). It lacks an explanation of 'without AdditionalCriteria' but overall is quite 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 100%, so the baseline is 3. The description adds minimal extra meaning: it clarifies that nonexistent segment IDs are ignored (beyond the schema's 'comma separated list') and mentions the 100 limit. No other parameter details are expanded.
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 retrieves the most recent result count for segments run without AdditionalCriteria. It specifies the HTTP verb, endpoint, and key constraints (one result per segment, no pagination, max 100 ids). This distinguishes it from sibling tools like get_count_history_by_segment_id or get_saved_segment_summaries.
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 indicates when to use (for segments without AdditionalCriteria) and states constraints (no pagination, max 100 ids, nonexistent ids ignored). It does not explicitly name alternative tools for other scenarios (e.g., segments with AdditionalCriteria or paginated results), but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false, but the description adds context that it is a write operation (🟡 WRITE) and explicitly states 'Reversible'. This goes beyond annotations, though the annotation already set non-read-only and non-destructive.
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: three lines with visual marker, HTTP method, and a short sentence. No fluff, all information is relevant and front-loaded.
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 moderate annotations, the description covers the core action, reversibility, and examples. Lacks details on success/failure responses but is sufficient for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage with descriptions for contact and automation IDs. The description adds meaning by explaining the action ('Creates an association between records') and giving examples, enhancing understanding 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 adds a contact to an automation, with a clear verb ('Add') and resource ('contact to an automation'). It distinguishes from siblings by mentioning 'links records' and 'Contact Automations', and provides the HTTP endpoint.
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 guidance (e.g., 'links records', reversible) but does not explicitly state when to use this tool vs alternatives like create_contact_tag. No exclusions or when-not scenarios are mentioned.
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?
Annotations already provide destructiveHint: true. Description adds visual warning ('🔴 DESTRUCTIVE · deletes data') and user confirmation requirement, which goes beyond annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: single line with emoji, endpoint, and two short sentences. No redundant words, well-structured.
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 tool with one parameter and no output schema, the description covers action, resource, destructive nature, and confirmation step. Could mention response but not critical.
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?
Input schema has 100% coverage with description for 'id'. Description does not add extra meaning beyond the schema, meeting baseline.
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 action ('Delete'), resource ('custom field'), and context ('Account Custom Field Meta'). Distinguishes from siblings like delete_a_field and delete_a_custom_field_value by specifying the exact API endpoint.
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 'Confirm with the user before calling,' providing clear context for safe use. Does not explicitly list alternatives or when not to use, but the destructive nature and confirmation requirement are sufficient.
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?
Annotations already indicate destructiveHint=true. Description adds '🔴 DESTRUCTIVE · deletes data' and 'Deletes a record,' reinforcing the behavior, plus the user confirmation instruction. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is extremely concise: two sentences, an emoji warning, and HTTP method. Every word adds value; no fluff. Properly front-loaded.
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 is adequate. It states the action, confirms destructive nature, and provides user guidance. Could mention response behavior but not essential.
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 100% with a clear parameter description ('ID of the fieldValue to delete'). The description does not add additional meaning beyond the schema, so baseline 3 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?
Description clearly states 'Delete a custom field value' and 'Deletes a record,' with a specific verb and resource. It distinguishes from siblings like delete_a_field (field vs field value).
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 'Confirm with the user before calling,' providing clear usage context for a destructive operation. Does not mention when not to use or alternatives, but the instruction is strong.
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?
Annotations already provide destructiveHint=true and readOnlyHint=false, which are reinforced by the description's 'DESTRUCTIVE' label. The description adds the HTTP method (DELETE) and path, plus the confirmation requirement. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and includes key elements: destructive hint, resource, HTTP method, and confirmation advice. It is front-loaded with the warning. Could be slightly more concise by removing the URL duplication, but overall efficient.
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 simplicity of the tool (single parameter, no output schema, and annotations clarifying safety), the description provides sufficient context. It covers the main concern (destructiveness and confirmation) and matches the tool's actual behavior.
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 for the single parameter (id) is 100%, so description does not need to add much. The description mentions the id parameter implicitly via the URL path '/addresses/{id}', but does not explain it beyond what the schema says ('ID of the Address to delete'). Baseline score of 3 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 action ('Delete an address') and the resource ('Addresses'). It uses the verb 'delete' and specifies the resource, making it easy to distinguish from sibling tools like create_an_address or update_an_address.
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 clear directive: 'Confirm with the user before calling.' This guides the agent on when to use the tool (after confirmation). It implicitly indicates this is for deleting addresses, but does not explicitly contrast with other tools. However, the sibling list includes many delete tools, so the specific resource helps.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description reinforces 'Fetches data. Makes no changes to your ActiveCampaign account,' adding no contradictions but providing additional endpoint context (Deal Groups, GET).
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: three short lines including an emoji label and endpoint info. Every sentence adds value, with no fluff.
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 8 parameters including nested objects and no output schema, the description is somewhat brief but sufficient when combined with the annotated schema. It could mention pagination or result format, but the schema covers parameter details adequately.
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 describes all 8 parameters with full coverage (100%). The description itself does not add parameter-level details beyond what the schema provides, so it meets the baseline of 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 explicitly states 'List all pipelines' and 'Retrieve all existing pipelines.' It also adds context with 'Deal Groups · GET /dealGroups,' clearly distinguishing it as a read-only listing operation 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates it fetches data and makes no changes, making its read-only nature clear. While it does not provide explicit when-to-use or when-not-to-use guidance, the context of 'list all pipelines' is self-evident, and it adequately serves the purpose.
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?
Annotations already provide destructiveHint=true. The description reinforces with 'DESTRUCTIVE · deletes data' and 'Deletes a record.' It adds the HTTP method and confirmation instruction, providing useful behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise with a header, primary statement, and action note. However, the final sentence is redundant ('Remove a domain from the site tracking whitelist'), making it slightly repetitive. Still, it is well-structured.
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 deletion tool with one parameter and no output schema, the description is complete. It specifies the action, resource, parameter, destructive nature, and user confirmation requirement, leaving no 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?
The description does not add meaning beyond the input schema, which already describes the 'name' parameter as 'The domain name to remove from the whitelist'. With 100% schema coverage, baseline score of 3 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 action 'Remove domain from whitelist' and specifies the resource 'Site Tracking Domains'. It distinguishes from siblings like 'add_domain_to_whitelist' and 'list_all_whitelisted_domains'.
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: 'Confirm with the user before calling.' It implies this is for removal only. While it doesn't explicitly state when not to use, the destructive hint and context provide adequate 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?
Description aligns with annotations (readOnlyHint, idempotentHint, destructiveHint false). Adds HTTP method and explicit 'Makes no changes' statement. No contradictions; provides adequate behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one line with emoji and endpoint, then two short sentences. No unnecessary words, front-loaded key info. Every part serves a purpose.
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 read operation with rich schema and annotations, the description is complete enough. Doesn't explain return format or what 'goals' means, but minimalism is acceptable given schema coverage.
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?
Input schema has 100% parameter coverage with descriptions. Description adds no additional meaning beyond what schema already provides. Baseline 3 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?
Description clearly states 'Retrieve a contact's goals' and specifies it fetches data with no modifications, using a specific HTTP endpoint. Distinguishes from sibling tools by its unique purpose (goals).
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?
Implicitly clear when to use (when needing contact goals) but lacks explicit comparison to other retrieve_contact_* tools or when not to use. The read-only annotation and name provide context but no direct usage guidelines.
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?
Annotations already declare idempotentHint=true and destructiveHint=false. The description confirms idempotency and explains the upsert mechanism, adding context beyond annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, using an emoji and key tags. Every sentence provides essential information, with no redundant text.
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 output schema, the description covers the core behavior (upsert) adequately. It could mention response or deprecation notes, but overall it's sufficient for a simple 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 100% with descriptions for all parameters. The description does not add specific parameter-level semantics beyond the schema, so baseline 3 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 'creates or updates' and uses 'upsert' to explain the sync behavior. It includes the HTTP method and endpoint, distinguishing it from separate create and update tools among siblings.
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 implies when to use this tool (for upserting contacts) but does not explicitly compare with alternatives like create_a_new_contact or update_a_contact_new. However, the upsert behavior is clearly communicated.
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?
Annotations (readOnlyHint, idempotentHint, destructiveHint) are already present, but the description adds valuable context: may create a short-lived cached result-set, the instant vs wait behavior, and the need to poll with runId. This fully discloses the tool's non-standard 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 fairly concise and front-loaded with key info (read-only, path, summary). It uses emoji and formatting, which may slightly reduce conciseness but aids clarity. Each sentence adds value, though the polling explanation could be tightened.
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 and absence of an output schema, the description adequately covers the polling mechanism, caching, and the instant parameter. It could mention potential error states or limits, but it's sufficient for a tool that returns data with a possible delay.
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 100%, so the description does not need to explain parameters. It does add context for the 'instant' parameter (returns immediately) and mentions using segmentId and runId for polling, but this is consistent with the schema descriptions. Baseline 3 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's action: 'Create a Match All Request' and explains it runs a search/report that returns data. It distinguishes itself by name from the sibling create_match_all_request, though not explicitly in the description. The emoji and path prefix further clarify it's a read-only query.
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 initiate a match-all request and provides polling guidance when results aren't ready. However, it does not explicitly contrast with create_match_all_request or state when NOT to use it. The guidance is clear but incomplete for exclusion cases.
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?
Adds value beyond annotations by stating the operation is reversible and does not delete underlying records. This clarifies the non-destructive nature, which complements annotations (destructiveHint: false) and idempotentHint: true.
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?
Front-loaded with a concise prefix line including method, resource, and endpoint. Three sentences with no waste. Every piece of information earns its place.
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?
Simple tool with one parameter and no output schema. Description fully explains the effect (removes association, reversible) and is sufficient 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (id) with 100% schema coverage; the schema already describes it well. The description adds no extra meaning beyond what the schema provides.
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 identifies the resource (Contact Automations) and action (remove association). Distinguishes from siblings like delete_contact by emphasizing it only unlinks records and does not delete underlying records.
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 context for usage by explaining it removes an association rather than deleting records, with examples like untagging a contact. No explicit when-not-to-use, but purpose is clear enough.
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?
Annotations include destructiveHint: true and idempotentHint: true, and the description reinforces this with 'DESTRUCTIVE' and 'deletes data'. No contradictions. Adds user confirmation guidance beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentences plus a header. Every element is essential and front-loaded with the destructive warning. No superfluous text.
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, the description is complete. It covers the destructive nature, the resource type, the HTTP method, and adds a safety instruction. Annotations handle the behavioral hints.
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 100% and the parameter 'id' is adequately described in the schema. The description does not add new semantics beyond what the schema provides, meeting the baseline.
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 explicitly states 'Delete a message' and 'Deletes a record' with the HTTP method and resource path. The tool name and title are consistent, leaving no ambiguity about what it does. Among many delete siblings, it clearly targets messages, distinguishing via the noun.
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 instructs 'Confirm with the user before calling', which is a clear usage guideline for a destructive action. It does not explicitly compare to alternatives, but the context of deletion is self-contained.
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?
Annotations already provide readOnlyHint, destructiveHint, and idempotentHint. The description adds the endpoint path and reinforces the read-only nature, providing useful but not essential context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using only one short sentence plus a supplementary line. It is well-structured with emoji and capitalization for quick scanning.
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 retrieval tool with one required parameter, no output schema, and comprehensive annotations, the description provides all necessary context: what it does, that it is read-only, and the endpoint.
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 100%, and the schema already defines the 'id' parameter with a description. The description does not add any additional detail or context for 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 'Retrieve a saved response', specifies the HTTP method 'GET', and emphasizes it is read-only and makes no changes. It distinguishes from siblings like 'list_all_saved_responses' and 'update_a_saved_response'.
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 visual cues ('🟢 READ-ONLY') and explicit statements about not modifying data, which guide usage. However, it does not explicitly mention when not to use or reference alternative tools like 'list_all_saved_responses'.
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?
Annotations already indicate idempotency and non-destructive nature. The description adds beyond annotations by explaining the effect of the showFields query parameter, the status of deleted fields, and practical tips for field uniqueness. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loads the action and tool type with an emoji indicator, and structures information well. The included URL is useful but adds length; could be shortened. Overall, it's efficient 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 complex nested input schema (with fields, relationships, labels) and no output schema, the description provides sufficient context: it explains idempotency, the showFields parameter behavior, and handling of deleted fields. It does not need to describe return values. Edge cases like deleted fields are covered.
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 100% description coverage, so the schema itself documents all parameters. The description adds extra context by emphasizing the showFields parameter and its role in ensuring field id uniqueness. This provides practical value beyond the schema's parameter 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 'Update a schema' and 'Modifies an existing record in place'. It identifies the resource as schemas under Custom Objects and distinguishes itself from sibling tools like create_a_schema, delete_a_schema, and retrieve_a_schema. The HTTP method and path are also included for clarity.
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 for when to use this tool (to update a schema) and provides guidance on related operations (e.g., deleting a field via another endpoint). It does not explicitly exclude scenarios, but the context is sufficient for an agent to decide usage among many siblings.
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 adds behavioral context beyond annotations by explicitly noting that the tool can perform mutations and should be treated as a write (annotations have readOnlyHint=false and destructiveHint=false). It also mentions the endpoint URL. However, it could elaborate on potential side effects or idempotency.
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: purpose, behavioral warning, and usage guidance. It is front-loaded with the core purpose and contains no unnecessary words or repetition.
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 GraphQL tool with 3 parameters, no output schema, and informative annotations, the description covers the essential: purpose, when to use, behavioral note, and endpoint. It could mention that the response is JSON or provide an example, but overall it 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?
Schema coverage is 100% with descriptions for all three parameters. The description does not add significant additional meaning beyond the schema; it merely restates that the query document can be a mutation. Baseline score is appropriate as the schema already does the heavy lifting.
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 ('Run'), the resource ('ActiveCampaign's Ecommerce GraphQL API'), and the action ('return the JSON result'). It also distinguishes itself from siblings by recommending REST tools for standard CRUD and this for precise field selection or ecommerce data, providing clear differentiation.
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 this tool ('precise field selection or ecommerce data') and when not to ('prefer dedicated REST tools for standard CRUD'). It also warns that GraphQL documents may contain mutations, indicating treatment as a write.
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?
Annotations indicate this is a write operation (readOnlyHint=false) and not destructive (destructiveHint=false). The description adds value by stating the HTTP method (POST) and that the operation is reversible, which is beyond the annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: two sentences plus a compact header with category and HTTP method. Every part adds value, and it is front-loaded with important metadata.
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 explains the operation well, including examples and reversibility. It could mention response format or error handling, but the current content is sufficient for a write tool with high schema coverage.
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 100%, so baseline is 3. The description adds meaning by explaining the effect of the operation (associates records) and providing examples, which helps understand the 'field' and 'relid' parameters beyond their 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 that the tool creates a custom field relationship to lists, and it differentiates itself from siblings like 'delete_a_custom_field_relationship_to_lists'. Examples (tags a contact, adds to list/automation) further clarify the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage context with examples and mentions reversibility, but does not explicitly state when not to use the tool or suggest alternatives. Given the large sibling set, this is adequate.
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?
Annotations already provide readOnlyHint, idempotentHint. Description adds: POST returns data, no record changes, may create a cached result set. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with 3 sentences plus a header. Front-loaded with key info (read-only, POST, export CSV). Every sentence 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 no output schema, the description covers purpose, parameters, and behavior. Could detail CSV columns but 'performance metrics' suffices.
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 100% and describes the 'body' parameter with 'ids' array. Description does not add parameter info beyond schema, meeting baseline.
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 exports broadcast metrics as CSV, with a specific verb and resource. It distinguishes from likely sibling 'get_broadcast_metrics' by noting CSV output.
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 indicates use for exporting CSV metrics and notes it's read-only and creates a cached result. It lacks explicit alternatives or when-not-to-use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description's 'Fetches data. Makes no changes' is redundant but confirming. The description adds valuable behavioral context by stating the segment ID type restriction and the timestamp format, which are not in annotations. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: four short lines including an emoji and endpoint. It is front-loaded with the core purpose ('Retrieve a Segment's Historic Definition'). Every line adds meaningful information without redundancy or fluff.
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 is read-only with no output schema, the description adequately explains the what (historic definition), when (at a timestamp), and constraints (segment ID type). It could be more complete by hinting at the return format, but the purpose and parameters are fully covered, making it effective for an AI agent.
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?
Input schema descriptions cover both parameters ('SegmentId' and 'UTC milliseconds from the epoch'), giving 100% coverage. The description adds extra value by showing the HTTP path pattern (reinforcing parameter names) and explicitly stating the SegmentId limitation (non-numeric). This exceeds the baseline 3 for high 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 the verb 'Retrieve' and the resource 'Segment's Historic Definition'. It also specifies the endpoint pattern and distinguishes this tool from the current segment retrieval (e.g., 'retrieve_a_segment' sibling) by noting that it retrieves a segment 'as it existed at a given point in time'. The constraint 'Only segments with non-numeric SegmentIds are supported' further clarifies scope.
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 implies when to use: when you need a historic snapshot of a segment at a specific timestamp. It also provides a clear usage constraint (non-numeric SegmentIds only). However, it does not explicitly name alternative tools (e.g., 'retrieve_a_segment' for current definition) or state when not to use it, which would elevate it to a 5.
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?
Annotations already mark destructiveHint: true. Description reinforces with '🔴 DESTRUCTIVE · deletes data' and user confirmation requirement, adding value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise, front-loaded with warning emoji and 'DESTRUCTIVE'. No wasted words, every sentence serves purpose.
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?
Simple tool with one parameter and no output schema. Description covers purpose, destructiveness, and user confirmation. Fully adequate for context.
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?
Single parameter 'id' with description 'The task id' in schema. Description does not add further meaning. Schema coverage 100% so baseline 3 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?
Clearly states 'Delete a task' and 'Deletes a record'. Distinct verb and resource, easily distinguishable from siblings like 'update_task' or '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?
Includes explicit instruction 'Confirm with the user before calling', guiding when to use. No alternatives given, but sufficient for a simple destructive action.
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?
The description adds significant behavioral details beyond annotations: irreversible process, immediate unavailability of associated data, potential delay, and that the field ID is not recycled. It also describes the expected HTTP response (202 Accepted). This goes well beyond the destructiveHint and idempotentHint annotations.
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 front-loaded with a warning emoji and 'DESTRUCTIVE' label, followed by the endpoint and concise behavioral details. Every sentence provides necessary information without redundancy. It is appropriately sized for the tool's complexity.
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 destructive and irreversible nature of the operation, the description covers the key aspects: irreversibility, immediate data unavailability, potential delay, and non-recycling of field IDs. It also references the `?showFields=all` parameter for programmatic use. No output schema exists, but the description explains the response status (202 Accepted), making it complete for the tool's 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?
Input schema has 100% description coverage, so the schema already documents parameters clearly. The description adds value by explaining the purpose of the `showFields` parameter (to show fields hidden after deletion) and its default behavior. This provides context 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 identifies the tool as deleting a field from a schema under Custom Objects, with a specific verb ('Delete a field') and resource. It distinguishes from sibling delete tools by specifying the context (field under schema) and including the HTTP endpoint.
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 confirm with the user before calling, which is a clear usage guideline. It also notes the irreversible nature and encourages use of the `?showFields=all` parameter. However, it does not explicitly differentiate when to use this tool versus other delete tools (e.g., delete_a_fieldvalue_1) or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

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

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