CDP MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
The tools are well-differentiated by resource type and action, with clear naming like 'cdp_create_campaign' and 'cdp_get_campaign'. However, some overlap exists in cache operations (e.g., 'cdp_cache_get_by_id' vs 'cdp_cache_get_by_key') and workflow actions (e.g., 'cdp_run_workflow' vs 'cdp_invoke_workflow_action'), which could cause minor confusion. Overall, the descriptions help clarify distinctions, but the sheer volume of tools increases the risk of misselection.
Naming Consistency5/5
Tool names follow a highly consistent pattern throughout: all start with 'cdp_' prefix, use snake_case, and follow a verb_noun structure (e.g., 'create_campaign', 'list_connectors', 'update_user'). There are no deviations in style or convention, making the naming predictable and easy to parse.
Tool Count2/5
With 293 tools, the count is extremely high and feels overwhelming for a single server. While CDP is a complex platform, this many tools suggests poor scoping and could lead to agent confusion. A more modular approach with multiple focused servers would be more appropriate, as this exceeds typical reasonable bounds (e.g., 3-15 tools for well-scoped servers).
Completeness5/5
The tool set provides comprehensive coverage of the CDP domain, including full CRUD operations for resources like campaigns, connectors, reports, and users, along with specialized actions (e.g., workflow execution, data export, audience calculation). There are no obvious gaps; the tools support the entire lifecycle and advanced functionalities, ensuring agents can handle complex workflows without dead ends.
Average 2.9/5 across 293 of 293 tools scored. Lowest: 1.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It fails to describe any behavioral traits—e.g., whether this is a read-only operation, if it requires authentication, rate limits, pagination behavior, or what happens if parameters are omitted. The description adds no context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise—a single sentence with the tool action and endpoint. It's front-loaded and wastes no words, though this brevity comes at the cost of clarity and completeness. It's structurally simple but under-specified.
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 complexity (a list operation with 3 parameters), no annotations, 0% schema coverage, and an output schema (which might help but isn't described), the description is incomplete. It doesn't explain what the tool returns, how to use parameters, or any behavioral aspects, making it inadequate for effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning parameters (tenant_id, offset, limit) are undocumented in the schema. The description does not add any meaning or explanation for these parameters—it doesn't clarify what 'tenant_id' refers to, how offset/limit work for pagination, or default behaviors. It 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.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List emailable pages (GET /v2/{tenantId}/emailablepages)' restates the tool name and includes the HTTP method and endpoint, but it's essentially tautological—it doesn't explain what 'emailable pages' are or what the tool actually does beyond listing them. It lacks specificity and doesn't differentiate from sibling tools like 'cdp_get_emailable_page' 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 Guidelines1/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. The description does not mention any context, prerequisites, or exclusions, such as how it relates to sibling tools like 'cdp_get_emailable_page' or when pagination via offset/limit is needed. It provides no usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but fails to disclose any behavioral traits. It does not indicate whether this is a destructive operation (implied by 'delete' but not confirmed), what permissions are required, if it's reversible, or what the output contains. This leaves critical safety and operational details unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single sentence with no wasted words. It is front-loaded with the core action, though this brevity comes at the cost of completeness. Every word earns its place, but the description is under-specified rather than optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a deletion operation with 2 parameters, 0% schema coverage, no annotations, but an output schema), the description is severely incomplete. It fails to address parameter meanings, behavioral implications, usage context, or output expectations, making it inadequate for safe and effective tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the tool description adds no information about parameters. It does not explain what 'validator_id' or 'tenant_id' represent, their formats, or how they affect the deletion. With two parameters (one required) and no schema descriptions, this is a significant gap.
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 'Delete a column validator' restates the tool name (cdp_delete_column_validator) with minimal elaboration, making it tautological. It specifies the verb ('delete') and resource ('column validator'), but lacks any distinguishing detail about scope, effects, or context that would differentiate it from similar deletion tools 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 Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, conditions, or sibling tools (e.g., cdp_get_column_validator, cdp_list_column_validators, cdp_create_column_validator, cdp_update_column_validator), leaving the agent with no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states the action 'Delete' without specifying if deletion is permanent, reversible, requires confirmation, affects dependencies (e.g., users assigned to the role), or has side effects like audit logging. This leaves critical behavioral aspects undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words, making it highly concise. It is front-loaded with the core action, though this brevity contributes to underspecification in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a destructive deletion operation with 2 parameters), lack of annotations, 0% schema description coverage, and presence of an output schema (which the description does not reference), the description is severely incomplete. It fails to address safety, parameters, outcomes, or integration with sibling tools, leaving the agent poorly informed.
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%, so the description must compensate by explaining parameters. It mentions 'by ID' but does not clarify the 'role_id' parameter's format, valid ranges, or the optional 'tenant_id' parameter's purpose (e.g., multi-tenancy context). No additional semantic meaning is provided beyond the schema's basic types.
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 'Delete a role by ID' restates the tool name 'cdp_delete_role' with minimal elaboration, making it tautological. It specifies the verb 'Delete' and resource 'role', but lacks detail on scope (e.g., permanent vs. soft deletion) or system context, and does not differentiate from sibling deletion tools like 'cdp_delete_user' or 'cdp_delete_schedule'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., 'cdp_update_role' for modification, 'cdp_list_roles' for viewing), prerequisites (e.g., role must exist, user permissions), or exclusions (e.g., cannot delete default roles). The description offers no contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action and endpoint, failing to describe whether this is a read-only operation, if it's safe to call, what authentication is required, how pagination works (implied by offset/limit parameters but not explained), or potential side effects. This leaves critical behavioral traits unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single sentence that includes the action and endpoint. There is no wasted verbiage, and it's front-loaded with the core purpose. However, this brevity comes at the cost of completeness, as noted in other dimensions.
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 (a list operation with pagination parameters), lack of annotations, 0% schema coverage, and the presence of an output schema (which might describe return values but isn't provided here), the description is inadequate. It fails to address key contextual elements like authentication needs, pagination behavior, error conditions, or how it fits among sibling tools, leaving significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the three parameters (tenant_id, offset, limit) have descriptions in the schema. The description adds no information about these parameters—it doesn't explain what tenant_id refers to, how offset and limit affect pagination, or their default behaviors. With zero coverage and no compensation in the description, parameter understanding is severely lacking.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List mailer identifiers' restates the tool name with minimal elaboration, making it tautological. It provides the HTTP endpoint 'GET /v2/{tenantId}/mailer/identifiers', which hints at a list operation but lacks specificity about what 'mailer identifiers' are or the scope of the listing. Compared to siblings like 'cdp_get_mailer_identifier' (singular) or 'cdp_list_mailer_accounts', it doesn't clearly differentiate 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 Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., authentication), when to prefer it over other list tools (e.g., 'cdp_list_mailer_accounts'), or any constraints like permissions or rate limits. Without such context, an agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the action ('List') and endpoint, without disclosing behavioral traits such as whether it's read-only, paginated (implied by offset/limit but not explained), rate-limited, or requires specific permissions. This leaves critical operational details unspecified.
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 core action and resource. However, it includes an endpoint path that may be redundant for tool selection, and the single sentence lacks structure for additional context, though it avoids unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a list operation with pagination parameters), no annotations, 0% schema coverage, and an output schema (which helps but isn't described), the description is incomplete. It doesn't explain the tool's behavior, parameters, or how it fits into the broader context of mailer batch management, making it inadequate for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so parameters are undocumented in the schema. The description adds no information about the three parameters (tenant_id, offset, limit), such as their purposes, formats, or constraints. It fails to compensate for the schema gap, leaving parameters entirely unexplained.
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 'List mailer batches (GET /v2/{tenantId}/mailer/batches)' states the action ('List') and resource ('mailer batches'), but it's vague about what 'mailer batches' are and doesn't differentiate from sibling tools like 'cdp_get_mailer_batch' (singular retrieval) or 'cdp_process_mailer_batch' (processing). It partially restates the name/title, making it tautological in parts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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. For example, it doesn't mention whether this is for bulk listing versus specific retrieval (e.g., 'cdp_get_mailer_batch'), or how it relates to other mailer tools like 'cdp_create_mailer_batch'. The description lacks any context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Delete' which implies a destructive mutation, but doesn't specify whether this action is reversible, requires specific permissions, has side effects (e.g., cascading deletions), or includes confirmation prompts. For a deletion tool with zero annotation coverage, this is a significant gap in safety and operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action ('Delete'), making it immediately clear, though this brevity contributes to the lack of detail in other dimensions.
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 a deletion tool with no annotations, 0% schema description coverage, and an output schema (which might provide some return value context), the description is incomplete. It doesn't address behavioral risks, parameter meanings, or usage context, making it inadequate for safe and effective tool invocation by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning parameters 'bucket_id' and 'tenant_id' are undocumented in the schema. The description adds no parameter information beyond what's implied by the tool name—it doesn't explain what a bucket_id is, how to obtain it, or when tenant_id is required. With two parameters and no schema descriptions, the description fails to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete an execution bucket' restates the tool name (cdp_delete_execution_bucket) almost verbatim, making it tautological. It specifies the verb ('Delete') and resource ('execution bucket'), but lacks differentiation from sibling tools like cdp_delete_execution_summary_group or other deletion tools, and doesn't clarify what an 'execution bucket' 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 Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., whether the bucket must be empty or inactive), exclusions, or related tools like cdp_list_execution_buckets for selection or cdp_update_execution_bucket for modifications, leaving the agent with no contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the action 'delete' without disclosing behavioral traits like permissions required, irreversibility, side effects, or error handling. It fails to address critical aspects such as whether deletion is permanent, requires specific tenant context, or impacts 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with zero wasted words, making it highly concise and front-loaded. However, this brevity contributes to under-specification rather than effective communication.
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 destructive tool with 2 parameters, 0% schema coverage, no annotations, and an output schema (unseen), the description is inadequate. It lacks essential context on behavior, parameters, and usage, failing to compensate for the missing structured data, though the output schema may mitigate some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter information. It does not explain 'template_id' (e.g., what identifies a mapping template) or 'tenant_id' (e.g., optional tenant context), leaving both parameters undocumented beyond their schema types.
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 'Delete a mapping template' restates the tool name with minimal elaboration, making it tautological. It specifies the verb 'delete' and resource 'mapping template', but lacks detail on what a mapping template is or the scope of deletion, and does not differentiate from sibling tools like 'cdp_delete_mapping_template' vs. 'cdp_delete_audience_def' or 'cdp_delete_campaign'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, prerequisites, or exclusions. It does not mention sibling tools like 'cdp_list_mapping_templates' for selection or 'cdp_update_mapping_template' for modifications, leaving usage context entirely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It doesn't disclose any behavioral traits: whether it's read-only, requires authentication, has rate limits, returns paginated results, or what happens on errors. The description is too minimal to inform the agent about operational behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded and directly states the tool's purpose without unnecessary elaboration, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters with 0% schema coverage, no annotations, and an output schema exists, the description is incomplete. It doesn't compensate for the lack of parameter documentation or provide any context on behavior, leaving the agent with insufficient information to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter details. The description adds no meaning beyond the tool name—it doesn't explain what 'tenant_id' or 'payload' are, their formats, or how they affect the retrieval. With 2 undocumented parameters, this is inadequate.
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 'Get web personalization templates for a tenant' clearly states the action ('Get') and resource ('web personalization templates'), but it's vague about scope (e.g., all templates or filtered) and doesn't distinguish from sibling tools like cdp_get_campaign or cdp_get_widget, which also retrieve resources. It's functional but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites, such as needing a tenant context, or compare it to other 'get' tools in the list. The agent must 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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description offers no behavioral information beyond the basic action. It doesn't disclose whether this is a read-only operation, if it requires authentication, what the output format is (though an output schema exists), or any rate limits or side effects. For a tool with zero annotation coverage, this is a critical gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded and directly states the tool's purpose, making it easy to parse quickly. Every word earns its place, though the brevity contributes to the lack of detail in other dimensions.
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 implied by the sibling tools (e.g., many involve data operations), the description is inadequate. No annotations exist, and while an output schema is present, the description doesn't explain what 'execution buckets' are, their purpose, or the context of use. For a tool in a rich ecosystem, this leaves significant gaps for an agent to understand its role.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, and the description provides no information about the 'tenant_id' parameter. It doesn't explain what a tenant is, whether the parameter is optional (default is null), or how to obtain valid tenant IDs. With one undocumented parameter and no compensation in the description, this fails to add value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List execution buckets for a tenant' clearly states the verb ('List') and resource ('execution buckets'), but it's vague about what 'execution buckets' are and lacks specificity compared to siblings like 'cdp_get_execution_summary_group' or 'cdp_list_execution_summary_groups'. It doesn't distinguish itself from other list tools in the sibling set 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 is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, exclusions, or related tools like 'cdp_get_execution_summary_group' or 'cdp_list_execution_summary_groups'. The agent must infer usage from the name alone, which is insufficient for informed tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It fails to describe any behavioral traits: it doesn't indicate if this is a read-only operation (implied by 'List' but not explicit), whether it requires specific permissions, if it supports pagination (though parameters suggest it), rate limits, or what the output contains. This leaves critical gaps for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core purpose, making it easy to scan. However, this conciseness comes at the cost of completeness, as it lacks necessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, no annotations, 0% schema coverage, but with an output schema), the description is incomplete. It doesn't address parameter meanings, behavioral aspects like safety or permissions, or when to use it. The output schema may cover return values, but the description fails to provide enough context for effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning parameters (tenant_id, offset, limit) are undocumented in the schema. The description adds no parameter semantics—it doesn't explain what tenant_id refers to, how offset/limit work for pagination, or default behaviors. With 3 parameters and no schema descriptions, the description fails to compensate, leaving parameters ambiguous.
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 'List workflows for a tenant' clearly states the action ('List') and resource ('workflows'), but it's vague about scope and lacks sibling differentiation. It doesn't specify if this lists all workflows, active workflows, or something else, and among many sibling 'list_' tools (e.g., cdp_list_audience_defs, cdp_list_campaigns), it doesn't distinguish itself beyond 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 doesn't mention prerequisites (e.g., authentication), when it's appropriate (e.g., for browsing vs. filtering), or refer to other tools like cdp_get_workflow for detailed views. Usage is implied only by the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states 'Create a new connector definition' without disclosing any behavioral traits: no information about permissions required, whether this is a mutating operation (implied but not confirmed), rate limits, idempotency, or what happens on success/failure. This is inadequate for a creation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise with two sentences that directly address the core action and parameter format. No wasted words, though this brevity contributes to the lack of detail in other dimensions.
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 a creation tool with 2 parameters (0% schema coverage), no annotations, and an output schema (which helps but doesn't excuse the description), the description is incomplete. It fails to explain parameter semantics adequately, provides no behavioral context, and offers no usage guidance, making it insufficient for reliable tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'Pass definition as a JSON string' which partially explains the 'body' parameter, but doesn't clarify the JSON structure or purpose. The 'tenant_id' parameter is completely undocumented in both schema and description. The description adds minimal value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb ('Create') and resource ('connector definition'), but is vague about what a 'connector definition' entails. It distinguishes from siblings like 'cdp_create_connector' by specifying 'template', but doesn't clarify the difference between a connector and a connector template, leaving purpose somewhat ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'cdp_create_connector' or 'cdp_create_mapping_template'. The description provides no context about prerequisites, typical use cases, or exclusions, leaving the agent with no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Create' implies a write/mutation operation, the description doesn't mention permissions required, whether this is idempotent, what happens on failure, rate limits, or what the output contains. The JSON configuration requirement is mentioned but without context about what configuration options 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 appropriately brief with two clear sentences. The first states the action, the second provides parameter guidance. There's no unnecessary verbosity, though it could benefit from being more informative while maintaining 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?
For a creation tool with 2 parameters (one required), 0% schema coverage, no annotations, and sibling tools that suggest this is part of a larger system, the description is inadequate. While an output schema exists, the description doesn't provide enough context about what an 'execution summary group' is, what configuration it accepts, or how it fits into the broader CDP ecosystem.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for 2 parameters, the description only partially compensates. It mentions that 'configuration' should be passed as a JSON string (mapping to 'body'), but provides no details about what configuration options exist or their format. The 'tenant_id' parameter is completely undocumented in both schema and description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('Create a new execution summary group') which is a clear verb+resource combination. However, it doesn't explain what an 'execution summary group' is or how it differs from sibling tools like 'cdp_create_execution_bucket' or 'cdp_list_execution_summary_groups', leaving the purpose somewhat vague for someone unfamiliar with the system.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, when this creation operation is appropriate, or how it relates to similar tools like 'cdp_update_execution_summary_group' or 'cdp_delete_execution_summary_group'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It indicates a creation action (implying mutation) but doesn't disclose behavioral traits like required permissions, side effects, rate limits, or what happens on success/failure. The mention of 'POST /v2/{tenantId}/mailer/batches' hints at an HTTP method but lacks operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the core action. It wastes no words, though it could be more informative. The single sentence efficiently states the tool's basic function and parameter format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters with 0% schema coverage, no annotations, and an output schema (which helps but isn't described), the description is incomplete. It lacks details on parameter semantics, behavioral context, and usage guidelines, making it inadequate for a mutation tool in a complex system.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions passing 'the definition as a JSON string' for the 'body' parameter, which adds some meaning, but doesn't explain the structure or content of that JSON or the purpose of 'tenant_id'. With 2 parameters and low schema coverage, this is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb ('Create') and resource ('a mailer batch'), which clarifies the basic purpose. However, it doesn't specify what a 'mailer batch' is or how it differs from sibling tools like 'cdp_process_mailer_batch' or 'cdp_update_mailer_batch', leaving the purpose somewhat 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 is provided on when to use this tool versus alternatives. The description mentions the API endpoint but doesn't explain prerequisites, dependencies, or scenarios where this tool is appropriate compared to other mailer-related 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the action ('Delete') without disclosing critical behavioral traits such as whether deletion is permanent, requires specific permissions, has side effects (e.g., data loss), or involves confirmation steps. This is inadequate for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence ('Delete a connector'), which is front-loaded and wastes no words. However, this brevity comes at the cost of completeness, but for conciseness alone, it scores perfectly.
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 (a destructive delete operation with 2 parameters), lack of annotations, 0% schema coverage, and presence of an output schema (which might help but isn't described), the description is incomplete. It should cover behavioral risks, parameter meanings, and usage context to be adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no parameter information beyond what's inferred from the tool name. It doesn't explain what 'connector_id' or 'tenant_id' represent, their formats, or usage context, failing 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a connector' clearly states the verb ('Delete') and resource ('connector'), but it's vague about what a 'connector' is in this context and doesn't differentiate from sibling tools like 'cdp_delete_connector_template' or 'cdp_delete_output_connector'. It's better than a tautology but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'cdp_delete_connector_template' or 'cdp_delete_output_connector', nor does it mention prerequisites, exclusions, or context for deletion. This leaves the agent with no 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?
No annotations are provided, so the description carries the full burden. It indicates this tool triggers a calculation workflow, implying it may initiate a background process or have side effects, but it lacks details on permissions required, rate limits, whether it's idempotent, or what the output entails. This is insufficient for a tool that likely performs a significant operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and to the point with two concise sentences that directly state the tool's action. It is front-loaded with the core purpose, though it could be more structured by including parameter or usage details without sacrificing 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?
Given no annotations, 0% schema coverage, and two parameters, the description is incomplete. It does not explain parameters, behavioral traits, or when to use it, and while an output schema exists, the description provides no context on what the execution entails or expected outcomes, making it inadequate for informed tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does not mention any parameters or their meanings (e.g., what 'audience_def_id' or 'tenant_id' represent). The description fails to add semantic context beyond the bare schema, leaving parameters undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'Execute/calculate an audience definition' and 'Triggers the audience calculation workflow', which clarifies the verb (execute/calculate) and resource (audience definition). However, it does not distinguish this from sibling tools like 'cdp_calculate_audience' or 'cdp_get_audience_count', leaving ambiguity about when to use this specific tool versus 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 explicit guidance is provided on when to use this tool versus alternatives like 'cdp_calculate_audience' or 'cdp_get_audience_count'. The description mentions triggering a workflow but does not specify prerequisites, exclusions, or contextual cues for selection among similar tools in the server.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states it 'gets' a summary view, implying a read operation, but doesn't disclose critical traits like authentication requirements, rate limits, pagination behavior (hinted by offset/limit parameters), error conditions, or whether it's idempotent. For a read tool with 5 parameters and no annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose with an example. It's appropriately sized and front-loaded, with no redundant information. However, it could be more structured by explicitly separating purpose from parameter guidance.
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 (5 parameters, 1 required), no annotations, 0% schema coverage, and an output schema (which reduces need to describe returns), the description is incomplete. It doesn't adequately explain parameters, behavioral traits, or usage context. For a tool with multiple parameters and no annotation support, more detail is needed to guide the agent effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but fails to do so. It mentions 'resource type' and provides an example ('list of customer profiles'), which loosely relates to the 'resource_name' parameter, but doesn't explain the meaning or usage of any parameters (resource_name, tenant_id, offset, limit, fq). With 5 parameters undocumented in both schema and description, the agent lacks essential semantic context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'Get Customer 360 summary view for a resource type (e.g., list of customer profiles)', which clarifies it retrieves a summary view for a specified resource type. However, it's vague about what a 'Customer 360 summary view' entails and doesn't explicitly distinguish it from sibling tools like 'cdp_get_customer_360_detail' or 'cdp_get_customer_360_realtime', leaving room for 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 guidance is provided on when to use this tool versus alternatives. The description mentions an example ('list of customer profiles') but doesn't specify use cases, prerequisites, or exclusions. Without explicit when/when-not instructions or named alternatives, the agent lacks context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions fetching via a GET endpoint, implying a read-only operation, but doesn't cover critical aspects like authentication requirements, rate limits, pagination, error handling, or what 'connector links' entail. This leaves significant gaps for safe and effective tool invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('Fetch connector links') and includes the API endpoint. There's no wasted text, though it could benefit from slightly more detail to improve clarity without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 parameters with 0% schema coverage, no annotations, and an output schema (which helps but isn't described), the description is incomplete. It lacks details on parameter meanings, behavioral traits, and usage context, making it inadequate for a tool with multiple inputs and potential complexity in a CDP environment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter details. The description only mentions 'connectorClass' in the URL example, adding minimal context for the 'connector_class' parameter and none for 'tenant_id'. It fails to explain what connector classes are, valid values, or how tenant_id affects the query, leaving parameters largely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool fetches connector links filtered by connector class, which is a clear verb+resource combination. However, it doesn't distinguish itself from sibling tools like 'cdp_list_connector_links' (which likely lists all links without filtering) or other list tools, making it somewhat vague about 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 explicit guidance on when to use this tool versus alternatives is provided. The description mentions filtering by connector class but doesn't specify scenarios or prerequisites, leaving the agent to infer usage based on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool lists items, implying a read-only operation, but fails to disclose behavioral traits like pagination handling (via offset/limit parameters), authentication needs, rate limits, or error conditions. This is a significant gap for a tool with parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste—'List available connector definitions (templates)'—front-loading the core action and resource. It is appropriately sized for a simple list operation, though brevity contributes to gaps in other dimensions.
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 low complexity (a list operation) but lack of annotations, 0% schema coverage, and presence of an output schema, the description is incomplete. It does not explain parameter usage, behavioral context, or how the output might be structured, leaving the agent under-informed despite the output schema potentially covering return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning parameters (tenant_id, offset, limit) are undocumented in the schema. The description adds no information about these parameters, such as their purposes (e.g., filtering by tenant, pagination controls), expected formats, or default behaviors, failing to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List available connector definitions (templates)' clearly states the verb ('List') and resource ('connector definitions/templates'), making the purpose understandable. However, it does not differentiate from sibling tools like 'cdp_list_connectors' or 'cdp_get_connector_template', which might list active connectors or fetch a specific template, leaving the scope vague relative to 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?
The description provides no guidance on when to use this tool versus alternatives. It lacks context such as prerequisites, typical use cases, or comparisons to siblings like 'cdp_list_connectors' or 'cdp_get_connector_template', leaving the agent without direction on selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'List', implying a read-only operation, but does not clarify if it's paginated (though parameters suggest it might be), what authentication is required, rate limits, or the format of returned data. The description lacks critical behavioral details for a tool with parameters and an output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It is front-loaded with the core action and resource, making it easy to scan. Every word earns its place, achieving optimal conciseness for the given content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (3 parameters, 0% schema coverage, no annotations, but with an output schema), the description is insufficient. It does not explain parameter usage, behavioral traits, or how it differs from siblings. While the output schema may cover return values, the description fails to provide necessary context for effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, meaning parameters (tenant_id, offset, limit) are undocumented in the schema. The description adds no information about these parameters—it does not explain what tenant_id refers to, how offset and limit work for pagination, or default behaviors. With low coverage and no compensation in the description, this is inadequate.
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 'List DQE Phase 2 data quality rules' clearly states the verb ('List') and resource ('DQE Phase 2 data quality rules'), providing a basic purpose. However, it does not differentiate this tool from its sibling 'cdp_list_dqe1_rules' (which lists Phase 1 rules), leaving ambiguity about when to use each. The purpose is clear but lacks 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. It does not mention sibling tools like 'cdp_list_dqe1_rules' or 'cdp_get_dqe2_rule', nor does it specify prerequisites, contexts, or exclusions. Usage is implied only by the tool name, with no explicit instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'Supports filtering via fq parameter', which adds some behavioral context, but fails to disclose critical traits like whether this is a read-only operation, pagination behavior (implied by offset/limit but not explained), rate limits, authentication needs, or error handling. For a query tool with 7 parameters, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the core purpose and includes an additional clause about filtering. It's efficient with no wasted words, though it could be more structured by explicitly listing key parameters.
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 (7 parameters, 0% schema coverage, no annotations) and the presence of an output schema, the description is incomplete. It doesn't explain parameter roles, usage scenarios, or behavioral expectations, leaving significant gaps for a tool that queries entities from a data warehouse.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only mentions the 'fq' parameter for filtering, ignoring the other 6 parameters (resource_name, tenant_id, offset, limit, sort, include). This leaves most parameters undocumented, failing to add meaningful semantics beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'Query entities from a CDP data warehouse resource' with examples like 'customer, organization, transaction', which clarifies the verb and resource. However, it doesn't differentiate from many sibling list tools (e.g., cdp_list_campaigns, cdp_list_users) beyond mentioning 'entities' and 'CDP data warehouse resource', leaving the scope somewhat vague compared to 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?
The description provides no guidance on when to use this tool versus other list tools (e.g., cdp_list_campaigns for campaigns, cdp_list_users for users). It mentions filtering via 'fq parameter' but doesn't explain when this is appropriate or what alternatives exist, offering minimal usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action ('List') and API endpoint, lacking critical details like whether this is a read-only operation, if it requires specific permissions, rate limits, pagination behavior, or error handling. The description fails to add meaningful context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single sentence that directly states the tool's action and API endpoint. It's front-loaded with the core purpose and wastes no words, though this brevity contributes to gaps in other dimensions.
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 an output schema (which helps), but no annotations and 0% schema description coverage for three parameters, the description is insufficient. It doesn't compensate for the lack of parameter documentation or provide behavioral context needed for a list operation (e.g., pagination, sorting, or response format hints). The description is too minimal for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the three parameters (tenant_id, offset, limit) are documented in the schema. The description adds no information about these parameters—it doesn't explain what 'tenant_id' refers to, how 'offset' and 'limit' work for pagination, or their default values. This leaves parameters completely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('mailer accounts'), making the purpose specific and understandable. It distinguishes from siblings like 'cdp_get_mailer_account' (singular retrieval) and 'cdp_create_mailer_account' (creation), though it doesn't explicitly mention this differentiation in the text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., authentication), when to use it over other list tools (e.g., 'cdp_list_mailer_batches'), or any constraints like pagination defaults. Usage is implied by the name but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states what the tool does ('List UDMP tables') without any behavioral context: no indication of whether this is a read-only operation, what permissions are required, whether it supports pagination (though parameters suggest it might), what format the output takes, or any rate limits 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 a single, efficient sentence that states the core purpose without any wasted words. It's appropriately sized for a basic list operation and front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While an output schema exists (which helps), the description is inadequate given the context: no annotations, 3 undocumented parameters with 0% schema coverage, and multiple similar list operations among siblings. For a tool with parameters and no annotation safety net, the description should provide more guidance about parameter usage and behavioral characteristics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the three parameters (tenant_id, offset, limit) have descriptions in the schema. The tool description provides absolutely no information about parameters - it doesn't mention any of them, their purposes, or how they affect the listing operation. This fails to compensate for the complete lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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') and the resource ('UDMP tables'), providing a specific verb+resource combination. It distinguishes the resource type (UDMP tables) from other listable resources in the sibling tools, though it doesn't explicitly differentiate from similar list operations like 'cdp_list_udmp_resources'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are many other list tools in the sibling set (e.g., cdp_list_udmp_resources, cdp_list_tables), but no indication of when this specific UDMP table listing is appropriate or what distinguishes it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool sends an email, implying a write operation, but does not disclose behavioral traits such as required permissions, rate limits, side effects (e.g., whether emails are queued or sent immediately), or error handling. This leaves significant gaps for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences that directly address the tool's function and parameter usage. It is front-loaded with the main purpose and avoids unnecessary details, though it could be slightly more structured by explicitly listing parameters.
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 a mutation tool with 3 parameters, 0% schema coverage, no annotations, and an output schema (which reduces need for return value explanation), the description is incomplete. It partially explains parameters but misses behavioral context and full parameter semantics, making it inadequate for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds some meaning by explaining email_type with examples (support, alert, notification) and specifying that email details should be passed as a JSON string, which clarifies the body parameter. However, it does not explain the tenant_id parameter or provide details on JSON structure, leaving gaps for 3 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose as 'Send an email of a specific type', which is clear but vague. It specifies the verb ('Send') and resource ('email'), but lacks detail on what 'email of a specific type' entails beyond examples (support, alert, notification). It does not distinguish from sibling tools, as no other email-related tools are listed 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 is provided. The description mentions email_type examples but does not specify contexts, prerequisites, or exclusions. It lacks any mention of when-not-to-use scenarios or how it differs from other tools in the system.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It indicates this is a mutation operation ('update'), but doesn't specify required permissions, whether changes are reversible, rate limits, or what happens to existing fields not mentioned. The JSON string format hint is useful but insufficient for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - just one sentence with no wasted words. It's front-loaded with the core action and includes the critical JSON format requirement. While perhaps too brief for a mutation tool, every word earns its place by providing essential information about the operation and parameter format.
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 3 parameters, 0% schema description coverage, no annotations, but with an output schema, the description is inadequate. It covers the JSON format for the body parameter but leaves bucket_id and tenant_id unexplained. The output schema existence helps with return values, but the description should do more to explain the mutation's behavior and parameter meanings given the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'updated fields as a JSON string' which clarifies the 'body' parameter's purpose and format, adding value beyond the schema. However, it doesn't explain 'bucket_id' (what identifies the bucket) or 'tenant_id' (when it's needed), leaving two of three parameters inadequately documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool updates an execution bucket, which is a clear verb+resource combination. However, it doesn't specify what an 'execution bucket' is or what fields can be updated, making it somewhat vague. It distinguishes from siblings like 'cdp_create_execution_bucket' and 'cdp_delete_execution_bucket' by the update action, but lacks specificity about the resource 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 alternatives. It doesn't mention prerequisites, when not to use it, or how it differs from similar update tools like 'cdp_update_execution_summary_group'. The only usage hint is the JSON string format, but this is parameter guidance rather than contextual usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. 'Update' implies mutation, but the description doesn't state whether this requires specific permissions, whether changes are reversible, what happens on success/failure, or any rate limits. The JSON string requirement is helpful but insufficient for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - just one sentence with no wasted words. It's front-loaded with the core action. However, this conciseness comes at the cost of completeness, making it more under-specified than optimally 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?
For a mutation tool with 3 parameters, 0% schema coverage, no annotations, and an output schema (which the description doesn't reference), this description is inadequate. It doesn't explain what an execution summary group is, what fields can be updated, what the JSON format should be, or what the tool returns. The presence of an output schema reduces but doesn't eliminate the need for more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 3 parameters, the description adds minimal value. It mentions 'updated fields as a JSON string' which partially explains the 'body' parameter, but doesn't clarify what fields are updatable, the JSON structure, or the purpose of 'group_id' and 'tenant_id'. The description fails to compensate for the complete lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool updates an execution summary group, which is a clear verb+resource combination. However, it doesn't distinguish this from other update tools in the sibling list (like cdp_update_execution_bucket or cdp_update_audience_def), nor does it specify what an 'execution summary group' actually is. The purpose is understandable but lacks differentiation and domain context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, when this update is appropriate, or what happens if the group doesn't exist. With many sibling tools including cdp_get_execution_summary_group and cdp_delete_execution_summary_group, the lack of usage 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Modify' implies a mutation operation, but the description doesn't specify what permissions are required, whether changes are reversible, what validation occurs, or what happens to the instance during update. The mention of JSON string format is helpful but insufficient for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences that each serve a purpose - the first states the action, the second provides technical implementation detail. It's front-loaded with the core purpose. However, the technical endpoint reference could be considered extraneous for an AI agent's decision-making.
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 3 parameters (0% schema coverage), no annotations, and complex sibling context (200+ tools), the description is inadequate. While an output schema exists (which helps), the description doesn't explain what constitutes a 'provisioned instance' in this system, what fields are modifiable, or what the typical update scenarios are. Given the complexity, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for all 3 parameters, the description must compensate but fails to do so adequately. It mentions 'Pass update body as JSON string' which partially explains the 'body' parameter, but doesn't clarify what fields the JSON should contain, what 'instance_id' refers to, or when 'tenant_id' is required. The description adds minimal value beyond what's implied by parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'Modify a provisioned instance' which provides a clear verb+resource combination. However, it doesn't distinguish this from sibling tools like 'cdp_update_campaign' or 'cdp_update_user' - it's just another generic 'update' operation in a large family of update tools. The description is vague about what specific aspects of a provisioned instance can be modified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With 200+ sibling tools including many other update operations, there's no indication of when this specific provision instance update is appropriate versus other update tools or versus creation/deletion operations. The mention of 'PUT /provisions/instances/{id}' is technical implementation detail, not usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'update' implying mutation, but fails to disclose behavioral traits like required permissions, whether changes are reversible, rate limits, or response format. This is a significant gap for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's appropriately sized for a simple update tool, though it could be more informative without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a mutation tool with 3 parameters, 0% schema coverage, no annotations, and an output schema (which helps but isn't described), the description is incomplete. It lacks details on updatable fields, behavioral context, and parameter meanings, making it inadequate for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only mentions 'updated fields as a JSON string' for the 'body' parameter, but doesn't explain what fields are updatable, the JSON structure, or the purpose of 'user_id' and 'tenant_id'. This leaves most parameter semantics unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('Update') and resource ('self-service user'), but it's vague about what fields can be updated or what constitutes a self-service user. It doesn't distinguish from sibling tools like 'cdp_update_user' or 'cdp_update_selfservice_user_status', leaving ambiguity about 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 (e.g., 'cdp_update_user' or 'cdp_update_selfservice_user_status'), nor any prerequisites or context for usage. The description only states what the tool does, not when to apply it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It fails to describe any behavioral traits: it doesn't indicate whether this is a mutating operation (implied by 'Create' but not explicit), what permissions are required, whether it's idempotent, what happens on failure, or what the output contains. The description is minimal and adds no behavioral context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with only one sentence, front-loading the core action. There is no wasted verbiage or redundancy. It efficiently states what the tool does and the parameter format, though this brevity comes at the cost of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (creation operation with 2 parameters, 0% schema coverage, no annotations), the description is inadequate. It lacks details on behavioral impact, parameter semantics, error handling, and output expectations. While an output schema exists, the description doesn't provide enough context for an agent to use the tool effectively without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions that 'validator' should be passed as a JSON string, which loosely maps to the 'body' parameter, but doesn't explain what a 'validator' entails, its structure, or examples. It ignores the 'tenant_id' parameter entirely. The description adds minimal value over the bare schema, failing to clarify parameter meanings or requirements.
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') and resource ('new column validator'), making the purpose understandable. It distinguishes from siblings like 'cdp_update_column_validator' and 'cdp_delete_column_validator' by specifying creation. However, it lacks specificity about what a 'column validator' is in this context, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, dependencies, or when to choose this over other validator-related tools like 'cdp_update_column_validator' or 'cdp_get_column_validator'. The only usage hint is the parameter format ('JSON string'), which is insufficient for contextual decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It indicates this is a creation operation (implying mutation) but doesn't mention authentication needs, rate limits, whether the operation is idempotent, what happens on conflicts, or what the output contains. The JSON format hint is minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with two sentences that directly state the tool's function and a key parameter requirement. It's front-loaded and wastes no words, though it could benefit from slightly more detail given the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters with 0% schema coverage, no annotations, and an output schema (which helps), the description is minimally adequate. It covers the core action and one parameter's format but lacks details on other parameters, behavioral traits, and usage context, making it incomplete for safe operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only mentions that 'body' should be 'entity data as a JSON string,' which adds some meaning for one parameter. However, it doesn't explain 'resource_name' or 'tenant_id' (including its optional nature and purpose), leaving two parameters largely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('Create a new entity') and target ('in a DW resource'), which clarifies the basic purpose. However, it doesn't specify what an 'entity' means in this context or differentiate from similar creation tools like cdp_create_audience_def or cdp_create_campaign, leaving the scope somewhat 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 is provided on when to use this tool versus alternatives. The description mentions passing entity data as JSON, but doesn't specify prerequisites, when this is appropriate compared to other creation tools, or any constraints like required permissions or system states.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is a creation tool (implying a write/mutation operation) and mentions the HTTP method (POST), but fails to describe authentication requirements, rate limits, error conditions, or what happens on success. For a mutation tool with zero annotation coverage, this is a significant gap in behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the core purpose. The single sentence efficiently conveys what the tool does and includes the API endpoint, though it could be more structured by separating the action from implementation details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 2 parameters (0% schema coverage), no annotations, and an output schema (which helps but doesn't compensate for input gaps), the description is inadequate. It doesn't explain parameter semantics, behavioral traits, or usage context, leaving the agent poorly equipped to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning neither parameter has any documentation in the schema. The description only mentions passing 'the definition as a JSON string' for the 'body' parameter, but doesn't explain what that definition should contain, its structure, or the purpose of the 'tenant_id' parameter. This leaves both parameters essentially undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a mailer subuser') and the resource ('mailer subuser'), which is specific and unambiguous. However, it doesn't differentiate from sibling tools like 'cdp_create_mailer_account' or 'cdp_create_user', leaving some ambiguity about when to use this specific creation 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context, or compare it to sibling tools like 'cdp_create_mailer_account' or 'cdp_create_user', leaving the agent to guess based on naming alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions that configuration is passed as a JSON string, which hints at input format, but fails to disclose critical behavioral traits: whether this is a mutating operation (likely yes, given 'create'), what permissions are required, if there are rate limits, what happens on success/failure, or any side effects. For a creation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two short sentences that are front-loaded with the core action. There is zero wasted verbiage, making it easy to parse quickly, though this conciseness comes at the cost of detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a creation tool likely involving configuration and tenant context), no annotations, 0% schema coverage, and two parameters, the description is incomplete. While an output schema exists (which might cover return values), the description lacks essential context: what an output connector is, typical configuration, error handling, or links to related tools. It's inadequate for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions that 'body' should be a 'JSON string' for configuration, which adds some meaning beyond the schema's generic 'string' type. However, it doesn't explain what the JSON structure should contain, what 'tenant_id' is for, or provide examples. With two parameters (one required) and low schema coverage, this is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('Create a new output connector') which is clear, but it's vague about what an 'output connector' is or what it does. It doesn't distinguish this from similar sibling tools like 'cdp_create_connector' or 'cdp_create_output_connector_def', leaving ambiguity about the specific resource being created.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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. With many sibling tools like 'cdp_create_connector' and 'cdp_create_output_connector_def', the description offers no context about prerequisites, typical use cases, or exclusions, leaving the agent to guess based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It states the tool triggers a workflow action, implying a mutation, but doesn't disclose whether this is reversible, what permissions are required, if it affects running workflows, or what the output contains. The mention of 'workflow controller' adds some context but lacks operational details like side effects or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the core purpose. Both sentences are relevant: the first states what the tool does, and the second adds context about the workflow controller. There's no wasted verbiage, though it could be more informative given the complexity.
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 a mutation tool with 3 parameters (2 required), 0% schema coverage, no annotations, and an output schema (which isn't described), the description is inadequate. It doesn't explain parameter meanings, behavioral implications, or usage context. While the output schema might cover return values, the description fails to address the tool's operational aspects and parameter semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the three parameters (workflow_id, schedule_id, tenant_id) have descriptions in the schema. The tool description provides no information about these parameters—what they represent, format expectations, or how they relate to each other. This leaves all parameters completely undocumented beyond their names and types.
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 ('deactivate') and resource ('a schedule'), specifying that it triggers the schedule's workflow action via the workflow controller. It distinguishes from siblings like cdp_activate_schedule by indicating opposite action, though it doesn't explicitly contrast with other schedule-related tools like cdp_get_schedule or cdp_update_schedule.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, when deactivation is appropriate, or what happens after deactivation. It doesn't reference the sibling cdp_activate_schedule for reactivation scenarios or other schedule management tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. 'Delete' implies a destructive mutation, but the description doesn't disclose any behavioral traits: no mention of permissions required, whether deletion is permanent or reversible, rate limits, side effects, or what happens to associated data. For a destructive operation with zero annotation coverage, this is a significant gap in safety and operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just four words, with zero wasted language. It's front-loaded with the core action ('Delete') and resource. While it lacks detail, every word earns its place by stating the essential operation.
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 this is a destructive mutation tool with no annotations, 0% schema description coverage, 2 parameters, and an output schema (which helps but isn't described), the description is incomplete. It doesn't provide enough context for safe and correct usage—missing behavioral warnings, parameter explanations, and differentiation from siblings. The output schema existence slightly mitigates but doesn't compensate for the other gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The tool description adds no information about the two parameters (group_id and tenant_id). It doesn't explain what a 'group_id' is, how to obtain it, what format it expects, or the purpose of the optional 'tenant_id'. The description 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete an execution summary group' clearly states the verb (delete) and resource (execution summary group), which is better than a tautology. However, it doesn't differentiate this tool from other delete operations in the sibling list (like cdp_delete_campaign, cdp_delete_dashboard, etc.) beyond specifying the resource type. It's vague about what an 'execution summary group' actually 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites (e.g., needing an existing group), consequences (e.g., data loss), or when to choose this over other deletion tools in the sibling list. The agent must infer usage purely from the name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the action without behavioral details. It doesn't disclose whether deletion is permanent, reversible, requires specific permissions, affects dependent resources, or has side effects. For a destructive operation, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just three words, front-loading the essential action and resource. There's zero wasted language, making it easy to parse quickly despite its informational shortcomings.
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 destructive operation with 2 parameters (0% schema coverage) and no annotations, the description is inadequate. While an output schema exists, the description doesn't provide necessary context about the deletion's impact, parameter usage, or alternatives. It leaves too many questions unanswered for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The tool description adds no information about the two parameters (connector_id, tenant_id), their meaning, format, or how they relate to the deletion operation. It fails to compensate for the complete lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete an output connector' clearly states the action (delete) and resource (output connector), but it's vague about scope and doesn't distinguish from siblings like 'cdp_delete_connector' or 'cdp_delete_output_connector_def'. It lacks specificity about what an 'output connector' 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 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 'cdp_delete_connector' or 'cdp_delete_output_connector_def'. The description provides no context about prerequisites, dependencies, or typical use cases for deleting an output connector.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action is a deletion, implying it's destructive, but doesn't mention critical details like whether the deletion is permanent, requires specific permissions, has side effects (e.g., affecting associated connectors), or what happens on success/failure. This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words, making it highly concise and front-loaded. Every part of the sentence directly contributes to stating the tool's purpose efficiently.
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 is a deletion operation (complex mutation) with no annotations, 0% schema description coverage, and an output schema (which might help but isn't described), the description is incomplete. It lacks necessary context like behavioral risks, parameter meanings, and usage scenarios, making it inadequate for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description adds no information about the parameters (connector_def_id and tenant_id), such as what they represent, where to find them, or how tenant_id affects the operation (e.g., defaulting to null). 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb ('Delete') and resource ('an output connector definition'), which clarifies the basic action. However, it doesn't specify what an 'output connector definition' is or how it differs from similar tools like 'cdp_delete_output_connector' (which deletes the connector itself rather than its definition), making it somewhat vague compared to 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 is provided on when to use this tool versus alternatives (e.g., 'cdp_delete_output_connector' or other deletion tools in the sibling list). The description lacks context about prerequisites, such as whether the definition must be inactive or if there are dependencies to check, offering no usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. 'Deploy' implies a state change (making workflow active), but the description doesn't disclose whether this is reversible, what permissions are required, whether it affects running instances, or what happens if deployment fails. For a mutation tool with zero annotation coverage, this is critically inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single phrase with clarifying parenthetical. Every word earns its place: 'deploy' (action), 'workflow' (resource), 'make it active' (outcome). There's no redundancy or unnecessary elaboration. It's 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 this is a mutation tool with 3 parameters, 0% schema coverage, no annotations, and sibling tools that might overlap (cdp_activate_schedule, cdp_run_workflow), the description is insufficient. While an output schema exists (which helps), the description doesn't address critical context: what 'deploy' means operationally, parameter meanings, or differentiation from similar tools. For a workflow deployment operation, this leaves too many questions unanswered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but provides no parameter information. It doesn't explain what workflow_id refers to, what version deployment targets (latest vs specific), or when tenant_id is needed. With 3 parameters (1 required) completely undocumented in both schema and description, this creates significant ambiguity for the agent.
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 ('deploy') and resource ('workflow'), with the parenthetical 'make it active' providing additional semantic context. It distinguishes from sibling tools like cdp_run_workflow (execution) and cdp_get_workflow (retrieval), though not explicitly named. The purpose is specific but could be more differentiated from similar deployment/activation 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 cdp_activate_schedule or cdp_run_workflow. It doesn't mention prerequisites (e.g., workflow must exist), consequences of deployment, or typical use cases. The agent must infer usage from the name and context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states this is a GET operation, implying read-only behavior, but doesn't confirm if it's safe, idempotent, or has side effects. It also doesn't mention rate limits, authentication requirements, error conditions, or what constitutes a valid 'emailable page' ID. The description adds minimal behavioral context beyond the HTTP method hint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('Get an emailable page by id'). It wastes no words, though it could be more informative. The structure is clear but overly terse given the lack of other documentation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there's an output schema (which should describe the return value), the description doesn't need to explain output details. However, with no annotations, 0% schema coverage, and two parameters (one optional), the description is incomplete. It doesn't address authentication, error handling, or provide enough context for the agent to use the tool confidently in a real scenario. It's minimally adequate but leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description mentions 'by id' which correlates with 'page_id', but doesn't explain what format the ID should be (e.g., UUID, numeric) or where to obtain it. It also doesn't clarify the optional 'tenant_id' parameter—when it's needed, what happens if omitted, or its relationship to 'page_id'. The description adds minimal semantic value beyond naming one parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'Get' and resource 'emailable page by id', which clarifies the basic action. However, it doesn't differentiate this tool from sibling tools like 'cdp_get_emailable_pages' (plural) or explain what an 'emailable page' is specifically. The purpose is clear but lacks sibling differentiation and domain context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention sibling tools like 'cdp_list_emailable_pages' for listing pages or 'cdp_get_emailable_page' versus other 'get' operations. There's no context about prerequisites, authentication needs, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states this is a 'Get' operation, implying read-only behavior, but doesn't disclose any behavioral traits like authentication requirements, rate limits, error conditions, or what happens if the entity doesn't exist. For a tool with no annotation coverage, this leaves significant gaps in understanding how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that gets straight to the point. There's no wasted verbiage or unnecessary elaboration. However, it's arguably too concise given the complexity of the tool and lack of supporting information elsewhere.
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 4 parameters with 0% schema coverage, no annotations, but an output schema exists, the description is minimally adequate. The output schema means return values are documented elsewhere, but the description doesn't provide enough context about the tool's role, parameters, or behavior to be considered complete. It meets the bare minimum for a simple retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter information beyond what's inferred from the tool name. It mentions 'resource name and ID' but doesn't explain what these parameters mean, their format, or the purpose of optional parameters like 'tenant_id' and 'include'. With 4 parameters (2 required), this is inadequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('Get') and target ('a single entity'), but is vague about what an 'entity' represents in this context. It doesn't differentiate from sibling tools like 'cdp_get_campaign' or 'cdp_get_user', which also retrieve single items. The purpose is understandable but lacks specificity about the domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With many sibling 'get' tools (e.g., cdp_get_campaign, cdp_get_user), the description doesn't explain that this is a generic entity retrieval tool or when to choose it over more specific ones. There's no mention of prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic action. It doesn't disclose behavioral traits like whether this is a read-only operation (implied by 'Get' but not confirmed), authentication requirements, rate limits, error handling, or what happens if the ID is invalid. This leaves significant gaps for an agent to understand tool behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence that directly states the tool's purpose. It's front-loaded and wastes no words, making it easy to parse quickly. However, this conciseness comes at the cost of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which helps), no annotations, and low schema coverage (0%), the description is insufficient. It doesn't explain what a mapping template is, the return format, or error conditions. For a tool with 2 parameters (one required, one optional with null default), more context is needed to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds minimal value. It mentions 'by ID' which relates to the 'template_id' parameter, but doesn't explain the 'tenant_id' parameter or provide context like ID format, optionality, or default behavior. This fails to adequately supplement the undocumented schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a specific mapping template by ID' clearly states the action (Get) and resource (mapping template), but it's generic and doesn't differentiate from sibling tools like 'cdp_get_mapping_template' vs 'cdp_list_mapping_templates'. It specifies 'by ID' which adds some specificity, but remains basic without explaining what a mapping template is or its context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, such as needing a valid template ID, or contrast it with related tools like 'cdp_list_mapping_templates' for browsing or 'cdp_create_mapping_template' for creation. Usage is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only mentions the action ('Get'), implying a read operation, but fails to detail aspects like authentication needs, rate limits, error handling, or what 'schema checkpoints' entail. This leaves significant gaps in understanding how the tool behaves beyond basic retrieval.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, straightforward sentence: 'Get schema checkpoints for a tenant.' It is front-loaded with the core action and resource, with no unnecessary words or fluff, making it highly efficient and easy to parse.
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 (1 parameter with 0% schema coverage, no annotations, but an output schema exists), the description is inadequate. It fails to explain the parameter, the nature of 'schema checkpoints,' or behavioral traits. While the output schema may cover return values, the description does not provide enough context for the agent to use the tool effectively in isolation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter (tenant_id) with 0% description coverage, meaning the schema provides no semantic context. The description does not mention this parameter at all, offering no compensation for the lack of schema documentation. This leaves the agent guessing about the parameter's role and usage.
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 'Get schema checkpoints for a tenant' clearly states the action ('Get') and resource ('schema checkpoints for a tenant'), making the purpose understandable. However, it lacks specificity about what 'schema checkpoints' are or how this differs from other 'get' tools in the sibling list (e.g., cdp_get_audience_def, cdp_get_campaign), leaving room for 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?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools (e.g., cdp_get_tenant, cdp_get_workflow), there is no indication of context, prerequisites, or exclusions. It merely states what it does without helping the agent decide when it's appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but fails to add any meaningful context. It doesn't indicate if this is a read-only operation, describe pagination behavior (implied by offset/limit parameters), rate limits, authentication needs, or what the output contains. The description merely restates the endpoint without 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?
The description is extremely concise—a single sentence that directly states the tool's action and endpoint. It's front-loaded with the core purpose and wastes no words, making it efficient for quick comprehension, though this brevity contributes to gaps in other dimensions.
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 (a list operation with 3 parameters), lack of annotations, 0% schema coverage, and presence of an output schema, the description is insufficient. It doesn't compensate for missing parameter documentation, provide behavioral context, or explain usage, relying too heavily on the output schema to cover return values without addressing other critical aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning parameters are undocumented in the schema, and the description adds no semantic information about them. It doesn't explain what 'tenant_id', 'offset', or 'limit' mean in context, their expected formats, or default behaviors, leaving the agent to guess based on parameter names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('mailer subusers'), making the purpose specific and understandable. It distinguishes itself from siblings like 'cdp_get_mailer_subuser' (singular retrieval) and 'cdp_create_mailer_subuser' (creation), but doesn't explicitly differentiate from other list tools (e.g., 'cdp_list_mailer_accounts'), which keeps it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., tenant context), use cases (e.g., browsing vs. filtering), or compare it to similar list tools in the sibling set, leaving the agent with no contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the tool lists instances with filters, lacking any disclosure about behavioral traits such as pagination (implied by offset/limit parameters but not explained), rate limits, authentication needs, or whether it's read-only. This is inadequate for a tool with 7 parameters and no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose and enumerates key filters. There is no wasted verbiage, making it appropriately concise for a list operation.
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 (7 parameters, no annotations, schema coverage 0%, but with an output schema), the description is insufficient. It lacks behavioral context, doesn't explain all parameters, and doesn't mention the output schema's existence or what the tool returns. For a list tool with multiple filters and pagination, more detail is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description lists optional filters (active, status, provision_name, requested_by), which covers 4 of the 7 parameters. However, schema description coverage is 0%, and it omits tenant_id, offset, and limit without explaining their purpose or relationship to the listing operation. This partial coverage fails to compensate for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and resource ('provisioned instances'), making the purpose evident. It also mentions optional filters, which adds specificity. However, it doesn't explicitly distinguish this tool from sibling list tools (e.g., cdp_list_unlinked_provision_instances), which would require a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions optional filters but doesn't specify scenarios for their use, prerequisites, or exclusions. Without any context for selection among sibling tools, this is minimal guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states that this updates an existing connector, but provides no information about permissions required, whether the update is partial or complete, what happens to unspecified fields, error conditions, or response format. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two sentences that directly state the tool's purpose and the parameter format. There's zero wasted language, and the information is front-loaded appropriately.
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 3 parameters (0% schema coverage), no annotations, and an output schema (whose existence means return values don't need description), the description is insufficient. It doesn't provide enough context about the update operation's behavior, parameter usage, or relationship to sibling tools to enable proper tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for all 3 parameters, the description provides minimal help. It mentions 'updated fields as a JSON string' which hints at the 'body' parameter's purpose, but doesn't explain what fields can be updated, the JSON structure, or the purpose of 'connector_id' and 'tenant_id'. The description doesn't adequately compensate for the complete lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and the resource ('an existing output connector'), providing a specific verb+resource combination. However, it doesn't differentiate this tool from its sibling 'cdp_update_output_connector_def' which appears to update connector definitions rather than connectors themselves, missing explicit 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 'cdp_update_output_connector_def' or 'cdp_create_output_connector'. There's no mention of prerequisites, constraints, or appropriate contexts for using this update operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool deletes a cache entry and returns '204 on success', which implies a destructive write operation and a specific HTTP-like success code. However, it lacks critical behavioral details: no mention of authentication requirements, error responses, rate limits, whether deletion is permanent or reversible, or what happens if the ID doesn't exist. For a destructive operation with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two short sentences that state the core action and success response. Every word earns its place with zero redundancy or unnecessary elaboration. It's front-loaded with the primary purpose and follows with behavioral detail about the return code.
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 this is a destructive operation with 3 parameters (2 required), 0% schema coverage, no annotations, and an output schema exists (though not provided here), the description is incomplete. It covers the basic action and success code but misses critical context: parameter meanings, authentication needs, error handling, and how it differs from sibling deletion tools. The existence of an output schema means the description doesn't need to detail return values, but it should still address the other gaps for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the three parameters (cache_type, id, tenant_id) have descriptions in the schema. The tool description provides no information about these parameters—what they represent, valid values, formats, or how they interact. The description mentions 'by ID' which hints at the 'id' parameter but doesn't explain what 'cache_type' means or when 'tenant_id' is required. With 0% schema coverage and no parameter guidance in the description, this is inadequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and resource ('a cache entry by ID'), which is specific and unambiguous. It distinguishes from siblings like 'cdp_cache_delete_by_group' and 'cdp_cache_delete_by_key' by specifying the deletion method (by ID). However, it doesn't explicitly mention what 'cache entry' refers to in this context, leaving some ambiguity about the resource 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?
The description provides no guidance on when to use this tool versus alternatives like 'cdp_cache_delete_by_group' or 'cdp_cache_delete_by_key'. It doesn't mention prerequisites, error conditions, or any context about when this deletion method is appropriate compared to other cache deletion methods available in the sibling tools list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'Set or update' which implies a write/mutation operation, but fails to describe critical behaviors such as permissions required, whether it overwrites existing entries, error conditions, or response format. The existence of an output schema mitigates some gaps, but the description itself lacks 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It is front-loaded with the core action and key parameters, making it easy to parse quickly.
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 (6 parameters, mutation operation), lack of annotations, and 0% schema description coverage, the description is insufficient. While an output schema exists, the description does not address parameter meanings, behavioral traits, or usage context, leaving significant gaps for an AI 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.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 6 parameters have descriptions in the schema. The tool description does not add any meaning for parameters like cache_type, group, id, value, tenant_id, or expiry_time—it only mentions 'group and ID' generically. This fails to compensate for the complete lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Set or update') and resource ('a cache entry'), specifying the mechanism ('by group and ID'). It distinguishes from siblings like cdp_cache_put_by_id and cdp_cache_put_by_key by mentioning the group parameter, but does not explicitly contrast them in the description text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 cdp_cache_put_by_id or cdp_cache_put_by_key, nor are any prerequisites, exclusions, or contextual usage scenarios mentioned. The description only states what it does without indicating 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?
With no annotations, the description carries full burden. It implies a write operation ('creates a copy') but lacks details on permissions, whether the clone inherits settings, if it's immediately active, or error handling. The HTTP method (POST) hints at mutation, but behavioral context like side effects or response format is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action. It includes an API endpoint for context without verbosity, though the URL could be seen as extraneous if not adding value beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, 0% schema coverage, and an output schema (unseen), the description is inadequate. It doesn't explain parameters, behavioral traits, or what the clone operation entails (e.g., if metadata is copied). The presence of an output schema might help, but the description lacks foundational context for safe and correct use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions no parameters explicitly, failing to explain 'prediction_def_id' (the ID to clone) or 'tenant_id' (context for multi-tenancy). The URL in the description includes placeholders but doesn't map them to input parameters, leaving semantics unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Clone') and resource ('prediction definition'), specifying it creates a copy with a new ID. It distinguishes from siblings like 'cdp_create_prediction' by focusing on duplication rather than creation from scratch, though it doesn't explicitly contrast with other clone tools like 'cdp_clone_campaign'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 doesn't mention prerequisites (e.g., needing an existing prediction definition), compare to other clone tools (e.g., 'cdp_clone_campaign'), or indicate typical use cases like testing modifications on a copy.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Create' which implies a write/mutation operation, but doesn't disclose any behavioral traits such as required permissions, whether the operation is idempotent, what happens on conflicts, rate limits, or what the output contains. The description is minimal and lacks essential context for a creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that directly states the action and parameters, with no wasted words. It's appropriately brief but could be more structured by separating purpose from parameter guidance.
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 (4 parameters, 0% schema coverage, no annotations) and the presence of an output schema, the description is insufficient. It doesn't compensate for the lack of parameter documentation, provides no behavioral context for a mutation tool, and relies entirely on the output schema for return values without any high-level explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description mentions 'template type and entityId along with tenant list as JSON body', which names three parameters but doesn't explain their meaning, valid values, or relationships. It omits the 'tenant_id' parameter entirely and provides no semantic details beyond naming.
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') and resource ('new campaign template'), making the purpose unambiguous. It distinguishes from siblings like 'cdp_create_campaign' by specifying 'template', but doesn't explicitly differentiate from other template-related tools like 'cdp_create_connector_template' or 'cdp_create_mapping_template'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description mentions passing parameters but doesn't indicate prerequisites, dependencies, or scenarios where this tool is appropriate compared to other campaign or template creation 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Create a new OAuth client,' implying a mutation operation, but does not disclose critical behavioral traits such as required permissions, whether the operation is idempotent, rate limits, or what happens on failure. The description adds minimal context beyond the basic action, leaving significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the main action and lists required parameters. It is efficient with no wasted words. However, it could be slightly more structured by separating the action from parameter details for better 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 (7 parameters, mutation operation) and lack of annotations, the description is incomplete. It does not explain the output (though an output schema exists, mitigating this gap), behavioral aspects, or usage context. For a creation tool with no annotations and low schema coverage, the description should provide more guidance on parameters, permissions, and outcomes to be adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists four required parameters ('client_id_str, client_secret, grants, and token_validity'), adding some meaning beyond the schema's property titles. However, it omits the three optional parameters ('tenant_id', 'authorities', 'scope') and does not explain the purpose, format, or constraints of any parameters (e.g., what 'grants' or 'token_validity' represent), failing to fully compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Create a new OAuth client.' It specifies the verb ('Create') and resource ('OAuth client'), making the action explicit. However, it does not differentiate this tool from its sibling 'cdp_create_token' (which also creates OAuth-related resources) or other creation tools, missing 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. It lists required parameters but does not mention prerequisites, context, or exclusions. For example, it does not specify if this is for administrative use only or how it relates to other client management tools like 'cdp_update_client' or 'cdp_delete_client'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'Create' which implies a write operation, but doesn't disclose behavioral traits like required permissions, whether this is idempotent, what happens on duplicate creation, rate limits, or what the output contains. The JSON string format hint is minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two sentences. It's front-loaded with the main purpose and includes a practical implementation detail. Every word earns its place with zero 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 2 parameters with 0% schema coverage, no annotations, but with an output schema present, the description is minimally adequate. The output schema will document return values, but the description lacks crucial context about the creation operation, parameter details, and behavioral expectations. It meets basic requirements but leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'template as a JSON string' which partially explains the 'body' parameter, but doesn't clarify the JSON structure, required fields, or examples. The 'tenant_id' parameter is completely undocumented in both schema and description. The description adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('Create a new mapping template') which is clear, but it doesn't specify what a 'mapping template' is or how it differs from other template-related tools like 'cdp_create_campaign_template' or 'cdp_create_connector_template'. The verb+resource combination is present but lacks domain-specific context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There's no mention of prerequisites, related operations (like 'cdp_update_mapping_template' or 'cdp_delete_mapping_template'), or contextual constraints. The description is purely functional without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Create a new output connector definition', which implies a write/mutation operation, but doesn't disclose any behavioral traits such as permissions required, whether the creation is idempotent, rate limits, or what happens on failure (e.g., if the definition already exists). The mention of 'Pass definition as a JSON string' hints at input format but doesn't clarify the response format or success/failure outcomes, leaving significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences that directly address the tool's purpose and a key parameter requirement. It avoids unnecessary words and is front-loaded with the main action. However, it could be slightly improved by integrating the parameter guidance more seamlessly, but overall it's efficient and well-structured for its limited content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a creation tool with 2 parameters (one required), 0% schema coverage, no annotations, and an output schema (which exists but isn't detailed here), the description is incomplete. It lacks crucial information: no behavioral context (e.g., permissions, side effects), minimal parameter details, and no mention of the output schema's role. For a mutation tool in a system with many siblings, this leaves the agent under-informed about how to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no descriptions for the two parameters ('body' and 'tenant_id'). The description adds minimal value by specifying that 'body' should be 'a JSON string', which gives some context for one parameter, but doesn't explain what the JSON should contain, its structure, or examples. It doesn't mention 'tenant_id' at all, leaving it completely undocumented. With low coverage, the description fails to compensate adequately for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a new output connector definition') and specifies the resource ('output connector definition'), which is a specific verb+resource combination. It distinguishes from siblings like 'cdp_create_output_connector' (which creates the connector itself rather than its definition) and 'cdp_update_output_connector_def' (which updates rather than creates). However, it doesn't explicitly differentiate from other 'create' tools in the list, such as 'cdp_create_connector' or 'cdp_create_connector_template', which handle different resource types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., whether a connector template must exist), when not to use it (e.g., for updates or deletions), or refer to sibling tools like 'cdp_update_output_connector_def' or 'cdp_delete_output_connector_def'. The agent must infer usage from the tool name alone, which is insufficient for clear decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states it 'creates' a role without disclosing behavioral traits. It doesn't mention required permissions, whether the operation is idempotent, what happens on conflicts, or the response format. The JSON format hint for whitelist/blacklist is useful but insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the core purpose. Both sentences are relevant, though it could be more structured by separating usage instructions from parameter format details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter mutation tool with no annotations and 0% schema coverage, the description is inadequate. While an output schema exists, the description doesn't address critical context like authentication needs, error conditions, or relationship to other role management tools, leaving significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but only addresses whitelist/blacklist parameters. It doesn't explain the purpose of 'name', 'tenant_id', or 'included', nor does it clarify what Permission objects contain or how JSON arrays should be structured. The description adds minimal value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a new role') and specifies the key functionality ('with whitelist/blacklist permissions'), which distinguishes it from generic creation tools. However, it doesn't explicitly differentiate from sibling tools like 'cdp_create_user' or 'cdp_update_role' beyond 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?
No guidance is provided on when to use this tool versus alternatives like 'cdp_update_role' or 'cdp_list_roles'. The description mentions whitelist/blacklist permissions but doesn't explain prerequisites, constraints, or typical use cases for role creation in this system.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It states this is a creation tool (implying mutation) but doesn't disclose behavioral traits like required permissions, whether it's idempotent, rate limits, or what happens on duplicate names. The mention of 'Requires name and expression' hints at validation but lacks detail.
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 main purpose. Both sentences add value: the first states the action, and the second provides parameter guidance. There's no unnecessary verbiage, 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?
Given a mutation tool with no annotations, 0% schema coverage, and an output schema (which helps but isn't described), the description is incomplete. It lacks details on permissions, error conditions, return values (though output schema exists), and doesn't fully explain parameters, making it inadequate for safe use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'name and expression (SQL query)' as required, but the schema has parameters 'body' (type string) and 'tenant_id' (optional string/null). The description doesn't explain that 'body' should be a JSON string containing name/expression or clarify the 'tenant_id' parameter's purpose, leaving significant gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a new SQueryDef') and specifies the resource type. It distinguishes from siblings like 'cdp_copy_squery_def' or 'cdp_update_squery_def' by focusing on creation. However, it doesn't explicitly differentiate from 'cdp_generate_squery_def' or 'cdp_validate_squery_def', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'cdp_copy_squery_def' or 'cdp_generate_squery_def'. It mentions required parameters but doesn't specify prerequisites, context, or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates a destructive action ('Cancel/delete') but fails to specify critical details such as required permissions, whether the deletion is reversible, potential side effects, or rate limits. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It front-loads the core action and resource, making it immediately clear what the tool does without unnecessary elaboration, which is ideal for 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?
Given the complexity of a deletion tool with 2 parameters (0% schema coverage), no annotations, and an output schema (which helps but isn't described), the description is incomplete. It lacks parameter explanations, behavioral context, and usage guidelines, making it inadequate for safe and effective tool invocation by an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the schema provides no descriptions for the two parameters ('body' and 'tenant_id'). The description adds no information about what these parameters represent, their formats, or how they affect the operation. For example, it doesn't explain what 'body' should contain or when 'tenant_id' is required, leaving parameters completely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Cancel/delete') and resource ('a pending data erasure request'), making the purpose specific and understandable. However, it doesn't differentiate from sibling tools like 'cdp_update_data_erasure_request' or 'cdp_get_data_erasure_status', which handle modification and status checks of similar resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., that a pending request must exist), exclusions, or refer to sibling tools like 'cdp_request_data_erasure' for creation or 'cdp_update_data_erasure_request' for modifications, leaving the agent with no contextual usage cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states 'Delete', implying a destructive mutation, but doesn't disclose critical behavioral traits: whether deletion is permanent or reversible, if it requires specific permissions, rate limits, or what happens to associated data. The HTTP method (DELETE) is mentioned, but this is low-value without further context on side effects or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('Delete a prediction definition') without unnecessary words. It includes the HTTP endpoint as supplementary detail, which doesn't detract from clarity. Every part earns its place, making it 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature, no annotations, 0% schema coverage, and an output schema (which might cover return values), the description is incomplete. It lacks essential context: parameter meanings, behavioral risks, usage constraints, and differentiation from siblings. While an output schema exists, the description doesn't provide enough guidance for safe and effective use in a broader context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning parameters are undocumented in the schema. The description adds no information about parameters—it doesn't explain what 'prediction_def_id' or 'tenant_id' represent, their formats, or usage. For a tool with 2 parameters (1 required), this is a significant gap, failing 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and the resource ('a prediction definition'), which is specific and unambiguous. It distinguishes from siblings like 'cdp_delete_campaign' or 'cdp_delete_audience_def' by specifying the resource type. However, it doesn't explicitly differentiate from 'cdp_clone_prediction' or 'cdp_update_prediction' beyond the verb, which keeps it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing prediction definition ID), exclusions (e.g., not for active predictions), or comparisons to siblings like 'cdp_update_prediction' or 'cdp_clone_prediction'. This leaves the agent with minimal 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates a destructive action ('Deprovision'), implying data removal or resource cleanup, but fails to specify critical details like whether this is irreversible, requires specific permissions, has side effects on related resources, or involves rate limits. This leaves significant gaps for safe agent invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that efficiently conveys the core action without unnecessary words. However, it could be more front-loaded by explicitly stating key behavioral traits upfront, but it avoids redundancy and 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature, no annotations, 0% schema coverage, and an output schema (which helps but isn't described), the description is incomplete. It lacks essential context such as safety warnings, parameter explanations, and usage scenarios, making it inadequate for informed agent decision-making despite the output schema's presence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter details. The description mentions 'instance_id' implicitly via the URL path but adds no semantic context for 'instance_id' or 'tenant_id' (e.g., what they represent, format examples, or when tenant_id is optional). It fails to compensate for the lack of schema documentation, leaving parameters poorly understood.
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 ('Deprovision') and resource ('a provisioned instance'), making the purpose specific and understandable. It distinguishes from siblings like 'cdp_delete_provision_instance' (which doesn't exist in the list) or 'cdp_deactivate_provision_instance' by specifying deprovisioning, though it doesn't explicitly differentiate from similar tools like 'cdp_delete_*' operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'cdp_deactivate_provision_instance' or 'cdp_delete_provision_instance' (implied by other delete tools). The description lacks context about prerequisites, consequences, or typical scenarios for deprovisioning, offering minimal usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'export is generated from the cube data on the collection endpoint', hinting at data retrieval and file generation, but lacks details on permissions, rate limits, file size, or error handling. For a tool with no annotations, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the main action, using two sentences efficiently. However, it could be more structured by separating prerequisites and behavioral notes, but it avoids unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, 0% schema coverage, and an output schema (which helps but isn't described), the description is incomplete. It doesn't cover all parameters, lacks behavioral context, and doesn't explain the output (e.g., file format details). For a tool with 4 parameters and export functionality, this is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only mentions 'cubeId and password' as required, ignoring 'tenant_id' and 'filename' parameters. This adds minimal meaning beyond the schema, failing to explain what these parameters do or their formats, leaving most semantics undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Export a report as an Excel pivot file') and the resource ('report'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'cdp_copy_report_def' or 'cdp_get_report_def', which reduces clarity in context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'Requires cubeId and password' as prerequisites, which provides some usage context, but it doesn't specify when to use this tool versus alternatives (e.g., other export or report-related tools in the sibling list) or any exclusions. No explicit guidance on when-not-to-use is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Get' implies a read-only operation, but it doesn't disclose behavioral traits like authentication needs, rate limits, error handling, or what happens if the role doesn't exist. The description is minimal and lacks crucial context for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to parse quickly. No unnecessary words or structural issues are 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?
Given the tool has an output schema (which reduces the need to describe return values), no annotations, and low schema coverage, the description is incomplete. It covers the basic purpose but misses parameter details, usage context, and behavioral transparency. For a simple read tool, it's minimally adequate but leaves gaps in understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description mentions 'by ID', which hints at the 'role_id' parameter, but doesn't explain its format or meaning. It completely ignores the 'tenant_id' parameter, leaving it undocumented. The description adds minimal value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a specific role by ID' clearly states the verb ('Get') and resource ('role'), but it's vague about scope and doesn't differentiate from siblings like 'cdp_list_roles' or 'cdp_get_user'. It specifies retrieval by ID, which adds some specificity, but lacks context about what a 'role' entails in this system.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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. With siblings like 'cdp_list_roles' (for listing roles) and 'cdp_get_user' (for user details), the description doesn't indicate this is for retrieving a single role by its identifier, nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Get' which implies a read operation, but doesn't disclose behavioral traits like authentication needs, rate limits, error handling, or whether it's idempotent. For a read tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's appropriately sized and front-loaded, directly stating the tool's core function without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 parameters with 0% schema coverage, no annotations, but an output schema exists, the description is minimally complete. It identifies the resource and key parameter, but lacks details on parameter semantics, behavioral context, or usage guidelines. The output schema mitigates the need to explain return values, but gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description mentions 'by ID' which hints at 'schedule_id', but doesn't explain what 'schedule_id' is (e.g., integer ID format) or mention 'tenant_id' at all. It adds minimal value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a specific schedule by ID' clearly states the verb ('Get') and resource ('schedule'), but it's vague about what 'Get' entails (e.g., retrieve details, fetch metadata). It distinguishes from siblings like 'cdp_list_schedules' (list vs. get specific), but lacks specificity on the scope of returned 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 explicit guidance on when to use this tool versus alternatives. It implies usage when a schedule ID is known, but doesn't mention prerequisites, when not to use it (e.g., for listing all schedules), or compare to siblings like 'cdp_get_schedule' vs. 'cdp_list_schedules' for bulk retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states this is a read operation ('Get'), implying it's non-destructive, but doesn't disclose any behavioral traits like authentication needs, rate limits, error handling, or what the output contains (though an output schema exists). For a tool with zero annotation coverage, this leaves significant gaps in understanding how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words. It front-loads the core action ('Get') and key constraint ('by ID'), making it easy to parse. Every word earns its place, though this conciseness comes at the cost of detail.
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 (simple retrieval with 2 parameters) and the presence of an output schema (which handles return values), the description is minimally adequate. However, with no annotations and 0% schema coverage, it fails to compensate for missing context like parameter meanings, error cases, or usage distinctions from siblings. It meets the bare minimum but leaves the agent to rely heavily on structured fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description mentions 'by ID', which hints at 'customization_id', but doesn't explain what this ID is, its format, or where to obtain it. It ignores 'tenant_id' entirely, leaving its purpose and default behavior (nullable with default null) unexplained. The description adds minimal value beyond the parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('Get') and resource ('a specific summary customization'), which is clear but basic. It doesn't differentiate from sibling tools like 'cdp_list_summary_customizations' (which likely lists multiple) or explain what a 'summary customization' is in this context. The purpose is understandable but lacks specificity about the domain or what the customization entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 doesn't mention prerequisites (e.g., needing an existing customization ID), compare it to 'cdp_list_summary_customizations' for browsing, or specify error conditions (e.g., what happens if the ID doesn't exist). The agent must infer usage from the name and parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'Get', implying a read operation, but fails to specify if it requires authentication, has rate limits, returns structured data or metadata, or handles errors. For a tool with two parameters and no annotation coverage, this lack of detail is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words, making it easy to parse. It is appropriately sized for a simple tool, though its brevity contributes to gaps in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which likely defines return values), the description's minimalism is partially acceptable. However, with no annotations, 0% schema coverage, and two parameters, it lacks essential context like behavioral traits and parameter details, making it incomplete for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It mentions 'by ID', which aligns with the 'table_id' parameter, but does not explain 'tenant_id' (e.g., its optional nature or purpose) or provide any context on parameter formats or constraints. This leaves half of the parameters inadequately explained.
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 'Get a specific UDMP table by ID' clearly states the verb 'Get' and resource 'UDMP table', making the basic purpose understandable. However, it lacks specificity about what 'Get' entails (e.g., retrieve metadata, schema, or data) and does not differentiate from sibling tools like 'cdp_list_udmp_tables' or 'cdp_get_udmp_resources', leaving ambiguity about scope and distinctions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, such as needing a valid table ID, or contrast it with sibling tools like 'cdp_list_udmp_tables' for listing tables. This absence of context makes it unclear when this tool is the appropriate choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Get', implying a read-only operation, but does not clarify if it requires specific permissions, returns detailed metadata or just basic info, has rate limits, or what the output includes. For a tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words, making it highly concise and front-loaded. It efficiently communicates the core action without unnecessary elaboration, though this brevity contributes to gaps in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 parameters, 2 required) and the presence of an output schema, the description is minimally adequate. The output schema likely covers return values, reducing the need for description detail. However, with no annotations and 0% schema description coverage, the description should do more to explain parameters and usage context, making it incomplete for full agent guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, meaning parameters are undocumented in the schema. The description adds no information about the four parameters (workflow_id, step_id, version, tenant_id), such as their formats, purposes, or how they interact. It fails to compensate for the schema's lack of descriptions, leaving parameters semantically unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a specific step in a workflow' clearly states the verb ('Get') and resource ('step in a workflow'), making the purpose understandable. However, it lacks specificity about what 'Get' entails (e.g., retrieve metadata, configuration, or status) and does not differentiate from sibling tools like 'cdp_get_workflow' or 'cdp_list_workflow_steps', leaving room for 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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., needing a workflow_id and step_id), when it is appropriate (e.g., for inspecting a step's details), or refer to sibling tools like 'cdp_list_workflow_steps' for broader queries, leaving the agent without contextual usage cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'List' which implies a read-only operation, but doesn't disclose any behavioral traits like pagination behavior (though offset/limit parameters suggest pagination), authentication requirements, rate limits, error conditions, or what the output contains. For a list operation with 3 parameters, this leaves significant gaps in understanding how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core purpose without unnecessary words. It's appropriately sized for a list operation and front-loads the essential information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (list operation with pagination parameters), lack of annotations, and 0% schema description coverage, the description is insufficient. While an output schema exists (which helps with return values), the description doesn't address key contextual aspects like parameter meanings, behavioral constraints, or usage guidance. For a tool with 3 parameters in a large sibling set, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% (titles only provide parameter names), and the description adds no information about parameters. It doesn't explain what 'tenant_id', 'offset', or 'limit' mean, their expected values, or how they affect the listing. With 3 undocumented parameters, the description fails to compensate for the schema's lack of semantic information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List A360 identity resolution rules' clearly states the action (list) and resource (A360 identity resolution rules). It distinguishes from sibling tools like 'cdp_get_a360_rule' (get single) and 'cdp_create_a360_rule' (create), but doesn't explicitly differentiate from other list tools like 'cdp_list_audience_defs' or 'cdp_list_dqe1_rules' beyond the specific 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?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, typical use cases, or when other tools like 'cdp_get_a360_rule' (for single rule details) or 'cdp_create_a360_rule' (for creation) would be more appropriate. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It implies a read-only list operation but doesn't disclose behavioral traits like pagination, sorting, default tenant behavior, error conditions, or performance characteristics. For a list tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's appropriately sized for a simple list tool and front-loaded with the core action. Every word earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (list operation, one optional parameter) and the presence of an output schema (which handles return values), the description is minimally complete. However, with no annotations and poor schema coverage, it lacks context on usage, parameters, and behavior, making it adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, with one parameter ('tenant_id') undocumented in the schema. The description mentions 'for a tenant' but doesn't explain the parameter's role, format, or that it's optional (default null). It adds minimal meaning beyond the schema, failing to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List execution summary groups for a tenant' clearly states the action ('List') and resource ('execution summary groups'), but it's vague about what 'execution summary groups' are and doesn't differentiate from sibling tools like 'cdp_get_execution_summary_group' (singular) or 'cdp_list_execution_buckets'. It provides a basic purpose but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, context (e.g., after creating groups), or exclusions (e.g., not for detailed views). With many sibling tools, this omission leaves the agent without 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?
No annotations are provided, so the description carries full burden. It discloses that results are paged, which is useful behavioral context, but lacks other critical details: it doesn't specify if this is a read-only operation, what authentication is needed, rate limits, error handling, or the format of returned data. For a list operation with zero annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two short sentences that are front-loaded and waste no words. Every part ('List message definitions for a tenant' and 'Returns paged results') adds value, 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?
Given the tool has 3 parameters with 0% schema coverage, no annotations, and an output schema (which helps but isn't described), the description is incomplete. It covers the basic purpose and paging behavior but misses parameter explanations, usage context, and behavioral details like safety or permissions. For a list tool in a complex system, this leaves too many gaps for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the three parameters (tenant_id, offset, limit) are documented in the schema. The description adds no information about these parameters—it doesn't explain what tenant_id refers to, how offset and limit work for pagination, or their default behaviors. 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.
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') and resource ('message definitions for a tenant'), making the purpose understandable. It distinguishes itself from siblings like 'cdp_get_message_def' (singular) by indicating it returns multiple items, but doesn't explicitly differentiate from other list tools like 'cdp_list_audience_defs' beyond 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?
No guidance is provided on when to use this tool versus alternatives. While the description implies it's for listing message definitions, it doesn't specify prerequisites, when to choose it over other list tools, or any constraints like required permissions. The mention of paged results hints at usage for large datasets but isn't explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it's a list operation, implying read-only behavior, but lacks critical details like pagination handling (offset/limit parameters), authentication requirements, rate limits, error conditions, or whether it returns a complete or filtered set. The description is too minimal for a tool with parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with zero wasted words. It's front-loaded with the core purpose and efficiently communicates the essential action without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters with 0% schema coverage, no annotations, and an output schema exists (which reduces need to describe returns), the description is incomplete. It fails to address parameter meanings, usage context, or behavioral traits, making it inadequate for effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about the three parameters (tenant_id, offset, limit). It doesn't explain what these parameters do, their expected values, or how they affect the listing. This leaves parameters entirely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and resource ('available output connector definitions'), making the purpose unambiguous. It distinguishes from siblings like 'cdp_get_output_connector_def' (singular get) and 'cdp_list_output_connectors' (list instances vs definitions), though this differentiation is implicit rather than explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites like authentication, differentiate from similar list tools (e.g., 'cdp_list_output_connectors'), or specify scenarios where listing definitions is appropriate over other operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it's a list operation, implying it's read-only and non-destructive, but doesn't cover critical aspects like pagination behavior (hinted by offset/limit parameters), authentication needs, rate limits, or error handling. This leaves significant gaps for a tool with parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that front-loads the essential action and resource. It's appropriately sized with no redundant information, making it efficient and easy to parse.
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 (3 parameters, no annotations, 0% schema coverage, but with an output schema), the description is insufficient. It doesn't compensate for the lack of parameter documentation or behavioral context. While the output schema may cover return values, the description fails to address input semantics and usage nuances, leaving critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description adds no information about parameters. It doesn't explain what 'tenant_id', 'offset', or 'limit' mean, their formats, defaults, or how they affect the listing. For a tool with 3 parameters and low schema coverage, this is inadequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List all configured') and resource ('output connectors for a tenant'), making the purpose specific and understandable. However, it doesn't differentiate from sibling tools like 'cdp_list_output_connector_defs' or 'cdp_get_output_connector', which list definitions or get a single connector respectively, leaving room for ambiguity in 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, such as 'cdp_list_output_connector_defs' for definitions or 'cdp_get_output_connector' for a single connector. It lacks context on prerequisites, exclusions, or typical scenarios, offering minimal usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it's a list operation, implying read-only behavior, but doesn't cover critical aspects like pagination behavior (implied by offset/limit parameters), rate limits, authentication requirements, error handling, or what 'all' encompasses (e.g., active vs. inactive). This is inadequate for a tool with three parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized for a simple list operation and front-loads the core purpose immediately.
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 three parameters with 0% schema coverage, no annotations, and an output schema (which helps but doesn't excuse the description), the description is incomplete. It lacks parameter explanations, behavioral context (e.g., pagination, permissions), and doesn't leverage the output schema to hint at return values. This is insufficient for effective tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the three parameters (tenant_id, offset, limit) are documented in the schema. The description adds no information about these parameters—it doesn't explain what tenant_id refers to, how offset/limit work for pagination, or default behaviors. This fails to compensate for the complete lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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') and resource ('all report definitions for a tenant'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'cdp_get_report_def' (singular retrieval) or 'cdp_copy_report_def' (copy operation), which would require explicit comparison to achieve a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., authentication), context for listing vs. getting individual definitions, or exclusions (e.g., whether it includes archived definitions). This leaves the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'List all edges' but doesn't describe what 'edges' entail (e.g., connections between steps), whether this is a read-only operation, if it requires permissions, or how results are returned (e.g., pagination, format). This leaves significant gaps for a tool with 3 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('List all edges') and resource ('in a workflow DAG'). There's no wasted verbiage, making it appropriately sized for its 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's complexity (3 parameters, 0% schema coverage, no annotations) and the presence of an output schema, the description is incomplete. It lacks parameter explanations, behavioral context (e.g., read/write nature, permissions), and doesn't leverage the output schema to hint at return values. For a list operation with multiple inputs, this is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, meaning parameters (workflow_id, version, tenant_id) are undocumented in the schema. The description adds no information about these parameters—it doesn't explain what workflow_id refers to, how version affects results, or the role of tenant_id. This fails to compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('edges (connections) in a workflow DAG'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'cdp_list_workflows' or 'cdp_list_workflow_steps', which would require a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as other workflow-related list tools (e.g., cdp_list_workflows, cdp_list_workflow_steps). There's no mention of prerequisites, exclusions, or typical scenarios for listing edges specifically.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the tool 'requests' erasure (implying it may be asynchronous or require approval) but doesn't clarify whether this is a destructive operation, what permissions are needed, how the request is processed, or what happens after submission. For a GDPR/CCPA compliance tool, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. However, it could be more structured by separating the purpose from parameter instructions, and it lacks completeness which affects its effectiveness despite being concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (GDPR/CCPA compliance operation), lack of annotations, 0% schema coverage, and two parameters (one required), the description is insufficient. While an output schema exists, the description doesn't address critical aspects like legal implications, response format hints, error conditions, or integration with sibling tools, making it incomplete for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions that the 'body' parameter should contain 'erasure request as a JSON string' and that customers can be identified by 'identityHash or email', but doesn't explain what fields the JSON should contain, provide examples, or clarify the optional 'tenant_id' parameter. This leaves critical parameter semantics undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Request GDPR/CCPA data erasure') and target ('for a customer'), specifying it can be done by identityHash or email. It distinguishes from siblings like 'cdp_delete_data_erasure_request' (which deletes requests) and 'cdp_get_data_erasure_status' (which checks status), but could be more explicit about this being a request initiation versus other data erasure 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?
The description provides no guidance on when to use this tool versus alternatives like 'cdp_delete_data_erasure_request' or 'cdp_update_data_erasure_request', nor does it mention prerequisites, legal considerations, or typical workflows. It simply states what the tool does without contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('Re-run') but doesn't describe what this entails—whether it creates a new job instance, retains previous configurations, requires specific permissions, has side effects, or handles errors. For a mutation tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and efficiently conveys the core action, making it easy to understand at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 (a mutation operation with 3 parameters), lack of annotations, 0% schema coverage, and no output schema details provided in the context signals, the description is insufficient. It doesn't cover parameter meanings, behavioral traits, or usage distinctions, leaving the agent with critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the parameters (workflow_id, job_id, tenant_id) are documented in the schema. The description provides no information about these parameters—what they represent, their formats, or how to obtain them. It 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Re-run') and the target resource ('a completed or failed workflow job'), which is specific and unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'cdp_run_workflow' or 'cdp_resume_job', which might have overlapping functionality, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance by specifying the job states ('completed or failed') for which the tool is applicable, but it doesn't explain when to use this versus alternatives (e.g., 'cdp_run_workflow' for new runs or 'cdp_resume_job' for suspended jobs). No exclusions or prerequisites are mentioned, leaving significant gaps in usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the action ('Suspend') but doesn't explain what suspension entails (e.g., pausing execution, preserving state), whether it's reversible, permission requirements, or side effects. This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and target, making it easy to parse quickly without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 3 parameters (0% schema coverage), no annotations, and an output schema (implied by context signals), the description is inadequate. It lacks parameter details, behavioral context, and doesn't leverage the output schema to explain return values, leaving the agent poorly informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning parameters are undocumented in the schema. The description provides no information about the three parameters (workflow_id, job_id, tenant_id), their formats, relationships, or examples. It fails to compensate for the schema's lack of documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Suspend') and target ('a running workflow job'), providing a specific verb+resource combination. It doesn't differentiate from sibling tools like 'cdp_kill_job' or 'cdp_resume_job', which would require explicit comparison, but the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'cdp_kill_job', 'cdp_resume_job', or 'cdp_rerun_job'. The description lacks context about prerequisites (e.g., job must be running) or exclusions, offering minimal usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. 'Update' implies mutation, but it doesn't disclose behavioral traits like required permissions, whether changes are reversible, rate limits, or what happens to unspecified fields (partial vs. full updates). For a mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's appropriately sized for a basic tool definition, though its brevity contributes to gaps in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given high complexity (8 parameters, 1 required, mutation operation) and no annotations, the description is incomplete. It lacks parameter semantics, behavioral context, and usage guidelines. An output schema exists, so return values needn't be explained, but the description doesn't add enough value beyond the structured fields to guide effective tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 8 parameters have descriptions in the schema. The tool description adds no parameter information beyond what's implied by 'OAuth client'—it doesn't explain what client_numeric_id, tenant_id, grants, etc., mean or how they affect the update. With 0% coverage and no compensation in the description, this is inadequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an existing OAuth client' clearly states the action (update) and resource (OAuth client). It distinguishes from siblings like cdp_create_client (create) and cdp_delete_client (delete), but doesn't specify what aspects of the client can be updated beyond the generic term.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 doesn't mention prerequisites (e.g., needing an existing client), when not to use it, or how it differs from similar update tools like cdp_update_user or cdp_update_role. The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states it's a real-time update via POST. It lacks critical behavioral details: whether it's idempotent, what permissions are required, if it overwrites or merges data, error handling, or rate limits. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the core action, avoiding redundancy. However, it could be more structured by separating endpoint details from usage instructions, and the parentheses around the endpoint slightly clutter the flow.
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 annotations, 0% schema coverage, and an output schema (which reduces need for return value explanation), the description is incomplete. It misses behavioral context (e.g., side effects, auth), parameter guidance, and sibling differentiation, making it insufficient for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no param details. The description only mentions passing 'profile update data as a JSON string', which loosely maps to the 'body' parameter but doesn't explain its structure, required fields, or examples. It ignores the 'tenant_id' parameter entirely, failing to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Update') and resource ('customer profile attributes'), specifying it's for real-time updates via a POST endpoint. However, it doesn't differentiate from sibling tools like 'cdp_update_campaign' or 'cdp_update_user', which have similar naming patterns but target different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., authentication), exclusions, or related tools for reading profiles (like 'cdp_get_customer_360'), leaving the agent to infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions that the tool updates an existing definition, implying mutation, but doesn't disclose behavioral traits like required permissions, whether changes are reversible, rate limits, or error handling. The note about 'folder_id' adds some context but is insufficient for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences: one states the purpose and parameter format, and the other explains 'folder_id'. It's front-loaded with the main action, and every sentence adds value (e.g., clarifying JSON usage and folder movement). There's no wasted text, though it could be slightly more structured for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a mutation tool with 4 parameters, 0% schema coverage, no annotations, but an output schema exists), the description is incomplete. It lacks details on behavioral aspects (e.g., auth, side effects), full parameter semantics, and usage context. While the output schema may cover return values, the description doesn't adequately prepare the agent for correct invocation in this environment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning for 'folder_id' by explaining it 'moves the export between folders,' which is helpful. However, it doesn't clarify 'body' (described as 'Pass updated fields as a JSON string' but without details on structure) or 'tenant_id', and 'export_id' is left unexplained. With 4 parameters and low coverage, the description provides only partial semantic 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 the tool's purpose: 'Update an existing data export definition.' It specifies the verb ('Update') and resource ('data export definition'), which is straightforward. However, it doesn't explicitly differentiate from sibling tools like 'cdp_update_audience_def' or 'cdp_update_report_def', which also update definitions but for different resources, so it misses full 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 minimal usage guidance: it mentions that 'folder_id moves the export between folders,' which hints at a specific use case, but it doesn't explain when to use this tool versus alternatives (e.g., vs. 'cdp_create_data_export' or 'cdp_delete_data_export'), nor does it outline prerequisites or exclusions. This leaves the agent with little 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is an update operation (implying mutation) and mentions the endpoint, but fails to describe critical behaviors: required permissions, whether changes are reversible, rate limits, error conditions, or what the output contains. The JSON string requirement is a parameter detail, not behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief (two clauses) and front-loaded with the core purpose. The HTTP endpoint detail is arguably extraneous for an AI agent but doesn't significantly bloat the text. It avoids repetition and stays focused, though it could be 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?
Given a mutation tool with 3 parameters (0% schema coverage), no annotations, and an output schema (existence noted but content unknown), the description is inadequate. It doesn't explain the update's impact, required inputs, error handling, or return values. The output schema's presence reduces the need to describe returns, but the description still misses crucial context about permissions, side effects, and parameter meanings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only mentions that 'body' should be 'a JSON string' containing 'the updated definition', which adds minimal semantics for one of three parameters. It doesn't explain what 'id' refers to (account identifier), what 'tenant_id' does (optional tenant context), or the structure/fields of the JSON definition. This leaves most parameter meaning undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and resource ('a mailer account'), making the purpose explicit. It distinguishes from siblings like 'cdp_create_mailer_account' (create vs update) and 'cdp_get_mailer_account' (read vs update). However, it doesn't specify what fields can be updated or the scope of changes, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing account ID), exclusions, or compare with similar tools like 'cdp_update_mailer_batch' or 'cdp_update_mailer_subuser'. The HTTP method hint (PUT) is technical but doesn't constitute usage guidance for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the HTTP endpoint and that the update definition should be a JSON string, but fails to disclose critical traits: whether this is a destructive mutation (implied by 'Update' but not explicit), authentication requirements, rate limits, error handling, or what constitutes a valid 'updated definition'. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences that directly address the tool's function and input format. It's front-loaded with the core purpose and avoids unnecessary verbiage. However, the inclusion of the HTTP endpoint (PUT /v2/{tenantId}/mailer/identifiers/{id}) is somewhat redundant for an AI agent that doesn't need low-level API details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (mutation operation with 3 parameters), lack of annotations, and 0% schema description coverage, the description is insufficiently complete. While an output schema exists (which relieves the need to describe return values), the description fails to compensate for missing behavioral context and parameter semantics. For a mutation tool in a system with many siblings, more guidance on usage and constraints is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the three parameters (id, body, tenant_id) have descriptions in the schema. The description only vaguely references 'updated definition as a JSON string' which partially relates to the 'body' parameter, but doesn't explain what 'id' refers to (e.g., identifier of the mailer to update), the optional 'tenant_id', or the structure/constraints of the JSON body. It adds minimal value beyond the bare parameter names 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 action ('Update') and resource ('a mailer identifier'), which provides a specific verb+resource combination. It distinguishes from siblings like 'cdp_create_mailer_identifier' and 'cdp_get_mailer_identifier' by focusing on modification rather than creation or retrieval. However, it doesn't explicitly differentiate from other update tools (e.g., 'cdp_update_mailer_account') beyond the resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing identifier), when-not-to-use scenarios, or comparisons to sibling tools like 'cdp_get_mailer_identifier' for reading or 'cdp_create_mailer_identifier' for creation. The HTTP method (PUT) is noted but doesn't constitute usage guidance for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that activation 'triggers the schedule's workflow action', implying a write/mutation operation, but doesn't specify side effects (e.g., whether this starts immediate execution, changes schedule state, or requires specific permissions). It lacks details on error conditions, rate limits, or what 'activate' means in this context beyond the high-level mechanism.
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 core action ('Activate a schedule'), followed by a clarifying sentence about the mechanism. There's no redundant information, and it avoids unnecessary elaboration. However, the second sentence could be more integrated or omitted if it doesn't add critical value, keeping it slightly from perfect conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is an output schema (which should cover return values), the description doesn't need to explain outputs. However, with no annotations, 0% schema description coverage, and three parameters (two required), the description is too sparse. It lacks context on prerequisites, side effects, and parameter meanings, making it incomplete for safe and effective use by an agent, though the existence of an output schema slightly mitigates this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the three parameters (workflow_id, schedule_id, tenant_id) have descriptions in the schema. The tool description adds no information about these parameters—it doesn't explain what they represent, their format, or how they relate to the activation process. This leaves the agent with only parameter names and types, which is insufficient for informed 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 action ('Activate a schedule') and specifies the mechanism ('triggers the schedule's workflow action via the workflow controller'), which distinguishes it from generic activation tools. However, it doesn't explicitly differentiate from its sibling 'cdp_deactivate_schedule' or other schedule-related tools like 'cdp_get_schedule' or 'cdp_update_schedule', which would be needed for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing schedule), conditions for activation, or when to choose this over similar tools like 'cdp_run_workflow' or 'cdp_invoke_workflow_action'. The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the return code ('Returns 204 on success'), which is helpful, but fails to describe error conditions, side effects (e.g., whether deletion is permanent), authentication requirements, or rate limits. For a destructive operation, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences that are front-loaded: the first states the action and parameters, and the second provides the success response. There is no wasted text, making it efficient and well-structured for its limited content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a destructive operation with 4 parameters (3 required) and 0% schema coverage, the description is insufficient. It lacks details on parameter meanings, error handling, and behavioral context. While an output schema exists (which may cover the 204 response), the description doesn't address the gaps in input understanding or usage guidance, making it incomplete for effective tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 4 parameters have descriptions in the schema. The description only mentions 'group and ID', covering 2 of the 4 parameters (cache_type and tenant_id are omitted). It doesn't explain what 'cache_type', 'group', 'id', or 'tenant_id' represent or their expected formats, failing 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.
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 cache entry') and identifies the required parameters ('by group and ID'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'cdp_cache_delete_by_id' or 'cdp_cache_delete_by_key', which would require mentioning the specific deletion method (group+ID vs. ID alone vs. key).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 'cdp_cache_delete_by_id' or 'cdp_cache_delete_by_key'. It lacks context about prerequisites, such as whether the cache entry must exist or if specific permissions are needed, offering minimal usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It mentions the action ('Delete') and success response ('Returns 204 on success'), but fails to disclose critical behavioral traits like permissions required, whether the deletion is irreversible, rate limits, or error conditions. This leaves significant gaps for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences that directly state the purpose and outcome. It is front-loaded with the core action and wastes no words, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 as a destructive operation with 3 parameters, 0% schema coverage, no annotations, and an output schema (implied by 'Returns 204'), the description is insufficient. It lacks details on parameters, behavioral context, and error handling, making it incomplete for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does not add any meaning beyond the schema, failing to explain what 'cache_type', 'cache_key', or 'tenant_id' represent, their formats, or examples. With 3 parameters and no semantic details, this is inadequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Delete') and resource ('a cache entry'), specifying it's done 'by explicit key'. It distinguishes from siblings like 'cdp_cache_delete_by_group' and 'cdp_cache_delete_by_id' by mentioning the key-based approach. However, it doesn't explicitly contrast with these siblings in the text, keeping it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'cdp_cache_delete_by_group' or 'cdp_cache_delete_by_id'. The description lacks context about prerequisites, such as needing to know the exact cache key, or any exclusions. It merely states what it does without usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Set or update a cache entry,' implying a write/mutation operation, but doesn't disclose behavioral traits such as permissions required, whether it overwrites existing entries, error handling (e.g., if ID doesn't exist), rate limits, or side effects. The auto-generated key detail is useful but insufficient for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with zero waste, front-loading the core purpose ('Set or update a cache entry by ID') and adding a key technical detail. Every word earns its place, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (mutation with 5 parameters, 0% schema coverage, no annotations), the description is inadequate. It lacks details on parameters, behavioral context (e.g., idempotency, errors), and usage guidelines, though the presence of an output schema means it needn't explain return values. For a cache write operation, this leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'ID' and implies 'cache entry' but doesn't explain the five parameters (cache_type, id, value, tenant_id, expiry_time) or their meanings (e.g., what cache_type values are valid, what format expiry_time uses). The description adds minimal value beyond the schema, failing to address the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set or update') and resource ('a cache entry by ID'), with the specific detail that 'The cache key is auto-generated.' This distinguishes it from sibling tools like 'cdp_cache_put_by_group' and 'cdp_cache_put_by_key', which likely use different key mechanisms, though it doesn't explicitly name these 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?
The description provides no guidance on when to use this tool versus alternatives like 'cdp_cache_put_by_group' or 'cdp_cache_put_by_key', nor does it mention prerequisites, error conditions, or typical use cases. It lacks explicit when/when-not instructions or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions that the value is stored as a string and that expiryTime is optional, which adds some behavioral context. However, it doesn't disclose critical traits like whether this is a mutation (implied by 'set or update'), permission requirements, rate limits, error handling, or what happens on conflicts (e.g., overwrites). For a mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded: two sentences that directly state the tool's function and a key parameter detail. Every sentence earns its place by providing essential information without waste, making it easy to parse quickly.
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 (mutation operation with 5 parameters), no annotations, and an output schema (which reduces need to describe returns), the description is incomplete. It lacks details on parameter meanings, behavioral traits like side effects or auth needs, and usage context. While the output schema helps, the description doesn't adequately cover the tool's full scope for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'Optional expiryTime in seconds', which adds meaning for one parameter (expiry_time). However, it doesn't explain the other four parameters (cache_type, cache_key, value, tenant_id), such as what cache_type represents, how cache_key is formatted, or the role of tenant_id. With 5 parameters and only one partially described, the description adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Set or update a cache entry by explicit key. Value is stored as a string.' It specifies the verb ('set or update'), resource ('cache entry'), and method ('by explicit key'), and distinguishes it from siblings like cdp_cache_put_by_group and cdp_cache_put_by_id by emphasizing 'by key'. However, it doesn't explicitly differentiate from cdp_cache_put_by_id, which might also use keys, so it's not fully sibling-distinctive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions 'Optional expiryTime in seconds' but doesn't specify when to use this over other cache tools like cdp_cache_put_by_group or cdp_cache_put_by_id, nor does it indicate prerequisites or exclusions. Usage is implied only by the name and description, with no explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states it 'creates' without behavioral details. It doesn't disclose if this is a mutating operation, what permissions are required, whether it's asynchronous, or what the output contains. The mention of 'JSON string' for request details is minimal context but insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two short sentences that are front-loaded and waste no words. Every part ('Create a new compaction request' and 'Pass request details as a JSON string') directly contributes to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 annotations, 0% schema description coverage, and an output schema (which helps but isn't described), the description is incomplete. It lacks details on behavior, parameter usage, and context, making it inadequate for safe and effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but only vaguely mentions 'request details as a JSON string' for the 'body' parameter. It doesn't explain what 'tenant_id' is for, the structure of the JSON, or any constraints. With 2 parameters and no schema descriptions, this adds minimal value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a new compaction request') and resource ('compaction request'), making the purpose understandable. It doesn't explicitly differentiate from sibling tools like 'cdp_list_compaction_requests' or 'cdp_unschedule_compaction_request', but the verb 'create' is distinct enough from 'list' and 'unschedule' 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, when compaction requests are needed, or what happens after creation. The sibling list includes 'cdp_list_compaction_requests' and 'cdp_unschedule_compaction_request', but no comparison is made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It implies a write operation ('Create') but does not specify required permissions, whether the operation is idempotent, potential side effects, or error handling. The mention of 'JSON string' hints at input format but lacks details on validation or response structure, leaving significant gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, stating the purpose in the first sentence and following with parameter details. It avoids redundancy and uses clear language, though it could be slightly more structured by separating usage notes from parameter explanations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is an output schema (which handles return values) but no annotations and low parameter coverage, the description partially compensates by detailing the 'body' parameter. However, it fails to cover 'tenant_id', provide behavioral context, or differentiate from siblings, making it incomplete for safe and effective tool invocation by an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains that 'body' should be a 'JSON string' with specific fields (name, description, widgets array, layout), adding meaningful context beyond the schema's generic 'string' type. However, it does not address the 'tenant_id' parameter at all, leaving half of the parameters undocumented and reducing overall effectiveness.
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 a new dashboard') and specifies the resource ('dashboard'), which distinguishes it from siblings like 'cdp_update_dashboard' or 'cdp_copy_dashboard'. However, it does not explicitly differentiate from 'cdp_clone_resource' or 'cdp_create_widget', which might create ambiguity in a broader context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'cdp_update_dashboard' for modifications or 'cdp_copy_dashboard' for duplication. It mentions optional fields but lacks context on prerequisites, permissions, or typical use cases, leaving the agent with minimal direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but lacks behavioral details. It states 'Create' (implying a write/mutation) but doesn't disclose permissions needed, whether it's idempotent, rate limits, or what happens on failure. The mention of 'POST' hints at HTTP method but doesn't add meaningful operational context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences that directly state the action and parameter format. It's front-loaded with the main purpose, though the API endpoint detail might be redundant if the agent already has structured endpoint info. No wasted words, but could be more informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 parameters with 0% schema coverage, no annotations, and an output schema (which reduces need to describe returns), the description is minimally adequate. It covers the basic action and hints at parameter format but lacks details on permissions, error handling, or full parameter semantics, leaving gaps for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds minimal param semantics. It mentions 'page definition as a JSON string' for the 'body' parameter, giving some context, but doesn't explain the structure or content of the JSON. The 'tenant_id' parameter is not addressed at all, leaving its purpose and usage unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create an emailable page') and resource ('emailable page'), making the purpose understandable. It distinguishes from siblings like 'cdp_get_emailable_page' or 'cdp_delete_emailable_page' by specifying creation, but doesn't explicitly differentiate from other 'create' tools (e.g., 'cdp_create_campaign') 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 is provided on when to use this tool versus alternatives. The description mentions the API endpoint but doesn't indicate prerequisites, typical use cases, or when to choose this over other creation tools in the sibling list. Usage context is implied only by the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Create' which implies a write operation, but doesn't disclose behavioral traits like required permissions, whether it's idempotent, what happens on failure, or typical response structure. The mention of 'POST /v2/{tenantId}/mailer/accounts' adds some API context but lacks operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and to the point with two clear pieces of information: what it does and how to pass data. No unnecessary words, though it could be more structured. The HTTP method and endpoint are useful but could be better integrated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there's an output schema (which reduces need to describe returns) but no annotations and 0% schema coverage, the description is minimally adequate. It covers the basic purpose and data format but lacks details about parameters, behavior, and usage context that would help an agent use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions passing 'the definition as a JSON string' which clarifies the 'body' parameter, but doesn't explain what should be in that JSON or the purpose of 'tenant_id'. With 2 parameters and no schema descriptions, this leaves significant gaps in understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and resource ('mailer account'), and mentions the HTTP method and endpoint path. It distinguishes from siblings like 'cdp_update_mailer_account' by specifying creation rather than update, though it doesn't explicitly differentiate from other creation tools like 'cdp_create_mailer_subuser'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 is provided. The description doesn't mention prerequisites, dependencies, or typical use cases. Sibling tools include other mailer-related creation tools, but no comparison or context 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?
No annotations are provided, so the description carries full burden. It states 'Create' implying a write/mutation operation, but doesn't disclose behavioral traits like required permissions, whether the identifier is persistent, rate limits, or what the response contains. The mention of 'POST /v2/{tenantId}/mailer/identifiers' hints at an API call but lacks operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the core action. The two sentences are efficient, but the second sentence could be more informative (e.g., explaining the JSON structure). No wasted words, though it risks under-specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 parameters with 0% schema coverage, no annotations, and an output schema (which reduces need to describe returns), the description is minimally adequate. It covers the basic purpose and parameter format but lacks details on usage, behavior, and full parameter semantics. For a creation tool in a complex system, more context would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'Pass the definition as a JSON string' for the 'body' parameter, adding some meaning beyond the schema's generic 'string' type. However, it doesn't explain the structure or content of the JSON, and ignores the 'tenant_id' parameter entirely. With 2 parameters and low coverage, this is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and resource ('mailer identifier'), and specifies the HTTP method and endpoint. It distinguishes from siblings like 'cdp_get_mailer_identifier' (read) and 'cdp_update_mailer_identifier' (update), but doesn't explicitly differentiate from other 'create' tools like 'cdp_create_mailer_account' or 'cdp_create_mailer_batch' 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 is provided. The description mentions the endpoint but doesn't explain prerequisites, when this operation is needed, or what happens after creation. With many sibling tools (e.g., 'cdp_create_mailer_account', 'cdp_create_mailer_batch'), there's no context for choosing among them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it's a creation tool (implying mutation) and mentions the HTTP method (POST), which is helpful. However, it lacks critical behavioral details: required permissions, whether the operation is idempotent, rate limits, error handling, or what the output contains. For a mutation tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose. It's efficient with zero wasted words. The inclusion of the API endpoint in parentheses is slightly technical but not excessive. It could be slightly improved by integrating the endpoint info more seamlessly, but it's 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 the complexity (mutation tool with 2 parameters, 0% schema coverage, no annotations, but has output schema), the description is minimally adequate. The output schema existence means return values are documented elsewhere, reducing the burden. However, for a creation tool, it should better explain parameters and behavioral context. It meets a baseline but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'Pass the full definition as a JSON string', which clarifies the 'body' parameter's purpose and format. However, it doesn't explain the 'tenant_id' parameter (optional, default null) or provide examples of the JSON structure. With 2 parameters and low schema coverage, the description adds some value but leaves significant gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a new prediction definition') and resource ('prediction definition'), which is specific and understandable. It distinguishes from siblings like 'cdp_clone_prediction' or 'cdp_update_prediction' by focusing on creation. However, it doesn't explicitly differentiate from other 'create' tools (e.g., 'cdp_create_campaign'), so it's not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a tenant ID), when not to use it (e.g., for updates), or refer to sibling tools like 'cdp_clone_prediction' or 'cdp_update_prediction'. The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the action is a POST request, implying a write operation, but doesn't cover critical aspects like required permissions, whether provisioning is reversible, rate limits, expected response format, or error conditions. For a creation tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences that directly address the tool's function and parameter format. It's front-loaded with the main purpose and avoids unnecessary verbiage. However, the 'etc.' could be more precise to improve clarity without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which reduces need to describe return values) but no annotations and 0% schema description coverage, the description is minimally adequate. It covers the basic purpose and parameter format but lacks behavioral context, usage guidelines, and complete parameter documentation. For a creation tool in a complex system, this leaves important gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'request body as JSON string with serviceId, provisionName, etc.' which adds some meaning for the 'body' parameter, but doesn't explain the 'tenant_id' parameter at all. The 'etc.' is vague and doesn't provide complete parameter documentation, failing to fully compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Provision a new instance') and specifies the resource ('instance'), which is a specific verb+resource combination. It distinguishes from siblings like 'cdp_get_provision_instance' (read) and 'cdp_update_provision_instance' (update), but doesn't explicitly contrast with other provisioning tools like 'cdp_deprovision_instance' or 'cdp_retry_provision_instance'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, when not to use it, or compare with sibling tools like 'cdp_retry_provision_instance' or 'cdp_update_provision_instance'. The only implied context is the HTTP method (POST), which is insufficient for usage decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states 'Create' implying a write operation, but lacks details on permissions, side effects (e.g., if it sends notifications), rate limits, or error handling. This is a significant gap for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences, front-loading the core purpose and key requirements. Every word earns its place, with no redundant or verbose language.
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 a user creation tool with 5 parameters, 0% schema coverage, no annotations, and an output schema (which reduces need for return value explanation), the description is incomplete. It lacks behavioral context, full parameter guidance, and usage distinctions, making it inadequate for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'userName and password' as required, covering 2 of 5 parameters, but ignores 'tenant_id', 'first_name', and 'last_name'. This leaves most parameters undocumented, failing to add sufficient 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 ('Create') and resource ('new CDP user'), making the purpose explicit. It distinguishes from sibling tools like 'cdp_create_selfservice_user' by specifying a general user creation, though it doesn't explicitly contrast with other user-related tools like 'cdp_update_user' or 'cdp_delete_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?
The description mentions 'Requires userName and password,' which hints at prerequisites but doesn't provide guidance on when to use this tool versus alternatives like 'cdp_create_selfservice_user' or 'cdp_update_user.' No explicit when/when-not scenarios or sibling tool comparisons are included.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'Admin-only' (permission requirement) and that it's an override operation, but doesn't disclose critical behavioral traits like whether this is a destructive/mutative action, what the override payload structure should be, rate limits, or what happens to the original request. The description is insufficient for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with only two sentences that each serve distinct purposes: establishing admin permissions/purpose and specifying parameter format. Zero wasted words 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?
For a mutation tool with 2 parameters (0% schema coverage), no annotations, and an output schema (which helps but doesn't excuse the description), the description is inadequate. It lacks essential context about the override operation's behavior, payload structure, security implications, and relationship to sibling tools. The presence of an output schema doesn't compensate for these gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'Pass override payload as JSON string' which partially explains the 'body' parameter, but doesn't clarify what the payload should contain or provide any information about the 'tenant_id' parameter. The description adds minimal value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'override the status of a data erasure request' with the specific HTTP method 'POST /dw/dataerasure/admin?action=statusoverride'. It distinguishes from siblings like 'cdp_get_data_erasure_status' (read) and 'cdp_update_data_erasure_request' (update), but doesn't explicitly contrast with 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 minimal guidance: 'Admin-only' indicates a permission requirement, but doesn't specify when to use this tool versus alternatives like 'cdp_update_data_erasure_request' or 'cdp_get_data_erasure_status'. No explicit 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action is a DELETE operation, implying a destructive mutation, but doesn't specify effects (e.g., data loss, state changes), permissions required, or error handling. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words, front-loading the core action. It's 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a destructive mutation tool with 2 parameters (0% schema coverage), no annotations, and an output schema (which might cover return values), the description is incomplete. It lacks parameter explanations, behavioral details, and usage context, making it inadequate for safe and correct tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter details. The description mentions no parameters, failing to explain what 'instance_id' or 'tenant_id' represent, their formats, or how they affect the operation. It doesn't compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Deactivate') and resource ('a provisioned instance'), making the purpose specific and understandable. It distinguishes from siblings like 'cdp_deprovision_instance' by focusing on deactivation rather than full deprovisioning, though it doesn't explicitly compare 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 alternatives like 'cdp_deprovision_instance' or 'cdp_reactivate_provision_instance', nor does it mention prerequisites or context for deactivation. It lacks explicit usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Delete', implying a destructive mutation, but fails to disclose critical behavioral traits: whether deletion is permanent or reversible, required permissions, side effects (e.g., impact on related resources), or error handling. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It is appropriately sized and front-loaded, directly stating the tool's purpose without unnecessary elaboration, making it easy to parse quickly.
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 (a destructive mutation), lack of annotations, 0% schema coverage, and presence of an output schema (which the description doesn't reference), the description is incomplete. It should address behavioral risks, parameter meanings, and output expectations to be adequate for safe use by an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning parameters are undocumented in the schema. The description adds no information about parameters beyond what's implied by the tool name (e.g., 'rule_id' is needed). It doesn't explain the purpose of 'tenant_id' or its default behavior, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and resource ('an A360 rule'), providing a specific verb+resource combination. It distinguishes from siblings like 'cdp_get_a360_rule' and 'cdp_update_a360_rule' by specifying the destructive operation. However, it doesn't elaborate on what 'A360 rule' entails beyond the name, keeping it slightly less specific than ideal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description lacks context such as prerequisites (e.g., needing an existing rule ID), when not to use it (e.g., if the rule is active), or explicit alternatives like 'cdp_deactivate_schedule' for similar operations. This leaves the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the action without behavioral details. It doesn't disclose if deletion is permanent/reversible, requires specific permissions, has side effects (e.g., cascading deletions), rate limits, or error conditions. 'Delete' implies destructive, but lacks context needed for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with zero wasted words. It's front-loaded with the core action and resource, making it efficient for quick scanning. No structural issues or redundancy are present.
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 destructive tool with 2 parameters (0% schema coverage), no annotations, and an output schema (unknown content), the description is inadequate. It lacks critical context: parameter details, behavioral traits (permanence, permissions), usage prerequisites, and output expectations. The presence of an output schema doesn't compensate for missing safety and invocation guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so parameters are undocumented in schema. The description mentions 'by ID' which hints at campaign_id but doesn't explain its format or source. It completely omits tenant_id (optional parameter), leaving its purpose and when to use it unclear. The description adds minimal value beyond the parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and resource ('a campaign definition by ID'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling deletion tools (like cdp_delete_audience_def or cdp_delete_dashboard), but the resource specificity is adequate for basic 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 is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., needing campaign_id), exclusions (e.g., cannot delete active campaigns), or sibling tools for related operations (like cdp_get_campaign to verify existence first).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Delete' implies a destructive mutation, the description doesn't specify whether this action is reversible, what permissions are required, if it cascades to dependent resources, or what the output contains. For a destructive tool with zero annotation coverage, this is a significant gap in safety and operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with zero wasted words. It's front-loaded with the core action and resource, making it immediately scannable. Every word earns its place, though this conciseness comes at the cost of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive mutation tool with 2 parameters (one required), 0% schema description coverage, no annotations, and an output schema (which isn't described), the description is inadequate. It doesn't explain the deletion's impact, parameter meanings, or what to expect in return. The presence of an output schema slightly mitigates the need to describe return values, but the overall context for safe and correct usage is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning parameter titles ('Connector Def Id', 'Tenant Id') are the only documentation. The description adds no semantic context about what these parameters represent (e.g., that connector_def_id identifies the template to delete, or that tenant_id might be optional for multi-tenant contexts). With two parameters and no schema descriptions, the description fails to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a connector definition' clearly states the verb (delete) and resource (connector definition), making the purpose immediately understandable. It distinguishes from siblings like 'cdp_delete_connector' (which deletes a connector instance) and 'cdp_create_connector_template' (which creates one), though it doesn't explicitly mention this differentiation in the text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a valid connector_def_id), consequences of deletion, or when to choose this over other deletion tools like 'cdp_delete_connector'. The agent must infer usage from the name and schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It indicates a destructive operation ('Delete'), but does not specify permissions required, whether the deletion is reversible, side effects, rate limits, or error handling. This is a significant gap for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste—it directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 as a destructive operation, lack of annotations, 0% schema description coverage, and presence of an output schema (which the description does not reference), the description is incomplete. It fails to address critical aspects like behavioral risks, parameter meanings, or output expectations, leaving the agent with insufficient context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning parameters are undocumented in the schema. The description mentions 'by ID', which hints at the 'cubic_set_def_id' parameter, but does not explain the 'tenant_id' parameter or provide any details on data types, constraints, or usage. It adds minimal value beyond the schema's property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and the resource ('a CubicSetDef by ID'), providing a specific verb+resource combination. However, it does not distinguish this tool from other delete operations on the server (e.g., cdp_delete_campaign, cdp_delete_dashboard), which are numerous and similar in structure, so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, prerequisites, or exclusions. It simply states what the tool does without context, leaving the agent to infer usage from the tool name and schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Delete' implies a destructive mutation, but the description doesn't disclose critical behavioral traits: whether deletion is permanent/reversible, what permissions are required, if it affects related resources, rate limits, or what the output contains. This is inadequate for a destructive operation with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place, though this conciseness comes at the cost of detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a destructive delete operation, 0% schema coverage, no annotations, and the presence of an output schema (which isn't described), the description is incomplete. It lacks essential context about behavior, parameters, and usage, making it insufficient for safe and effective tool invocation by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description adds no information about the two parameters (dispatch_id and tenant_id) beyond what's inferred from their names. It doesn't explain what a dispatch ID is, how to obtain it, or when tenant_id is needed. The description fails to compensate for the schema's lack of documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a dispatch definition' clearly states the verb ('Delete') and resource ('dispatch definition'), making the purpose immediately understandable. It distinguishes from siblings like 'cdp_update_dispatch' (update) and 'cdp_get_dispatch' (read), but doesn't specify what a 'dispatch definition' is or how it differs from other deletable resources like campaigns or audiences.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., needing the dispatch ID), what happens after deletion, or whether there are sibling tools for related operations like listing dispatches first. It's a basic statement without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It reveals this is a 'soft-delete' operation (not permanent deletion), which is valuable context beyond the name. However, it doesn't disclose important behavioral traits like required permissions, whether the operation is reversible, what happens to associated data, or any rate limits. For a destructive operation with zero annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single sentence that states the core purpose. It's front-loaded with the key action ('Soft-delete') and includes the API endpoint for technical context. Every word earns its place with zero waste or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no annotations, 0% schema description coverage, and 2 parameters, the description is incomplete. While an output schema exists (which helps), the description doesn't address critical context: what 'soft-delete' means operationally, prerequisites, side effects, or error conditions. Given the complexity of a delete operation and poor schema documentation, the description should provide more guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. The description mentions no parameters at all - it doesn't explain what 'id' represents (subuser identifier) or when 'tenant_id' is needed versus optional. With 2 parameters completely undocumented in both schema and description, the description adds no parameter semantics 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 the action ('Soft-delete') and resource ('a mailer subuser'), providing specific verb+resource pairing. It distinguishes from siblings like 'cdp_delete_mailer_account' by specifying the subuser resource type. However, it doesn't explicitly differentiate from 'cdp_restore_mailer_subuser' which handles restoration of soft-deleted items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when soft-delete is appropriate versus hard delete, nor does it reference sibling tools like 'cdp_restore_mailer_subuser' for undoing this operation or 'cdp_delete_mailer_account' for different resource types. The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool deletes a report definition, implying a destructive mutation, but fails to mention critical details such as permissions required, whether deletion is permanent or reversible, side effects (e.g., impact on related schedules or data), or rate limits. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It is front-loaded with the core action and resource, making it highly concise and well-structured for quick understanding.
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 (destructive mutation with 2 parameters), lack of annotations, 0% schema coverage, and presence of an output schema (which might cover return values), the description is incomplete. It omits behavioral traits, parameter details beyond the ID, and usage context, making it inadequate for safe and effective tool invocation by an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning parameters 'report_def_id' and 'tenant_id' are undocumented in the schema. The description only mentions 'by ID', which partially explains 'report_def_id' but ignores 'tenant_id' entirely. It adds minimal value beyond the schema, failing to compensate for the coverage gap, especially for the optional tenant 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 the action ('Delete') and the resource ('a report definition by ID'), providing a specific verb+resource combination. It distinguishes itself from siblings like 'cdp_copy_report_def' or 'cdp_update_report_def' by focusing on deletion, though it doesn't explicitly contrast with other deletion tools (e.g., 'cdp_delete_dashboard').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description lacks context about prerequisites (e.g., needing an existing report definition ID), exclusions, or comparisons to similar tools like 'cdp_delete_data_export' or 'cdp_delete_widget', leaving the agent without 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Delete' implies a destructive mutation, the description doesn't specify whether this action is permanent, requires specific permissions, has side effects, or returns confirmation data. For a deletion tool with zero annotation coverage, this leaves critical behavioral aspects unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with zero wasted words. It's appropriately front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place in conveying the essential 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?
For a deletion tool with 2 parameters (one required, one optional), 0% schema description coverage, no annotations, and an output schema (which might help but isn't described), the description is inadequate. It lacks context about parameters, behavioral implications, error conditions, and usage prerequisites, leaving significant gaps for safe and correct tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning parameter titles ('Squery Def Id', 'Tenant Id') provide minimal semantic context. The description only mentions 'by ID,' which corresponds to the required 'squery_def_id' parameter but adds no detail about format, validation, or purpose. It completely ignores the optional 'tenant_id' parameter, failing to compensate for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and resource ('a SQueryDef by ID'), making the purpose immediately understandable. However, it doesn't distinguish this tool from other delete operations in the sibling list (like cdp_delete_campaign, cdp_delete_user, etc.), which all follow the same 'Delete X by ID' pattern.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. The description doesn't mention prerequisites (like needing the SQueryDef ID), what happens after deletion, or whether there are recovery options. Given the destructive nature implied by 'Delete,' this lack of usage context is problematic.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Delete' implies a destructive mutation, but the description doesn't specify whether deletion is permanent, requires specific permissions, has side effects (e.g., cascading deletions), or provides confirmation. For a destructive tool with zero annotation coverage, this is a significant gap in behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized for a simple deletion operation and front-loads the core action. Every word earns its place in conveying the essential function.
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 destructive mutation tool with no annotations, 0% schema description coverage, and an output schema (which helps but isn't described), the description is inadequate. It lacks critical information about behavioral traits, parameter meanings beyond basics, and usage context. The presence of an output schema reduces the need to describe return values, but other gaps remain significant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'by ID' which maps to the 'widget_id' parameter, but doesn't explain the 'tenant_id' parameter (optional, can be null) or provide any format/validation details. The description adds minimal value beyond what's implied by the parameter names 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 'Delete a widget by ID' clearly states the action (delete) and target resource (widget), with the specific identifier method (by ID). It distinguishes from sibling tools like 'cdp_get_widget' (read) and 'cdp_update_widget' (modify), but doesn't explicitly differentiate from other deletion tools like 'cdp_delete_dashboard' or 'cdp_delete_report_def' beyond 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?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., needing widget existence), consequences (e.g., irreversible deletion), or when to choose other deletion tools for different resources. It's a bare statement of function with no contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is a 'Get' operation, implying read-only behavior, but doesn't cover authentication needs, rate limits, error conditions, pagination, or what the output contains. For a tool with 3 parameters and no annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the core purpose. Both sentences are relevant, though the second sentence could be integrated more smoothly. There's no unnecessary verbiage, making it efficient despite the gaps in content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters with 0% schema coverage, no annotations, but an output schema exists, the description is minimally adequate. The output schema likely covers return values, reducing the burden, but the description lacks context on authentication, errors, and parameter details. It meets a basic threshold but has clear gaps for a tool in this context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only mentions the 'body' parameter ('Pass customer IDs as a JSON string body'), leaving 'resource_name' and 'tenant_id' completely unexplained. The description adds minimal value beyond what the schema's property names suggest, failing to adequately cover the 3 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('identities associated with given customer IDs'), making the purpose understandable. It doesn't explicitly distinguish from siblings like 'cdp_get_customer_360' or 'cdp_get_customer_360_detail', but the focus on identities is specific enough for basic 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 is provided on when to use this tool versus alternatives. The description mentions passing customer IDs as a JSON string body, but this is a parameter instruction rather than usage context. There's no mention of prerequisites, typical use cases, or comparison to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states a read operation ('List') but doesn't mention authentication needs, rate limits, pagination behavior (though offset/limit parameters suggest pagination), error conditions, or what the output contains. This leaves significant gaps for a tool that likely involves sensitive data erasure statuses.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. It's appropriately sized for a listing tool, though its brevity contributes to gaps in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (listing operation with pagination parameters), no annotations, and an output schema (which reduces need to describe returns), the description is incomplete. It covers the basic purpose but lacks parameter explanations, usage context, and behavioral details needed for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the three parameters (tenant_id, offset, limit) are documented in the schema. The description doesn't mention any parameters or their semantics, failing to compensate for the lack of schema documentation. This leaves the agent guessing about parameter purposes and 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 verb ('List') and resource ('data erasure request statuses') with scope ('for a tenant'), making the purpose specific and understandable. However, it doesn't explicitly distinguish this tool from its sibling 'cdp_get_data_erasure_status_by_id', which appears to fetch a single status by ID rather than listing all.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 'cdp_get_data_erasure_status_by_id' or other data-related tools. The description implies usage for listing statuses but lacks context on prerequisites, typical scenarios, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool is a lookup operation, implying it is read-only and non-destructive, but does not explicitly confirm this or address other behavioral traits like authentication needs, rate limits, error handling, or response format. For a tool with zero annotation coverage, this leaves significant gaps in understanding its operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, stating the core purpose in the first phrase. The inclusion of the API endpoint path adds technical context without unnecessary verbosity. However, the URL could be considered slightly redundant if the tool name already implies the operation, but it does not detract significantly from clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, 0% schema coverage, no annotations, but with an output schema), the description is minimally adequate. It identifies the tool as a lookup operation and hints at key parameters, but lacks details on usage guidelines, behavioral transparency, and parameter semantics. The presence of an output schema mitigates some gaps by likely defining return values, but the overall description remains incomplete for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning no parameters are documented in the schema. The description mentions 'campaign + dispatch' and includes a URL path with placeholders for 'campaignId' and 'dispatchId', which hints at two required parameters. However, it does not explain the optional 'tenant_id' parameter or provide any semantic details about parameter formats, constraints, or relationships. 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.
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: 'Look up a mailer identifier by campaign + dispatch.' It specifies the verb ('look up'), resource ('mailer identifier'), and key identifiers ('campaign + dispatch'), making the action distinct. However, it does not explicitly differentiate from sibling tools like 'cdp_get_mailer_identifier' or 'cdp_list_mailer_identifiers', which might serve similar purposes but with different parameters or scopes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It lacks context such as prerequisites, when-not-to-use scenarios, or comparisons with sibling tools like 'cdp_get_mailer_identifier' or 'cdp_list_mailer_identifiers'. The agent must infer usage solely from the name and parameters, which is insufficient for informed tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states this is a GET operation (implying read-only), but doesn't disclose behavioral traits such as authentication requirements, rate limits, error responses, or whether it returns full or partial prediction definition data. The HTTP endpoint hint is minimal and doesn't add meaningful operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. The parenthetical HTTP endpoint adds technical detail without verbosity, though it could be considered slightly redundant if the tool name already implies a GET operation. No wasted words, but could benefit from slightly more context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which likely describes the return structure), the description doesn't need to detail return values. However, with no annotations, 0% schema description coverage, and two parameters (one required, one optional with null default), the description is too sparse. It should at least clarify parameter roles and basic usage context to compensate for the lack of structured documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description mentions 'by ID' which loosely maps to 'prediction_def_id', but doesn't explain what this ID is, its format, or where to obtain it. It doesn't address 'tenant_id' at all, leaving its purpose and handling (nullable default) unexplained. The description adds minimal value beyond the bare parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('specific prediction definition by ID'), making the purpose understandable. It distinguishes from siblings like 'cdp_list_predictions' (which lists multiple) by specifying retrieval of a single item by ID. However, it doesn't explicitly mention what a 'prediction definition' entails in this context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. While the description implies it's for retrieving a specific prediction by ID, it doesn't mention prerequisites (e.g., needing a valid prediction_def_id), contrast with 'cdp_list_predictions' for browsing, or specify error conditions like handling invalid IDs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers little behavioral insight. It states it 'gets' data (implying read-only), but doesn't disclose authentication needs, rate limits, error conditions, or what 'prediction result' entails. The mention of 'other query params' is vague and unhelpful for understanding 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 brief (two sentences) and front-loaded with the core purpose. However, the second sentence about optional parameters is somewhat vague ('other query params' adds little value). Overall, it avoids unnecessary verbosity but could be more precise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters with 0% schema coverage, no annotations, but an output schema exists, the description is minimally adequate. It identifies the tool's purpose but lacks details on parameter usage, behavioral constraints, and sibling differentiation. The output schema mitigates the need to describe return values, but other gaps remain significant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds minimal value. It mentions 'container_code' (implied required) and 'pid' as optional, but doesn't explain what a container code is, format expectations, or what 'other query params' might be. The two other parameters (tenant_id, pid) lack meaningful context beyond their names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('prediction result'), specifying it's retrieved 'by container code'. It distinguishes from siblings like 'cdp_get_prediction' (which likely retrieves by prediction ID) by focusing on container-based retrieval. However, it doesn't explicitly contrast with all similar 'get' tools in the extensive 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?
The description provides minimal guidance: it mentions optional parameters like 'pid (person ID) and other query params', but gives no context on when to use this tool versus alternatives like 'cdp_get_prediction' or 'cdp_list_predictions'. There's no mention of prerequisites, typical use cases, or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. 'Kill' implies a destructive, irreversible action that terminates execution, but the description doesn't explicitly state this, nor does it mention permissions required, side effects, or what happens to job data. For a mutation tool with zero annotation coverage, this leaves critical behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action and target, making it immediately understandable despite its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive mutation tool with 3 parameters (0% schema coverage), no annotations, and an output schema (which helps but doesn't replace description), the description is inadequate. It lacks behavioral context, parameter details, usage guidelines, and doesn't address the tool's impact or requirements, leaving the agent poorly equipped to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so parameters are undocumented in the schema. The description adds no parameter information beyond what's implied by the name (workflow_id and job_id). It doesn't explain the optional tenant_id parameter or provide format/context for any parameters, failing to compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Kill a running workflow job' clearly states the action (kill) and target (running workflow job). It distinguishes from siblings like cdp_suspend_job (which pauses rather than terminates) and cdp_rerun_job (which restarts). However, it doesn't explicitly mention the destructive nature or that it terminates execution, which would make it a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like cdp_suspend_job (pause) or cdp_rerun_job (restart). It doesn't mention prerequisites (e.g., job must be running) or consequences (e.g., irreversible termination). The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states a read operation ('List'), implying it's non-destructive, but fails to mention any behavioral traits like pagination (suggested by offset/limit parameters), authentication requirements, rate limits, or return format. This leaves significant gaps for a tool with parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words, making it highly concise and front-loaded. It efficiently conveys the core purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters with 0% schema coverage, no annotations, and an output schema (which helps but isn't described), the description is incomplete. It lacks parameter explanations, behavioral context, and usage guidelines, making it inadequate for effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter details. The description does not mention any parameters, failing to explain the purpose of 'tenant_id', 'offset', or 'limit'. This lack of semantic information makes it hard to understand how to use the tool effectively.
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') and resource ('all OAuth clients for a tenant'), making the purpose specific and understandable. However, it does not explicitly differentiate from sibling tools like 'cdp_get_client' or 'cdp_list_tenants', which slightly limits its clarity in a crowded toolset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 'cdp_get_client' for single client details or 'cdp_list_tenants' for listing tenants. It lacks context on prerequisites, exclusions, or typical use cases, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states a read operation ('List'), implying it's non-destructive, but doesn't disclose behavioral traits like pagination, rate limits, authentication requirements, or error conditions. For a listing tool with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves in practice.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core action ('List column validators'), making it easy to scan. No extraneous information or redundancy is present, which is ideal for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one optional parameter) and the presence of an output schema (which handles return values), the description is minimally adequate. However, with no annotations and 0% schema coverage, it should do more to explain the parameter's role and usage context. It's complete enough for basic understanding but lacks depth for reliable agent 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 description mentions 'for a tenant', which aligns with the 'tenant_id' parameter in the schema. However, schema description coverage is 0%, and the description doesn't add meaning beyond the parameter name—it doesn't explain what 'tenant' means, whether the ID is optional (it has a default of null), or what happens if omitted. With one parameter and low schema coverage, the description provides minimal compensation.
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 'List column validators for a tenant' clearly states the verb ('List') and resource ('column validators'), but it's vague about scope and format. It doesn't specify whether this lists all validators globally or filtered ones, or what information is returned. Compared to siblings like 'cdp_get_column_validator' (singular retrieval), it distinguishes as a listing operation, but lacks specificity about the listing's nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., authentication), when to prefer this over other listing tools (like 'cdp_list_audience_defs'), or any constraints. The agent must infer usage from the name alone, which is insufficient for effective tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions listing but fails to describe key traits like whether it's a read-only operation (implied by 'List'), pagination behavior, rate limits, authentication requirements, or error handling. This leaves significant gaps for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words, making it highly concise and front-loaded. It efficiently communicates the core action without unnecessary elaboration, which is appropriate for a simple list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one optional parameter) and the presence of an output schema (which handles return values), the description is minimally adequate. However, with no annotations and 0% schema coverage, it lacks context on behavioral aspects like safety or performance, making it incomplete for full 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?
The description mentions 'for a tenant', which aligns with the 'tenant_id' parameter in the schema. However, schema description coverage is 0%, and the description does not add details like parameter format, optionality (it's optional with default null), or what happens if omitted. With one parameter and low schema coverage, the description provides minimal semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb ('List') and resource ('mapping templates for a tenant'), which clarifies the basic action. However, it lacks specificity about what 'mapping templates' are in this context (e.g., data mappings, workflow templates) and does not differentiate from sibling tools like 'cdp_get_mapping_template' (singular) or other list tools, leaving the purpose somewhat 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?
The description provides no guidance on when to use this tool versus alternatives, such as 'cdp_get_mapping_template' for a single template or other list tools for different resources. It also omits prerequisites like authentication or tenant context, offering no usage context beyond the basic action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states this is a list operation (GET endpoint) and mentions it returns runs and their state, but doesn't disclose critical behavioral traits like whether it's paginated (though parameters suggest it might be), rate limits, authentication requirements, error conditions, or what 'orchestration statuses' specifically entail. The description adds minimal value beyond the basic operation type.
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 appropriately concise with two sentences that directly state the tool's purpose and what it returns. It's front-loaded with the core action ('List orchestration statuses') and avoids unnecessary words, though it could be slightly more structured by explicitly mentioning it's a paginated list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which likely describes the return structure), the description doesn't need to detail return values. However, for a list operation with 3 parameters and no annotations, the description is incomplete: it lacks parameter semantics, usage context, and behavioral details like pagination or scoping. It's minimally adequate but has clear gaps in guiding effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description doesn't mention any parameters at all, failing to compensate for the coverage gap. It doesn't explain what 'tenant_id', 'offset', or 'limit' mean in the context of listing orchestration statuses, leaving all three parameters undocumented in meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List orchestration statuses' with the specific resource being 'workflow/connector orchestration runs and their state.' It uses a specific verb ('List') and identifies the resource, but doesn't explicitly differentiate from sibling tools like 'cdp_get_orchestration_status' or 'cdp_get_orchestration_status_for_connector' beyond implying a list vs. get 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. It doesn't mention sibling tools like 'cdp_get_orchestration_status' (which appears to fetch a single status) or 'cdp_get_orchestration_status_for_connector' (which seems connector-specific), nor does it specify any prerequisites, contexts, or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It mentions 'paged' (implying pagination) but fails to disclose critical details like required permissions, rate limits, error handling, or whether it's a read-only operation. For a list tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. It avoids redundancy and wastes no words, making it easy to parse quickly while conveying key information like pagination.
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 (3 parameters, no annotations, 0% schema coverage) and the presence of an output schema, the description is incomplete. It lacks parameter explanations, behavioral context, and usage guidelines. While the output schema may cover return values, the description does not provide enough context for effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so parameters are undocumented in the schema. The description adds no information about the three parameters (tenant_id, offset, limit), such as their purposes, formats, or constraints. It does not compensate for the lack of schema documentation, leaving parameters ambiguous.
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') and resource ('available provision services for a tenant'), making the purpose evident. It distinguishes from siblings like 'cdp_list_provision_instances' by specifying 'services' rather than 'instances', though it could be more explicit about the distinction. It avoids tautology by not merely restating the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance, mentioning 'for a tenant' and 'paged', but lacks explicit when-to-use instructions, prerequisites, or alternatives. It does not clarify when to choose this over similar list tools (e.g., 'cdp_list_provision_instances') or address edge cases like tenant selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It implies a read-only operation via 'List' and the GET method, but doesn't disclose behavioral traits such as pagination, rate limits, authentication requirements, or what 'unlinked' means in context. The description adds minimal context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. It includes the API endpoint, which adds technical context without unnecessary verbosity. Every part serves a purpose, though it could be slightly more structured 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 3 parameters with 0% schema coverage, no annotations, and an output schema present, the description is minimally adequate. It covers the basic action and key parameters but lacks details on usage, behavior, and parameter semantics. The output schema mitigates some gaps, but overall completeness is limited for a tool with undocumented parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'connector class and type' which maps to two required parameters, but doesn't explain their semantics, valid values, or the optional 'tenant_id' parameter. The API endpoint in the description provides some context but lacks detailed parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and resource ('unlinked provisioned instances'), and specifies filtering criteria ('for a connector class and type'). It distinguishes from siblings like 'cdp_list_provision_instances' by focusing on 'unlinked' instances. However, it doesn't explicitly differentiate from other list tools in the sibling set beyond this scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description mentions the API endpoint but doesn't explain scenarios for listing unlinked instances, prerequisites, or comparisons with related tools like 'cdp_list_provision_instances' or 'cdp_get_provision_instance'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It mentions optional offset/limit for pagination but doesn't disclose critical traits like whether this is a read-only operation, performance characteristics, authentication requirements, error conditions, or rate limits. For a lookup tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the core purpose. Both sentences are relevant: the first states the action and resource, the second adds pagination context. There's no wasted text, though it could be more informative given the tool's complexity.
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 4 parameters with 0% schema coverage, no annotations, but an output schema exists, the description is minimally adequate. It covers the basic purpose and hints at pagination but lacks details on parameter usage, behavioral traits, and when to use versus alternatives. The output schema reduces the need to describe return values, but other gaps remain significant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so parameters are undocumented in the schema. The description only mentions 'lookup by name' and 'optional offset/limit', covering 3 of 4 parameters superficially. It doesn't explain what 'lookup' expects (exact match, partial, case-sensitive), what 'tenant_id' does, or the behavior of offset/limit. The description adds minimal value beyond parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Lookup') and resource ('audiences by name'), specifying it returns matching audience definitions. It distinguishes from siblings like 'cdp_list_audience_defs' by focusing on lookup/search functionality rather than listing all. However, it doesn't explicitly contrast with other lookup tools like 'cdp_lookup_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 is provided on when to use this tool versus alternatives. There's no mention of prerequisites, typical use cases, or comparison with sibling tools like 'cdp_list_audience_defs' or 'cdp_get_audience_def'. The description only states what it does, not when it's appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. While it mentions the required parameters and that the lookup request must be a JSON string, it fails to describe important behavioral aspects: whether this is a read-only operation, what authentication/permissions are needed, whether there are rate limits, what happens with invalid inputs, or what the typical response format looks like. The description provides only basic operational instructions without behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences that directly address the tool's function and parameter requirements. It's front-loaded with the core purpose and wastes no words. However, the second sentence could be clearer about which parameter requires JSON string format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 parameters, 3 required) and the presence of an output schema (which handles return values), the description is minimally adequate but has significant gaps. It covers the basic operation but lacks context about authentication, error handling, performance characteristics, and relationships to sibling tools. The 0% schema description coverage exacerbates these gaps, making the description incomplete for effective tool selection and use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for 4 parameters, the description must compensate but only partially does so. It mentions that 'field' is required and that 'body' should be a JSON string lookup request, but provides no semantic context for 'resource_name' or 'tenant_id'. The description doesn't explain what constitutes a valid resource name, what fields are available for lookup, what the JSON body should contain, or when tenant_id is needed versus optional.
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 ('Lookup') and resource ('distinct values for a field in a DW entity resource'), making the purpose understandable. It distinguishes from siblings by focusing on field value lookup rather than general data retrieval or entity management. However, it doesn't explicitly contrast with similar tools like 'cdp_get_dimension_values' or 'cdp_lookup_audience_defs'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 minimal usage guidance by stating 'Requires the field name to look up' and format instructions for the body parameter. However, it offers no context about when to use this tool versus alternatives like 'cdp_get_dimension_values' or 'cdp_lookup_audience_defs', nor does it mention prerequisites, typical use cases, or constraints beyond the basic parameter requirements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states this triggers processing (implies mutation/action) and mentions optional JSON body forwarding, but lacks critical behavioral details: what 'processing' entails, whether it's idempotent, permission requirements, rate limits, or what happens if the batch doesn't exist. The POST method hint is useful but insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with zero waste. The first sentence states the core purpose, the second adds technical detail about the optional body. However, the endpoint path inclusion could be considered extraneous since it's not needed for tool selection.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters with 0% schema coverage, no annotations, but an output schema exists, the description is incomplete. It covers the main action and hints at parameters but misses tenant_id entirely and lacks behavioral context. The output schema reduces the need to describe return values, but the description should still explain the processing action more thoroughly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only mentions 'by id' (mapping to batch_id) and 'optional JSON body' (mapping to body), but doesn't explain tenant_id parameter at all. No details on parameter formats, constraints, or relationships between parameters. The description adds minimal value beyond what's inferable from parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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: 'Trigger processing of a mailer batch by id' - a specific verb ('trigger processing') and resource ('mailer batch'). It distinguishes from sibling tools like 'cdp_get_mailer_batch' (read) and 'cdp_create_mailer_batch' (create), but doesn't explicitly differentiate from other processing-related tools like 'cdp_start_campaign'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 mentions the endpoint path but doesn't explain prerequisites (e.g., batch must exist), expected outcomes, or when to use this versus other mailer batch operations like 'cdp_update_mailer_batch' or campaign tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Reactivate' implies a state-changing mutation, the description doesn't disclose critical behavioral traits: whether this requires specific permissions, what happens if the instance isn't deactivated, if there are rate limits, side effects, or what the response looks like. The HTTP method (POST) is mentioned but adds little value without context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single sentence that directly states the tool's purpose. It's front-loaded with the core action and resource, with no wasted words. The HTTP endpoint inclusion, while not adding much value for an AI agent, doesn't detract from the brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a state-changing mutation tool), lack of annotations, 0% schema coverage, but presence of an output schema, the description is incomplete. It doesn't address behavioral risks, parameter meanings, or usage context. The output schema may help with return values, but the description itself leaves significant gaps for safe and correct tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The tool description adds no parameter semantics beyond what's implied by the URL path ('{id}' maps to 'instance_id'). It doesn't explain what 'instance_id' or 'tenant_id' represent, their formats, or when 'tenant_id' is required versus optional. With 2 parameters and 0% coverage, the description fails to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Reactivate') and the resource ('a deactivated instance'), providing a specific verb+resource combination. It distinguishes from siblings like 'cdp_deactivate_provision_instance' and 'cdp_provision_instance_action' by focusing on reactivation specifically. However, it doesn't explicitly differentiate from other instance management tools beyond the verb choice.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., the instance must be deactivated), when-not-to-use scenarios, or direct alternatives among the many sibling tools. The agent must infer usage from the tool name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It indicates a mutation ('Restore') but doesn't disclose permissions needed, whether the operation is idempotent, rate limits, or what happens on success/failure (e.g., if the page becomes active again). The mention of 'soft-deleted' is useful context, but overall transparency is lacking for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action. It wastes no words, though it includes the endpoint path ('POST /v2/{tenantId}/emailablepages/{id}') which may be redundant if the agent already has structural info. Overall, it's 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a mutation tool with no annotations, 0% schema coverage, but an output schema exists, the description is minimally adequate. It states the action and resource but lacks details on behavior, parameters, and error handling. The output schema may cover return values, but the description doesn't guide the agent on what to expect, leaving gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter information. It doesn't explain what 'page_id' or 'tenant_id' represent, their formats, or that 'tenant_id' is optional with a default. The description repeats the endpoint path but provides no semantic clarity beyond the schema's basic structure.
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 ('Restore') and resource ('a soft-deleted emailable page'), making the purpose specific and understandable. It distinguishes from siblings like 'cdp_delete_emailable_page' and 'cdp_get_emailable_page' by focusing on restoration of deleted items. However, it doesn't explicitly contrast with 'cdp_create_emailable_page' or 'cdp_update_emailable_page' in terms of state transitions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., the page must be soft-deleted), when not to use it (e.g., for hard-deleted pages), or refer to sibling tools like 'cdp_delete_emailable_page' or 'cdp_list_emailable_pages' for context. Usage is implied only by the action name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It indicates this is a destructive action ('Stop/kill', 'kill signal') which is helpful, but lacks critical behavioral details: whether the stop is immediate or graceful, if it's reversible, what permissions are required, rate limits, or what the output contains. For a mutation tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (two short phrases) with zero wasted words, front-loading the core action. Every element ('Stop/kill', 'running campaign by ID', 'workflow kill signal') contributes essential information 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 destructive mutation tool with 2 parameters (0% schema coverage), no annotations, and an output schema (existence noted but content unknown), the description is incomplete. It covers the basic purpose but misses parameter semantics, usage context, behavioral details, and doesn't leverage the output schema to explain results. The tool's complexity warrants more comprehensive guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'by ID' which aligns with the 'campaign_id' parameter, but doesn't explain the 'tenant_id' parameter at all or provide any format/constraint details for either parameter. The description adds minimal value beyond what's inferable from parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Stop/kill') and target ('a running campaign by ID'), with the additional detail 'Sends a workflow kill signal' providing specific mechanism. It distinguishes from siblings like 'cdp_start_campaign' and 'cdp_kill_job' by focusing on campaigns rather than jobs, though it doesn't explicitly contrast with all 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 provides no guidance on when to use this tool versus alternatives like 'cdp_kill_job' or 'cdp_suspend_job', nor does it mention prerequisites (e.g., campaign must be running) or consequences. It simply states what the tool does without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. 'Unschedule' implies a mutation (likely destructive), but the description doesn't clarify permissions needed, whether the action is reversible, what happens to the compaction request (e.g., is it deleted or just paused?), or any rate limits. This leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with zero wasted words. It's appropriately sized and front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a mutation tool with no annotations, 0% schema description coverage, and 2 parameters, the description is inadequate. It lacks behavioral details, parameter explanations, and context about what 'unschedule' entails. The presence of an output schema helps but doesn't compensate for these gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description mentions 'by ID' which hints at 'request_id', but doesn't explain what a compaction request ID is, the format, or the optional 'tenant_id' parameter. It adds minimal value beyond the schema's structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('unschedule') and target ('compaction request by ID'), making the purpose immediately understandable. However, it doesn't differentiate from potential siblings like 'cdp_delete_compaction_request' or 'cdp_list_compaction_requests' that might exist in the broader context, though these specific siblings aren't in the provided 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?
The description provides no guidance on when to use this tool versus alternatives, prerequisites, or contextual constraints. It's a bare statement of function without any usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Update' implies a mutation operation, but the description doesn't mention permissions required, whether changes are reversible, rate limits, or what happens on success/failure. The JSON format requirement is helpful but insufficient for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just one sentence that contains essential information: the action, target, and parameter format. Every word earns its place with zero waste or redundancy. It's perfectly 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?
For a mutation tool with 3 parameters, 0% schema description coverage, no annotations, and an output schema (which reduces need to describe returns), the description is inadequate. It doesn't explain what an A360 rule is, what fields can be updated, required permissions, error handling, or provide examples. The presence of an output schema helps but doesn't compensate for these gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so parameters are undocumented in the schema. The description mentions 'updated fields as a JSON string' which partially explains the 'body' parameter, but doesn't clarify what fields are updatable, the JSON structure, or the purpose of 'rule_id' and 'tenant_id'. It adds minimal value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Update') and resource ('existing A360 rule'), making the purpose immediately understandable. It distinguishes from sibling tools like 'cdp_create_a360_rule' and 'cdp_delete_a360_rule' by specifying it's for updating existing rules. However, it doesn't specify what an 'A360 rule' is or what fields can be updated, keeping it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'cdp_create_a360_rule' or 'cdp_get_a360_rule'. It mentions 'existing A360 rule' which implies it requires a pre-existing rule, but doesn't state prerequisites, error conditions, or when other tools might be more appropriate. 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is an update operation, implying mutation, but doesn't mention required permissions, whether changes are reversible, potential side effects, or response format. The mention of JSON string for 'body' hints at input format but lacks behavioral depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core purpose and includes essential parameter guidance, making it appropriately concise for its limited content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a mutation tool with no annotations, 0% schema coverage, and an output schema (which reduces need to describe returns), the description is incomplete. It lacks behavioral context, doesn't fully address parameters, and offers no usage guidance, leaving significant gaps for an update operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only mentions 'body' as a JSON string for updated fields, ignoring 'validator_id' and 'tenant_id'. This leaves two parameters undocumented, failing to add sufficient meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and resource ('a column validator'), making the purpose understandable. It doesn't explicitly differentiate from sibling tools like 'cdp_create_column_validator' or 'cdp_delete_column_validator', but the verb 'Update' implies modification of an existing validator rather than creation or deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'cdp_create_column_validator' for creation or 'cdp_get_column_validator' for retrieval. It mentions passing updated fields as JSON, but this is a parameter instruction rather than usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states this is an update operation, implying mutation, but doesn't disclose behavioral traits like required permissions, whether changes are reversible, rate limits, or what happens to unspecified fields. The mention of 'JSON string' for the body is helpful but insufficient for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It front-loads the core action ('Update an existing connector') and adds necessary detail about the JSON format. Every word earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (mutation tool with 3 parameters), no annotations, 0% schema coverage, and an output schema (which helps but isn't described), the description is incomplete. It lacks details on updatable fields, permissions, error handling, and the optional 'tenant_id' parameter. For a tool that modifies resources, this leaves significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description adds minimal semantics: it implies 'connector_id' identifies the connector to update and 'body' contains updated fields as JSON. However, it doesn't explain the purpose of 'tenant_id' (optional parameter), what fields are updatable in the JSON, or any constraints, failing to compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and resource ('existing connector'), and specifies the format for providing updates ('as a JSON string'). It distinguishes from siblings like 'cdp_create_connector' (create vs. update) and 'cdp_delete_connector' (update vs. delete). However, it doesn't specify what fields can be updated or the connector's purpose, leaving some 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing connector ID), when not to use it (e.g., for creation or deletion), or refer to sibling tools like 'cdp_get_connector' for retrieving connector details before updating. Usage is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is an update operation, implying mutation, but lacks critical details such as required permissions, whether changes are reversible, error handling, or rate limits. The mention of 'JSON string' for the body parameter adds some context but is insufficient for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences that directly state the tool's purpose and a key parameter requirement. It is front-loaded with the main action and wastes no words, making it efficient for quick comprehension.
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 a mutation tool with 3 parameters, 0% schema description coverage, no annotations, and an output schema (which helps but isn't described), the description is incomplete. It lacks details on behavioral traits, parameter meanings beyond 'body', and usage context, making it inadequate for safe and effective tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter details. The description only clarifies that 'body' should be a 'JSON string' with updated fields, but it doesn't explain the purpose of 'cubic_set_def_id' or 'tenant_id', their formats, or what fields can be updated in the JSON. This leaves two of three parameters largely undocumented, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and resource ('existing CubicSetDef by ID'), which is specific and distinguishes it from siblings like 'cdp_create_cubic_set_def' (create) and 'cdp_delete_cubic_set_def' (delete). However, it doesn't fully differentiate from other update tools (e.g., 'cdp_update_audience_def') beyond the resource name, which is why it's not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing CubicSetDef ID), exclusions, or comparisons to sibling tools like 'cdp_copy_cubic_set_def' or 'cdp_get_cubic_set_def', leaving the agent with minimal context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is an update operation, implying mutation, but doesn't cover critical aspects like required permissions, whether changes are reversible, rate limits, error handling, or what the output schema contains. The mention of 'JSON string' for the body parameter adds minimal context but leaves major behavioral traits undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single sentence that directly states the tool's purpose and key parameter requirement. There is no wasted language, repetition, or unnecessary elaboration. It is front-loaded with the core action, making it efficient for quick comprehension.
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 an update operation with 3 parameters (2 required), 0% schema description coverage, no annotations, and an output schema (though its content is unknown), the description is inadequate. It lacks details on permissions, side effects, error conditions, and parameter meanings, leaving significant gaps for safe and correct tool invocation despite the output schema's existence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter documentation. The description only mentions that 'updated fields' should be passed 'as a JSON string', which loosely corresponds to the 'body' parameter. It doesn't explain 'dispatch_id' (what identifies a dispatch), 'tenant_id' (optional context), or the structure/fields expected in the JSON body. This fails to compensate for the complete lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and resource ('a dispatch definition'), making the purpose immediately understandable. It distinguishes itself from sibling tools like 'cdp_create_dispatch' and 'cdp_delete_dispatch' by focusing on modification rather than creation or deletion. However, it doesn't specify what a 'dispatch definition' entails or how it differs from similar resources like campaigns or schedules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing dispatch), exclusions, or compare it to sibling tools like 'cdp_update_campaign' or 'cdp_update_schedule'. The only implicit usage hint is that updates require a JSON string, but this is insufficient for effective tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It mentions that updated fields should be passed as a JSON string, which is useful, but lacks details on permissions, side effects, error handling, or response format. For a mutation tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences that are front-loaded and waste no words. Every phrase ('Update an existing entity', 'Pass updated fields as a JSON string') directly contributes to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a mutation tool with 4 parameters, 0% schema coverage, no annotations, and an output schema (which reduces need for return value explanation), the description is incomplete. It lacks crucial details like authentication requirements, error conditions, and full parameter semantics, making it inadequate for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but only partially does. It explains that 'body' should contain 'updated fields as a JSON string', adding meaning beyond the schema's generic 'Body' title. However, it doesn't clarify 'resource_name', 'resource_id', or 'tenant_id', leaving three of four parameters with minimal context.
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 ('existing entity in a DW resource'), making the purpose understandable. It distinguishes from siblings like 'cdp_create_entity' by specifying 'existing', but doesn't explicitly differentiate from other update tools (e.g., 'cdp_update_campaign', 'cdp_update_user') beyond the entity 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?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, when not to use it, or how it relates to sibling tools like 'cdp_create_entity' or 'cdp_get_entity'. Usage is implied only by the action of updating an existing entity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Update a mailer batch' and includes the HTTP method (PUT), implying a mutation operation, but does not disclose critical traits like required permissions, whether the update is idempotent, error handling, or side effects. This leaves significant gaps for safe and effective tool invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two sentences that directly state the tool's action and parameter format, with no redundant information. It is front-loaded and wastes no words, making it efficient for quick comprehension.
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 (a mutation operation with 3 parameters, 0% schema coverage, no annotations, but an output schema exists), the description is insufficient. It lacks details on behavioral traits, parameter meanings, and usage context, relying too heavily on the output schema and leaving the agent under-informed for proper tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It mentions 'Pass the updated definition as a JSON string,' which hints at the 'body' parameter's content but does not explain the 'id' or 'tenant_id' parameters, their formats, or relationships. This adds minimal value beyond the schema, failing to address the coverage gap adequately.
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 ('Update') and resource ('a mailer batch'), and includes the HTTP method (PUT) and endpoint path, making the purpose specific and unambiguous. However, it does not differentiate this tool from sibling update tools like 'cdp_update_mailer_account' or 'cdp_update_mailer_subuser', which reduces clarity in context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as 'cdp_create_mailer_batch' for creation or 'cdp_get_mailer_batch' for retrieval. It mentions the endpoint but does not specify prerequisites, constraints, or typical use cases, leaving the agent with minimal context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the HTTP method (PUT) and that a JSON string is required, but doesn't cover critical aspects like authentication requirements, rate limits, error handling, or what happens to existing subuser data not included in the update. For a mutation tool with zero annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately brief (two sentences) and front-loaded with the core action. Every sentence adds value: the first states what the tool does, the second provides implementation details. There's no redundant information or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there's an output schema (which reduces the need to describe return values) but zero schema description coverage and no annotations, the description is minimally adequate. It covers the basic action and implementation method but lacks details about parameters, behavioral constraints, and usage context that would make it fully complete for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only mentions that 'body' should be 'a JSON string' containing 'the updated definition,' but provides no details about what fields the definition should include, format expectations, or examples. The 'id' and 'tenant_id' parameters aren't explained at all. This leaves most parameter semantics undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and resource ('mailer subuser') with specific HTTP method and endpoint details. It distinguishes from sibling tools like 'cdp_create_mailer_subuser' and 'cdp_delete_mailer_subuser' by focusing on modification rather than creation or deletion. However, it doesn't explicitly differentiate from other update tools in the same domain (e.g., 'cdp_update_mailer_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 is provided about when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., needing an existing subuser ID), constraints, or typical use cases. While the sibling list shows related tools, the description itself offers no comparative context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is an update operation, implying mutation, but fails to describe critical behaviors: required permissions, whether the update is partial or full, validation rules for the JSON body, error handling, or response format. The mention of 'JSON string' for the body adds minimal context but doesn't compensate for the lack of safety or operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that front-loads the core action ('Update an output connector definition'). It avoids unnecessary words and gets straight to the point. However, the lack of additional context or structure means it may be too terse for effective tool selection and invocation.
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 of a mutation tool with 3 parameters, 0% schema coverage, and no annotations, the description is incomplete. It mentions the existence of an output schema (which helps), but fails to explain parameter meanings, usage context, or behavioral traits. While concise, it doesn't provide enough information for reliable tool invocation without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter documentation. The description only vaguely addresses one parameter ('body' as a 'JSON string'), leaving 'connector_def_id' and 'tenant_id' entirely unexplained. It doesn't clarify what fields the JSON should contain, the format of the ID, or when tenant_id is required. This fails to compensate for the poor 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 action ('Update') and resource ('output connector definition'), making the purpose immediately understandable. It distinguishes this from sibling tools like 'cdp_create_output_connector_def' and 'cdp_delete_output_connector_def' by focusing on modification rather than creation or deletion. However, it doesn't specify what an 'output connector definition' entails, leaving some ambiguity about the resource being modified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing connector definition ID), compare it to sibling tools like 'cdp_update_output_connector' (which might update connector instances), or specify scenarios where this update is appropriate versus creating a new definition. The agent must infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states this is an update operation (implying mutation) and mentions the HTTP method (PUT), but lacks critical behavioral details: required permissions, whether the update is idempotent, error handling (e.g., for invalid IDs), response format, or side effects. For a mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two sentences with zero wasted words. It front-loads the core purpose ('Update an existing prediction definition') and includes the API endpoint for technical context. Every sentence earns its place by providing essential information efficiently.
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 (a mutation tool with 3 parameters, 0% schema coverage, no annotations, but an output schema exists), the description is incomplete. It lacks behavioral context (permissions, errors), parameter details (beyond a vague JSON string note), and doesn't leverage the output schema to hint at return values. For a tool that modifies data, this leaves too many gaps for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'updated fields as a JSON string' for the 'body' parameter, which adds some semantics, but doesn't explain what fields are updatable, the JSON structure, or provide examples. It doesn't address 'prediction_def_id' (what it is, where to get it) or 'tenant_id' (when it's required vs optional). With 3 parameters and low schema coverage, the description provides insufficient parameter 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 action ('Update') and resource ('an existing prediction definition'), making the purpose understandable. It distinguishes from siblings like 'cdp_create_prediction' (create vs update) and 'cdp_get_prediction' (read vs update), though it doesn't explicitly mention these distinctions. The inclusion of the HTTP method (PUT) adds technical specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing prediction definition ID), when not to use it, or refer to sibling tools like 'cdp_create_prediction' for creation or 'cdp_delete_prediction' for removal. The description assumes the user knows when updates are appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states it's an update operation, implying mutation, but doesn't disclose behavioral traits like required permissions, whether changes are reversible, rate limits, or error conditions. The mention of JSON string for 'body' hints at input format but lacks depth on behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first clause and includes a brief parameter note. It's efficient with two sentences, though it could be slightly more structured (e.g., separating purpose from parameter instructions).
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 4 parameters with 0% schema coverage, no annotations, and an output schema (which reduces need to describe returns), the description is incomplete. It covers the tool's purpose but lacks details on parameters, behavioral context, and usage guidelines, making it minimally adequate but with clear gaps for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'action' and 'body' as JSON string, adding minimal meaning beyond schema titles. However, it doesn't explain 'user_id' or 'tenant_id', leaving 2 of 4 parameters undocumented, failing to adequately address the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Update') and resource ('a self-service user's status'), with a specific example ('activate/deactivate'). It distinguishes from siblings like 'cdp_update_selfservice_user' by focusing on status changes rather than general updates, though it doesn't 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 alternatives (e.g., 'cdp_update_selfservice_user' for non-status updates or 'cdp_create_selfservice_user' for creation). The description mentions passing parameters but doesn't specify usage context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states it's an update operation but doesn't mention required permissions, whether changes are reversible, rate limits, or what happens to unspecified fields. For a mutation tool affecting user data, this leaves critical behavioral aspects undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately front-loaded with the core action, though its brevity contributes to gaps in other dimensions.
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 6 parameters, 0% schema coverage, no annotations, and no output schema explanation, the description is inadequate. It doesn't address permissions, side effects, parameter meanings, or what constitutes a successful update. The presence of an output schema (per context signals) means return values might be documented elsewhere, but the description doesn't reference this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides only parameter names and types without meaning. The description mentions 'user's details' but doesn't explain what the six parameters represent (e.g., user_id identifies the target, others are optional fields to update). It fails to compensate for the schema's lack of semantic information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and resource ('existing CDP user's details'), making the purpose immediately understandable. It distinguishes itself from sibling tools like 'cdp_create_user' by specifying it's for existing users, though it doesn't differentiate from other update tools like 'cdp_update_client' or 'cdp_update_role' beyond the user focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing user_id), exclusions, or compare it to similar update tools in the sibling list. The agent must infer usage from the name and parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the validation action but does not disclose behavioral traits such as whether it's read-only or mutating, authentication requirements, rate limits, error handling, or what the output contains. The description is minimal and misses key operational details needed for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, consisting of two clear sentences that directly state the tool's function and what it checks. There is no wasted verbiage, making it easy to parse, though it could benefit from more detail without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (validation with 2 parameters), no annotations, 0% schema coverage, but an output schema exists, the description is incomplete. It covers the purpose but lacks usage guidelines, parameter explanations, and behavioral context. The output schema may help with return values, but the description does not compensate for other gaps, making it minimally adequate with clear deficiencies.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description mentions 'expression, arguments, and output attributes' but does not map these to the input parameters ('body' and 'tenant_id'). It fails to explain what 'body' should contain (e.g., the SQueryDef JSON) or the role of 'tenant_id', leaving parameters largely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Validate a SQueryDef's expression, arguments, and output attributes.' It specifies the verb ('validate') and resource ('SQueryDef'), and details what is validated (expression, arguments, output attributes). However, it does not explicitly differentiate from sibling tools like 'cdp_get_squery_def' or 'cdp_copy_squery_def', which would require mentioning it's for validation only, not retrieval or copying.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 (e.g., needing a SQueryDef to validate), exclusions, or compare it to siblings like 'cdp_generate_squery_def' or 'cdp_update_squery_def'. Usage is implied from the purpose but lacks 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states this is a read operation ('Get'), implying it's non-destructive, but doesn't disclose behavioral traits like authentication needs, rate limits, error conditions, or what happens if the cache entry doesn't exist. The description adds minimal context beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose. The first sentence states what the tool does, the second adds useful context about groups. Zero waste, appropriately sized for a simple retrieval tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters with 0% schema coverage, no annotations, but an output schema exists, the description is moderately complete. It explains the core operation and group concept but lacks details on parameters, behavioral traits, and doesn't need to explain return values due to the output schema. Adequate but with clear gaps in parameter documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description mentions 'group and ID' which maps to two of the four parameters, but doesn't explain 'cache_type' or 'tenant_id'. It adds some meaning for 'group' ('logically segregate cache keys by source or purpose') but leaves most parameters undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'a cached value', specifying it's retrieved 'by group and ID'. It distinguishes from siblings like 'cdp_cache_get_by_id' and 'cdp_cache_get_by_key' by highlighting the group-based retrieval, but doesn't explicitly contrast with all 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 'cdp_cache_get_by_id' or 'cdp_cache_get_by_key'. The description mentions groups 'logically segregate cache keys by source or purpose', which implies usage context but doesn't provide clear when/when-not rules or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool returns 'the stored value string and metadata', which is useful. However, it doesn't mention whether this is a read-only operation, potential error cases (e.g., missing keys), performance characteristics, or authentication requirements. For a cache retrieval tool with zero annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence) and front-loaded with the core purpose. Every word earns its place: 'Get' (action), 'cached value' (resource), 'by explicit cache key' (method), and 'Returns...' (outcome). No wasted words or 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 3 parameters with 0% schema coverage and no annotations, the description is incomplete. It mentions the return format but doesn't explain parameters or behavioral details. However, the existence of an output schema means the description doesn't need to document return values. For a simple retrieval tool, it's minimally adequate but lacks parameter guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'cache key' but doesn't explain the three parameters (cache_type, cache_key, tenant_id) or their relationships. The description adds minimal value beyond what's implied by the tool name, failing to clarify parameter purposes or usage patterns.
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 ('Get') and resource ('cached value'), specifying retrieval by 'explicit cache key'. It distinguishes from siblings like 'cdp_cache_get_by_group' and 'cdp_cache_get_by_id' by emphasizing the key-based approach. However, it doesn't explicitly contrast with these alternatives in the description text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 'cdp_cache_get_by_group' or 'cdp_cache_get_by_id'. It also doesn't mention prerequisites, error conditions, or typical use cases. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool creates a duplicate, implying a write operation, but lacks details on permissions, side effects (e.g., whether the original is affected), rate limits, or response behavior. For a mutation tool with zero annotation coverage, this is a significant gap in behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two short sentences that are front-loaded and waste no words. Every part earns its place by stating the action, resource, and outcome efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which covers return values), the description's minimalism is partially offset. However, as a mutation tool with no annotations, 0% schema coverage, and 2 parameters, it lacks completeness in usage guidelines, behavioral details, and parameter explanations. The output schema helps, but key contextual gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'by ID' for 'campaign_id', adding minimal context, but doesn't explain 'tenant_id' (optional parameter) or provide format examples (e.g., integer ID, string tenant). With 2 parameters and no schema descriptions, the description adds insufficient semantic value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Clone/copy') and resource ('campaign definition by ID'), with the outcome ('Creates a duplicate'). It distinguishes from siblings like 'cdp_create_campaign' (new creation) and 'cdp_copy_campaign' (if existed, but not in list). However, it doesn't explicitly differentiate from other clone tools like 'cdp_clone_prediction' or 'cdp_clone_resource' beyond 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?
No guidance on when to use this tool versus alternatives is provided. It doesn't mention prerequisites (e.g., needing an existing campaign ID), exclusions, or compare with similar tools like 'cdp_copy_campaign' (not in siblings) or creation tools. The description assumes context but offers no explicit usage rules.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states it 'creates a duplicate' without disclosing behavioral traits like whether this is a safe operation, if it requires specific permissions, what happens to the original, or any rate limits. It misses key context for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('Copy a CubicSetDef by ID') and adds clarifying detail ('Creates a duplicate of the OLAP query definition') with zero 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 mutation tool with no annotations, 0% schema coverage, but an output schema present, the description is minimally adequate. It states the purpose but lacks behavioral context, parameter semantics, and usage guidelines, though the output schema may cover return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter details. It mentions 'by ID' which hints at 'cubic_set_def_id', but does not explain the purpose of 'tenant_id' or provide any syntax/format guidance beyond what the bare 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 the verb ('Copy') and resource ('CubicSetDef by ID'), specifying it creates a duplicate of an OLAP query definition. It distinguishes from siblings like 'cdp_create_cubic_set_def' (create new) and 'cdp_update_cubic_set_def' (modify existing), but does not explicitly mention these alternatives in the description 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 is provided on when to use this tool versus alternatives like creating a new CubicSetDef from scratch or cloning other resources. The description implies usage when duplicating an existing definition, but lacks explicit context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool performs a copy/duplicate operation, implying creation of a new resource, but doesn't disclose behavioral traits like whether it requires specific permissions, if the copy is exact or modifiable, what happens to the original, or any rate limits. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which reduces the need to describe return values) but no annotations and low schema coverage, the description is minimally adequate. It states the basic purpose but lacks details on usage, parameters, and behavioral context needed for a mutation tool, leaving clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'by ID' which hints at the 'export_id' parameter, but doesn't explain what 'export_id' refers to or the optional 'tenant_id' parameter. This adds minimal value beyond the schema, failing to address the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Copy/duplicate') and resource ('a data export definition by ID'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'cdp_clone_resource' or 'cdp_copy_datasetdef' that might perform similar operations on different resources, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites (e.g., needing an existing export), exclusions, or comparisons to similar tools like 'cdp_create_data_export' or 'cdp_clone_resource' 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the tool creates a duplicate, implying a write operation, but does not disclose behavioral traits like permissions required, whether the copy includes all dependencies, rate limits, or what happens on failure. This leaves significant gaps for safe and effective use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two short sentences that directly state the purpose and outcome, with no unnecessary words. It is front-loaded and efficient, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which should cover return values), no annotations, and low schema coverage, the description is minimally adequate but incomplete. It explains what the tool does at a high level but lacks details on parameters, behavioral context, and usage guidelines, which are crucial for a mutation tool with undocumented inputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning parameters are undocumented in the schema. The description adds no information about the parameters, such as what 'report_def_id' refers to or the purpose of 'tenant_id'. It fails to compensate for the lack of schema documentation, leaving parameters ambiguous.
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 ('Copy a report definition by ID') and the outcome ('Creates a duplicate of the report'), which specifies the verb and resource. However, it does not explicitly differentiate from similar sibling tools like cdp_clone_resource or cdp_copy_dashboard, which might have overlapping purposes in copying resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as cdp_clone_resource or other copy-related tools in the sibling list. It lacks context on prerequisites, exclusions, or specific 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?
With no annotations provided, the description carries full burden but lacks behavioral details. It mentions 'creates a duplicate' implying a write operation, but doesn't disclose permissions required, whether the copy inherits settings, rate limits, or what the output contains. For a mutation tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values), no annotations, and low schema coverage, the description is minimally adequate but lacks context. It states the purpose but misses behavioral transparency and parameter semantics needed for a mutation tool. Completeness is borderline viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description mentions 'by ID' which hints at 'squery_def_id', but doesn't explain what an SQueryDef is, the purpose of 'tenant_id', or their formats. It adds minimal value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Copy') and resource ('SQueryDef by ID'), specifying it creates a duplicate. It distinguishes from siblings like 'cdp_create_squery_def' (create new) and 'cdp_get_squery_def' (retrieve), but doesn't explicitly contrast with 'cdp_clone_resource' which might 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 is provided on when to use this tool versus alternatives like 'cdp_clone_resource' or 'cdp_create_squery_def'. The description only states what it does, not when it's appropriate or any prerequisites (e.g., needing an existing SQueryDef ID).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a creation operation but doesn't mention required permissions, whether this is a mutating/destructive action, rate limits, or what happens on success/failure. The JSON string requirement is helpful but insufficient for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just one sentence with zero wasted words. It's front-loaded with the core purpose and includes the critical parameter format requirement. Every word earns its place in this minimal but complete statement.
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 this is a mutation tool with 2 parameters (0% schema coverage), no annotations, but with an output schema, the description is minimally adequate. The output schema existence means return values are documented elsewhere, but the description lacks crucial context about permissions, side effects, and parameter details needed for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'rule as a JSON string' which partially explains the 'body' parameter, but doesn't clarify the JSON structure, required fields, or examples. It completely ignores the 'tenant_id' parameter and its optional nature. The description adds minimal value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and resource ('new A360 identity resolution rule'), providing a specific verb+resource combination. It distinguishes from siblings like 'cdp_update_a360_rule' by focusing on creation rather than modification, though it doesn't explicitly contrast with other rule-related tools like 'cdp_get_a360_rule' or 'cdp_list_a360_rules'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, appropriate contexts, or when to choose creation over other rule operations like updating or listing. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It mentions 'Requires name' as a constraint and hints at data format ('JSON string', 'serialized Saiku JSON string'), but doesn't cover permissions, side effects, error conditions, or what the output schema returns. For a creation tool with zero annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the core purpose. Each sentence adds value: the first states the action, the second specifies input format and requirements, and the third clarifies a field detail. There's no wasted text, though it could be 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?
Given 2 parameters with 0% schema coverage, no annotations, and an output schema (which reduces need to describe returns), the description is partially complete. It covers key aspects of 'body' but omits 'tenant_id' and lacks behavioral context like error handling or permissions. It's minimally viable but has clear gaps for a 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?
Schema description coverage is 0%, so the description must compensate. It adds meaning by specifying that 'body' should be a 'JSON string' containing the definition, with 'name' required and 'model' as a 'serialized Saiku JSON string'. However, it doesn't explain 'tenant_id' (the second parameter) or provide examples of the JSON structure, leaving partial gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a new CubicSetDef') and specifies the resource being created. It distinguishes from siblings like 'cdp_copy_cubic_set_def' by focusing on creation rather than copying, but doesn't explicitly contrast with other creation tools like 'cdp_create_dashboard' or 'cdp_create_report_def' to explain what makes a CubicSetDef unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, context for creation, or compare it to similar tools like 'cdp_create_datasetdef' or 'cdp_create_squery_def'. The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool creates a dispatch definition, implying a write operation, but doesn't disclose behavioral traits like required permissions, whether it's idempotent, rate limits, or what happens on failure. The mention of 'JSON string' for the body parameter adds some context but is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two sentences with zero waste. It front-loads the core purpose and provides a direct instruction for the body parameter. Every word earns its place, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation with 3 parameters, 0% schema coverage, no annotations, but an output schema exists), the description is incomplete. It lacks details on parameters, behavioral context, and usage guidelines. However, the presence of an output schema mitigates the need to explain return values, keeping it from being a complete failure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only mentions that the 'body' parameter should be a 'JSON string', adding minimal semantics for one of three parameters. It doesn't explain 'campaign_id' or 'tenant_id', leaving most parameters undocumented. This fails to adequately compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and resource ('dispatch definition for a campaign'), making the purpose evident. It distinguishes from siblings like 'cdp_update_dispatch' or 'cdp_get_dispatch' by specifying creation. However, it doesn't explicitly differentiate from other creation tools (e.g., 'cdp_create_campaign'), leaving room for improvement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., an existing campaign), exclusions, or comparisons to sibling tools like 'cdp_update_dispatch' or 'cdp_list_dispatches'. Usage context is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Create a new execution bucket', which implies a write operation, but doesn't disclose any behavioral traits such as required permissions, whether this is idempotent, what happens on failure, or if there are rate limits. The mention of 'configuration as a JSON string' hints at input format but doesn't explain the expected structure or constraints. For a creation tool with zero annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two short sentences that are front-loaded and waste no words. It directly states the action and key input requirement without unnecessary elaboration, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (creation operation with 2 parameters), no annotations, and an output schema (which reduces the need to describe return values), the description is incomplete. It covers the basic purpose but lacks usage guidelines, behavioral details, and parameter semantics. While the output schema helps, the description doesn't provide enough context for safe and effective use, especially for a write operation with undocumented parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'configuration as a JSON string', which loosely maps to the 'body' parameter, but doesn't explain what this configuration entails or provide any details about the 'tenant_id' parameter. With schema description coverage at 0% and 2 parameters (one required), the description adds minimal value beyond the schema's property names. It fails to compensate for the lack of schema descriptions, leaving parameters largely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' and the resource 'execution bucket', making the purpose specific and understandable. It distinguishes from siblings like cdp_list_execution_buckets (list vs. create) and cdp_update_execution_bucket (update vs. create), though it doesn't explicitly differentiate beyond the inherent action. The mention of 'configuration as a JSON string' adds useful detail about the input format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, such as whether an execution bucket is needed for specific workflows, or when to choose this over other creation tools like cdp_create_execution_summary_group. The only implied usage is for creating execution buckets, but no context or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states this is a creation tool (implies mutation) but doesn't disclose behavioral traits like required permissions, whether the operation is idempotent, rate limits, or what happens on duplicate names. The mention of JSON string format is helpful but insufficient for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in two sentences: the first states the purpose, the second provides critical parameter guidance. There's no wasted text, though it could be slightly more front-loaded with key constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there's an output schema (which handles return values), no annotations, and 2 parameters with 0% schema coverage, the description is moderately complete. It covers the core purpose and main parameter requirements but lacks behavioral context for a mutation tool and doesn't fully document all 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 0%, so the description must compensate. It adds meaningful context: the 'body' parameter should be a JSON string containing name and reportType fields, with reportType having enum values 'CUBE' or 'RELATIONAL'. However, it doesn't explain the optional 'tenant_id' parameter or provide JSON structure examples, leaving gaps in parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a new report definition') and specifies the resource ('report definition'), which distinguishes it from other creation tools like cdp_create_dashboard or cdp_create_widget. However, it doesn't explicitly differentiate from cdp_copy_report_def (a sibling tool), which would be needed for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like cdp_copy_report_def or cdp_update_report_def. It mentions required fields (name and reportType) but doesn't specify prerequisites, dependencies, or contextual triggers for creating a report definition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It mentions the JSON format for user details but doesn't disclose permissions needed, whether this is a mutating operation (implied by 'Create'), rate limits, error conditions, or what happens on success/failure. For a user creation tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two brief sentences with zero wasted words. It's front-loaded with the core purpose and follows with a critical implementation detail. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool creates a user (a significant mutation), has no annotations, 0% schema description coverage, but does have an output schema (which reduces need to describe returns), the description is minimally complete. It states the action and data format but lacks crucial context like permissions, validation rules, or error handling, making it barely adequate for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but only partially does. It mentions 'user details as a JSON string' which loosely maps to the 'body' parameter, but doesn't explain what fields the JSON should contain, format examples, or the optional 'tenant_id' parameter's purpose. Two parameters exist with no schema descriptions, and the description adds limited 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 the action ('Create') and resource ('new self-service user'), making the purpose explicit. It distinguishes from siblings like 'cdp_create_user' by specifying 'self-service' user type, though it doesn't explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'cdp_create_user' or 'cdp_update_selfservice_user'. The description only states what it does, not when it's appropriate or what prerequisites might exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is a creation tool, implying it's a write operation, but doesn't mention permissions required, whether it's idempotent, rate limits, or what happens on success/failure. The mention of 'JSON string' for the body parameter adds some context, but overall behavioral traits are inadequately covered for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with only two sentences that directly address the tool's function and key parameter requirements. Every word earns its place: the first sentence states the purpose, the second provides essential parameter guidance. No redundant information or unnecessary elaboration 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?
Given that this is a mutation tool with no annotations, 0% schema description coverage, but with an output schema present, the description is moderately complete. It covers the core purpose and provides some parameter guidance, but lacks behavioral context (permissions, side effects) and doesn't address all parameters. The output schema existence means return values don't need explanation, but other gaps remain significant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains that 'body' should be a 'JSON string' containing widget definition with minimum fields 'name and visualizationType', which adds crucial meaning beyond the schema's generic 'string' type. However, it doesn't address the 'tenant_id' parameter at all, leaving half of the parameters undocumented. The description provides partial but incomplete parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Create') and resource ('new widget'), making the purpose immediately understandable. It distinguishes from sibling tools like 'cdp_copy_widget' or 'cdp_update_widget' by focusing on creation rather than copying or updating. However, it doesn't specify what a 'widget' is in this context, which slightly limits differentiation from other creation tools 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?
The description provides no guidance on when to use this tool versus alternatives. It mentions required fields ('name and visualizationType at minimum') but doesn't explain when to choose this over 'cdp_copy_widget' for duplication or 'cdp_update_widget' for modifications. No prerequisites, exclusions, or contextual usage scenarios are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Delete' implies a destructive, irreversible operation, but the description doesn't explicitly warn about permanence, confirm deletion effects, or mention any permissions required. For a destructive tool with zero annotation coverage, this is a significant gap in safety 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?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized for a simple deletion operation and gets straight to the point without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no annotations, 0% schema description coverage, and an output schema (which may provide some return information), the description is inadequate. It doesn't address critical aspects like safety warnings, confirmation requirements, or what happens post-deletion. The presence of an output schema helps somewhat, but the description should do more for a 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?
The description provides no parameter information beyond what's implied by the tool name. With 0% schema description coverage and 2 parameters (audience_def_id, tenant_id), the description doesn't compensate by explaining what these parameters mean or how they affect the deletion. However, the baseline is 3 since the tool name itself suggests the primary parameter (audience_def_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 the verb ('Delete') and resource ('an audience definition'), making the purpose immediately understandable. However, it doesn't differentiate from sibling deletion tools like cdp_delete_campaign or cdp_delete_user, which all follow the same 'delete [resource]' pattern.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. The description doesn't mention prerequisites (like needing an existing audience definition), nor does it clarify when deletion is appropriate versus deactivation or other operations available in the sibling tool list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Delete' implies a destructive operation, the description doesn't specify whether deletion is permanent/reversible, what permissions are required, whether it affects associated resources, or what the output contains. This is inadequate for a destructive tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core purpose without unnecessary words. It's appropriately sized for a simple deletion operation and gets straight to the point.
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 destructive tool with no annotations, 0% schema description coverage, and an output schema (which helps but doesn't replace behavioral context), the description is insufficient. It should address critical aspects like deletion permanence, authorization requirements, and what happens to associated data, especially given the presence of sibling tools that manage related 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 description mentions 'numeric ID' which aligns with the client_id parameter, but doesn't explain the tenant_id parameter at all. With 0% schema description coverage and 2 parameters, the description adds minimal value beyond what's implied by the tool name. It partially compensates for the coverage gap but leaves tenant_id completely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and target resource ('OAuth client by numeric ID'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling deletion tools like cdp_delete_user or cdp_delete_campaign, but the specificity about OAuth clients provides some implicit distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites (like needing specific permissions), consequences of deletion, or when to choose this over other client-related tools like cdp_create_client or cdp_update_client.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. 'Delete' implies a destructive, irreversible mutation, but it doesn't disclose permissions needed, side effects (e.g., impact on linked widgets), confirmation steps, or error handling. This is inadequate for a destructive operation with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with zero wasted words, making it highly concise and front-loaded. Every word ('Delete', 'dashboard', 'by ID') contributes essential information 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 destructive tool with 2 parameters (0% schema coverage), no annotations, and an output schema (unseen), the description is incomplete. It lacks critical context: no behavioral details, minimal parameter guidance, and no mention of output or error cases. The presence of an output schema mitigates some need but doesn't compensate for the overall gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but only mentions 'by ID' for dashboard_id, ignoring tenant_id. It adds minimal meaning beyond the schema's property names, failing to explain parameter purposes (e.g., tenant_id for multi-tenant contexts). Baseline 3 is given as schema coverage is low but description doesn't adequately fill gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a dashboard by ID' clearly states the action (delete) and resource (dashboard), making the purpose immediately understandable. It distinguishes from sibling tools like cdp_update_dashboard or cdp_copy_dashboard by specifying deletion, though it doesn't explicitly contrast with other delete operations (e.g., cdp_delete_widget).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., needing dashboard existence), exclusions, or relationships with sibling tools like cdp_list_dashboards for ID discovery or cdp_delete_widget for related deletions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'soft-delete' which implies a non-destructive operation, but doesn't clarify what that entails (e.g., is it reversible? what happens to the page data? are there retention policies?). It also doesn't address authentication needs, rate limits, error conditions, or response format. The description adds minimal behavioral context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single sentence that states the core action. It's front-loaded with the key information ('soft-delete an emailable page') and includes the API endpoint as supplementary detail. There's zero wasted verbiage, making it efficient for an agent to parse.
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 deletion tool with no annotations, 0% schema coverage, but with an output schema, the description is inadequate. It doesn't explain the implications of 'soft-delete', doesn't guide parameter usage, and doesn't provide behavioral context. While the output schema may document return values, the description fails to address critical aspects like permissions, side effects, or error handling that would help the agent use 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 description coverage is 0%, so the schema provides no parameter documentation. The description doesn't mention any parameters at all, failing to compensate for the coverage gap. However, with only 2 parameters (page_id required, tenant_id optional with default null), the baseline is moderate. The description adds no value beyond what's inferable from the schema structure alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('soft-delete') and resource ('an emailable page'), providing a specific verb+resource combination. It distinguishes from siblings like 'cdp_delete_emailable_page' (hard delete) by specifying 'soft-delete', though it doesn't explicitly contrast with other deletion tools in the list. The purpose is unambiguous but could better differentiate from 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?
No guidance is provided on when to use this tool versus alternatives. The description mentions 'soft-delete' but doesn't explain what that means operationally, when it's appropriate, or what alternatives exist (e.g., hard delete, restore). There's no context on prerequisites, permissions, or typical use cases, leaving the agent with minimal usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Delete' implies a destructive operation, the description doesn't specify whether this is permanent, requires specific permissions, has confirmation steps, or what the output contains. For a destructive tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized for a simple deletion operation and front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with 2 parameters (0% schema coverage) and no annotations, the description is insufficient. While an output schema exists (which helps), the description should explain the irreversible nature of deletion, permission requirements, and parameter context given the complete lack of structured 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 description coverage is 0%, so the description must compensate. It mentions 'by ID' which corresponds to the 'user_id' parameter, but doesn't explain the optional 'tenant_id' parameter or provide any context about parameter formats, constraints, or relationships. The description adds minimal value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and target resource ('a self-service user by ID'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'cdp_delete_user' or 'cdp_update_selfservice_user_status', which reduces its effectiveness in a crowded toolset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. There's no mention of prerequisites (like needing admin permissions), what happens after deletion, or whether this is irreversible versus other user management 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Delete' implying a destructive mutation, but doesn't disclose critical behaviors like whether deletion is permanent, requires specific permissions, has side effects, or returns confirmation. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words, making it easy to parse. It's appropriately sized for a simple tool, though brevity contributes to gaps in other dimensions.
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 destructive mutation tool with no annotations, 0% schema coverage, and an output schema (which helps but isn't described), the description is incomplete. It lacks behavioral context, parameter details, and usage guidance, making it insufficient for safe and effective tool 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 description coverage is 0%, so the description must compensate. It mentions 'by ID', which hints at the 'user_id' parameter, but doesn't explain the 'tenant_id' parameter or its optionality. The description adds minimal value beyond the schema, failing to fully address the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and target resource ('a CDP user by ID'), making the purpose specific and understandable. However, it doesn't differentiate from sibling deletion tools like 'cdp_delete_client' or 'cdp_delete_role', which follow the same pattern, so it misses full 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, prerequisites, or exclusions. Given the sibling tools include 'cdp_delete_user' and others like 'cdp_delete_selfservice_user', there's no indication of which to choose in different 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the token is sent via the Authorization header, which is useful, but fails to describe critical traits like whether this is a read-only or mutating operation, authentication requirements, rate limits, or what happens on success/failure. This leaves significant gaps for a tool that likely modifies token state.
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 that directly state the tool's function and a technical detail (Authorization header). There is no wasted language, and it's 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 complexity of token management, no annotations, and low schema coverage, the description is inadequate. It lacks output details (though an output schema exists, reducing this gap), behavioral context, and parameter explanations. For a tool that likely involves authentication state changes, more completeness is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description adds minimal value by implying the 'token' parameter is a bearer token sent in the Authorization header, but doesn't explain the 'scheme' parameter or its default value 'A1USER'. This partially compensates but leaves key semantics unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Extend') and resource ('expiry of an existing bearer token'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'cdp_create_token' or 'cdp_revoke_token', which would require mentioning alternatives or contrasting use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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., 'cdp_create_token' for new tokens, 'cdp_revoke_token' for invalidating tokens). It also lacks context about prerequisites, such as needing an existing token or typical scenarios for extension.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool generates arguments and fills in 'arguments and outputAttributes,' implying a read-only or computational operation, but does not clarify if it's safe, idempotent, or has side effects. It lacks details on error handling, rate limits, or authentication needs, which are critical for a tool with potential complexity.
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 highly concise and front-loaded: two sentences that directly state the action, input, and output. Every word serves a purpose, with no redundant information, making it efficient for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (generating arguments for a SQueryDef), no annotations, 0% schema coverage, but with an output schema present, the description is partially complete. It covers the basic operation and output but lacks details on parameters, behavioral traits, and usage context. The output schema mitigates some gaps, but overall, it's adequate only for minimal understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It mentions 'Pass a SQueryDef JSON with an expression field,' which hints at the 'body' parameter but does not explain the 'tenant_id' parameter or provide format details (e.g., JSON structure). This adds minimal value beyond the schema, leaving key parameters inadequately described.
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: 'Generate input/output arguments for a SQueryDef from its expression.' It specifies the verb ('Generate'), resource ('input/output arguments for a SQueryDef'), and transformation ('from its expression'). However, it does not explicitly differentiate from sibling tools like 'cdp_validate_squery_def' or 'cdp_get_squery_def', which might have overlapping contexts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 minimal usage guidance: 'Pass a SQueryDef JSON with an expression field.' It does not specify when to use this tool versus alternatives (e.g., 'cdp_validate_squery_def' for validation or 'cdp_create_squery_def' for creation), nor does it mention prerequisites or exclusions. This leaves the agent without clear contextual 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?
No annotations are provided, so the description carries full burden for behavioral disclosure. It states this is a 'Get' operation, implying read-only behavior, but doesn't confirm if it's safe, whether it requires authentication, what happens with invalid IDs, or if there are rate limits. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized for a simple retrieval tool and front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there's an output schema (which handles return values), no annotations, and simple parameters, the description is minimally complete. However, for a tool with zero schema description coverage and no annotations, it should provide more context about parameters and behavioral expectations to be fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning neither parameter has descriptions in the schema. The description mentions 'by ID' which correlates with 'rule_id', but doesn't explain what 'tenant_id' is, its purpose, or when it should be provided. With two parameters and no schema descriptions, the description adds minimal value beyond the obvious.
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 ('Get') and resource ('a specific A360 rule by ID'), making the purpose immediately understandable. It distinguishes this tool from its sibling 'cdp_list_a360_rules' by specifying retrieval of a single rule rather than listing multiple rules. However, it doesn't explain what an 'A360 rule' is, which slightly 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?
The description provides no guidance on when to use this tool versus alternatives like 'cdp_list_a360_rules' or 'cdp_update_a360_rule'. It doesn't mention prerequisites, error conditions, or typical use cases. The only implied usage is when you have a specific rule ID, but this is insufficient for effective tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'synchronous' which hints at blocking behavior, but doesn't disclose critical traits like permissions needed, rate limits, error conditions, or what 'audience count' entails (e.g., approximate vs. exact). For a tool with no annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two sentences with zero waste. It front-loads the core purpose and follows with parameter guidance. Every word earns its place, making it easy for an agent to parse quickly without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which likely describes the return value), the description doesn't need to explain outputs. However, with no annotations, 0% schema coverage, and two parameters (one partially explained), the description is minimally adequate. It covers the basic purpose and one parameter's semantics but lacks behavioral context and full parameter guidance, making it incomplete for safe, informed use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains that 'body' should be a 'segment definition as a JSON string', adding crucial meaning beyond the schema's generic 'Body' title. However, it doesn't clarify 'tenant_id' at all, leaving half the parameters undocumented. The description adds value but doesn't fully compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('audience count'), specifying it's based on a segment definition and synchronous. It distinguishes from many sibling tools (e.g., cdp_calculate_audience, cdp_get_calculated_count) by focusing on count retrieval rather than calculation or other operations. However, it doesn't explicitly differentiate from all possible siblings like cdp_get_audience_def, which might retrieve definitions rather than counts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions 'synchronous' but doesn't explain implications or compare to asynchronous options. With many sibling tools (e.g., cdp_calculate_audience, cdp_get_calculated_count), there's no indication of when this specific tool is appropriate, leaving the agent to guess based on names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states it's a read operation ('Get details'). It doesn't disclose behavioral aspects like authentication needs, rate limits, error conditions, or what 'details' include (e.g., structure, format). This leaves significant gaps for a tool that likely returns complex campaign execution data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. There's no wasted verbiage or unnecessary elaboration, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which likely documents return values), the description's minimalism is somewhat acceptable. However, with no annotations, 0% schema description coverage, and a mutation-heavy sibling context, it should provide more behavioral context (e.g., read-only safety, typical response structure) to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter information. It mentions 'by ID' which hints at 'run_id', but doesn't explain what a 'run_id' is, the optional 'tenant_id' parameter, or their formats/constraints. This leaves both parameters largely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get details') and resource ('specific campaign execution (dataset description) by ID'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'cdp_get_campaign' or 'cdp_list_campaign_runs', which would be needed for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, typical use cases, or how it differs from other 'get' tools in the sibling list (e.g., cdp_get_campaign, cdp_get_run_dispatches).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It implies a read-only operation ('Get'), but doesn't disclose permissions needed, rate limits, error conditions, or what the output contains. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action ('Get a specific column validator'), making it easy to scan and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (2 parameters, no nested objects) and the presence of an output schema (which handles return values), the description is minimally adequate. However, with no annotations and 0% schema coverage, it lacks context on permissions, errors, and parameter details that would help an agent use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter details. It mentions 'by ID' which aligns with 'validator_id', but doesn't explain what a validator ID is, its format, or the optional 'tenant_id' parameter's purpose. The description fails to provide meaningful context beyond what's inferred from the parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'a specific column validator by ID', making the purpose unambiguous. It distinguishes from siblings like 'cdp_list_column_validators' (which lists multiple) and 'cdp_create_column_validator' (which creates new ones), but doesn't explicitly contrast them in the description 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 is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., needing a valid validator_id), nor does it differentiate from similar tools like 'cdp_list_column_validators' for browsing or 'cdp_get_entity' for other resources.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Get' implies a read operation, the description doesn't specify whether this requires authentication, what happens if the connector ID doesn't exist (e.g., error handling), rate limits, or the format of returned data. For a read tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action ('Get a specific connector'), making it immediately scannable. Every word earns its place by specifying the resource and key identifier.
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 (simple read operation), 2 parameters, and the presence of an output schema (which handles return values), the description is minimally adequate. However, with 0% schema coverage and no annotations, it fails to explain parameter semantics or behavioral context. The output schema existence prevents a lower score, but the description should do more to compensate for the missing structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning parameters are undocumented in the schema. The description mentions 'by ID' which hints at the 'connector_id' parameter, but doesn't explain what a connector ID is, its format, or where to obtain it. It completely ignores the 'tenant_id' parameter (optional string/null), leaving the agent guessing about its purpose and when to provide it. The description adds minimal value beyond the parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('a specific connector by ID'), making the purpose immediately understandable. It distinguishes from sibling tools like 'cdp_list_connectors' (which lists multiple connectors) and 'cdp_create_connector' (which creates new ones). However, it doesn't specify what information is retrieved about the connector, leaving some ambiguity about the scope of data 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a valid connector ID), when not to use it (e.g., for listing connectors), or refer to sibling tools like 'cdp_list_connectors' for broader queries. The agent must infer usage from the tool name and context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states a read operation ('Get'), implying it's likely safe and non-destructive, but doesn't disclose any behavioral traits: no information about authentication needs, rate limits, error responses, or what happens if the ID doesn't exist. For a tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action ('Get a specific connector definition'), making it immediately understandable. Every word earns its place by specifying the resource and key parameter.
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 (2 parameters, no nested objects) and the presence of an output schema (which likely describes the return value), the description is minimally adequate. However, with no annotations and 0% schema description coverage, it lacks context on authentication, errors, and parameter details. It meets a bare minimum but leaves gaps an agent would need to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description mentions 'by ID', which hints at the 'connector_def_id' parameter, but doesn't explain what a connector definition is, what format the ID should be (integer as per schema), or the purpose of the optional 'tenant_id' parameter. It adds minimal value beyond the schema's property names and types.
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 ('Get') and resource ('a specific connector definition by ID'), making the purpose unambiguous. It distinguishes this from list operations (like 'cdp_list_connector_templates') by specifying retrieval of a single item. However, it doesn't explicitly differentiate from other 'get' tools (e.g., 'cdp_get_connector', 'cdp_get_connector_versions') beyond the resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a valid connector_def_id), contrast with sibling tools like 'cdp_list_connector_templates' for browsing, or specify error conditions. The agent must infer usage from the name and parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Get connector history / past batch runs', which implies a read-only operation, but does not specify permissions, rate limits, pagination behavior (hinted by offset/limit parameters), or what the output contains. For a tool with no annotations, this is a significant gap in transparency about how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence: 'Get connector history / past batch runs for a connector'. It is front-loaded with the core purpose and has no unnecessary words, making it highly concise and well-structured for quick 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 (4 parameters, 1 required), no annotations, 0% schema coverage, but with an output schema present, the description is incomplete. It states the purpose clearly but lacks parameter explanations, behavioral details, and usage context. The output schema may cover return values, but the description does not provide enough guidance for effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It does not mention any parameters, such as 'connector_id', 'tenant_id', 'offset', or 'limit', leaving their purposes undocumented. The description adds no meaning beyond the schema, failing to explain what these parameters do or how they affect the retrieval of connector history.
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 connector history / past batch runs for a connector'. It specifies the verb ('Get') and resource ('connector history / past batch runs'), making it easy to understand what it does. However, it does not explicitly differentiate from sibling tools like 'cdp_get_connector' or 'cdp_list_connectors', which might retrieve current connector details or lists, respectively.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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, context, or exclusions, such as whether it's for historical data only or how it differs from other 'get' or 'list' tools for connectors. This lack of usage context leaves the agent to infer based on the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states it's a read operation ('Get') and returns status information. It lacks details on permissions needed, rate limits, error conditions, or whether it's idempotent. For a tool that likely queries system state, more behavioral context would be helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently communicates the core functionality. It's front-loaded with the main purpose and includes the return value without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there's an output schema (which should document return values), the description adequately covers the basic purpose. However, with no annotations and poor parameter documentation, it leaves gaps in understanding behavioral aspects and parameter usage that could hinder effective tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description provides no information about the 'tenant_id' parameter. It doesn't explain what happens when tenant_id is null versus specified, or how this affects the scope of cubes returned. The description fails to compensate for the schema's lack of documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get the processing status') and resource ('all OLAP cubes for a tenant'), with specific mention of what's returned ('status of each cube including whether it is ready'). However, it doesn't explicitly differentiate from the sibling tool 'cdp_get_cube_status_by_names', which appears to be a more targeted version.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The sibling list includes 'cdp_get_cube_status_by_names', which likely serves a similar purpose with different parameters, but the description doesn't mention this alternative or specify usage contexts like when tenant_id is required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool retrieves status information (implying read-only), but doesn't mention authentication requirements, rate limits, error handling, or what 'processing status' entails (e.g., pending, running, completed). The description is minimal and lacks operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no wasted words. The first sentence states the purpose, and the second provides parameter guidance. It's appropriately sized for a simple lookup tool, though it could be more front-loaded with key usage 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 that there's an output schema (which handles return values), the description's job is lighter. However, with no annotations, 0% schema coverage, and a mutation-heavy sibling toolset, the description should do more to clarify this read operation's behavior and constraints. It's minimally adequate but leaves gaps in parameter documentation and usage 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 description coverage is 0%, so the description must compensate. It explains that 'cube_names' should be a 'JSON array of cube unique names as a string', adding crucial format information not in the schema. However, it doesn't mention the optional 'tenant_id' parameter at all, leaving half the parameters undocumented. The value added is partial.
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 ('Get the processing status') and resource ('specific OLAP cubes by name'), making the purpose explicit. It distinguishes from the sibling tool 'cdp_get_cube_status' (which likely has different parameters) by specifying 'by names', though it doesn't explicitly contrast with other cube-related tools in the 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?
The description provides no guidance on when to use this tool versus alternatives like 'cdp_get_cube_status' or other status-checking tools. It mentions the parameter format ('JSON array of cube unique names as a string') but gives no context about prerequisites, error conditions, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states this is a 'Get' operation, implying it's likely read-only, but doesn't disclose behavioral traits such as authentication requirements, rate limits, error conditions, or what constitutes a 'detailed' profile. This leaves significant gaps for safe and effective use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. It's appropriately sized for a straightforward tool, though its brevity contributes to gaps in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, 2 required) and the presence of an output schema (which reduces the need to describe return values), the description is minimally adequate. However, with no annotations and 0% schema coverage, it lacks sufficient detail on parameters and behavioral context, making it incomplete for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so parameters are undocumented in the schema. The description mentions 'for a specific customer' but doesn't explain what 'resource_name', 'resource_id', or 'tenant_id' mean, how to obtain them, or their expected formats. It adds minimal value beyond the schema's structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/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 ('detailed Customer 360 profile for a specific customer'), making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'cdp_get_customer_360' or 'cdp_get_customer_360_realtime', which appear to be related but distinct 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context for selecting this over similar tools (e.g., 'cdp_get_customer_360'), or any exclusions, leaving the agent without 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?
No annotations are provided, so the description carries the full burden. It states this is a read operation ('Get'), which is clear, but lacks details on permissions, rate limits, data freshness, or response format. The mention of 'latest streaming events' hints at dynamic data but doesn't specify behavioral traits like latency or update frequency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. Every word earns its place, with no wasted text or redundancy, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, 0% schema coverage, and an output schema (which handles return values), the description is minimally adequate. It clarifies the tool's purpose but lacks parameter details and behavioral context, making it incomplete for a tool with three parameters in a complex CDP environment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds no information about the three parameters (resource_name, resource_id, tenant_id), such as what they represent, examples, or constraints. This leaves parameters undocumented beyond their titles 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 ('Get') and resource ('real-time Customer 360 data') with a specific scope ('includes latest streaming events'). It distinguishes from sibling tools like 'cdp_get_customer_360' and 'cdp_get_customer_360_detail' by emphasizing real-time data, though it doesn't explicitly name those 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 explicit guidance on when to use this tool versus alternatives like 'cdp_get_customer_360' or 'cdp_get_customer_360_detail'. The description implies real-time data retrieval but lacks context on prerequisites, exclusions, or specific scenarios where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool 'Returns full definition including widgets and layout structure,' which adds value beyond the basic 'get' action by hinting at the return content. However, it lacks critical behavioral details: it doesn't disclose whether this is a read-only operation (implied but not stated), authentication needs, error handling (e.g., for invalid IDs), rate limits, or performance characteristics. For a tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the core action, and the second adds valuable return details. Every sentence earns its place with no waste, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (simple retrieval), no annotations, and an output schema exists (which should document return values), the description is minimally complete. It covers the basic action and hints at return content, but gaps remain: no behavioral transparency, incomplete parameter semantics, and no usage guidelines. It's adequate but with clear room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description mentions 'by ID,' which aligns with the dashboard_id parameter, adding some meaning. However, it doesn't explain the tenant_id parameter (its purpose, when it's required vs. optional with default null, or how it affects the query). With 2 parameters and low coverage, the description compensates only partially.
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 ('Get') and resource ('a dashboard by ID'), making the purpose specific and understandable. It distinguishes from siblings like cdp_list_dashboards (which lists multiple dashboards) by focusing on retrieval of a single dashboard by ID. However, it doesn't explicitly contrast with other get_* tools (e.g., cdp_get_widget), though the resource 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., needing a valid dashboard ID), exclusions, or comparisons to siblings like cdp_list_dashboards for browsing or cdp_get_widget for widget details. Usage is implied by the action 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states it's a read operation ('Get'). It lacks details on authentication needs, rate limits, error conditions, response format (though output schema exists), or whether it's idempotent/safe. For a tool that likely involves sensitive data erasure status, this is insufficient behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero wasted words. It front-loads the core purpose ('Get the status') and efficiently specifies the scope ('of a specific data erasure request by resource ID'). Every word earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, sensitive data context), no annotations, and an output schema (which handles return values), the description is minimally adequate. It states what the tool does but lacks crucial context like parameter details, usage guidelines, and behavioral traits. The output schema mitigates some gaps, but overall completeness is limited.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description mentions 'by resource ID', which hints at the 'resource_id' parameter but doesn't explain what a resource ID is, its format, or where to obtain it. It completely ignores the 'tenant_id' parameter, leaving its purpose and optionality unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('status of a specific data erasure request'), making the purpose evident. It distinguishes from the sibling 'cdp_get_data_erasure_status' by specifying 'by resource ID', but doesn't explicitly contrast with other data-related tools like 'cdp_get_purge_status' or 'cdp_delete_data_erasure_request', keeping it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing erasure request ID), differentiate from 'cdp_get_data_erasure_status' (which might list multiple requests), or specify scenarios where this tool is appropriate over others like deletion or status-checking tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a read operation ('Get'), but doesn't reveal whether it requires authentication, has rate limits, returns structured data, or handles missing IDs. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words. It front-loads the core purpose ('Get a specific data export definition') and specifies the key identifier ('by ID'), making it efficiently scannable.
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 simple read operation, 2 parameters, and presence of an output schema (which handles return values), the description is minimally adequate. However, with no annotations and 0% schema coverage, it should provide more context about authentication, error handling, or parameter semantics to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so parameters are undocumented in the schema. The description mentions 'by ID' which corresponds to 'export_id', but doesn't explain what a valid ID looks like, its source, or the optional 'tenant_id' parameter's purpose. It adds minimal value beyond what's inferable from the parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('a specific data export definition by ID'), making the purpose immediately understandable. It distinguishes this from sibling tools like 'cdp_list_data_exports' (which lists multiple exports) and 'cdp_create_data_export' (which creates new exports), though this distinction is implicit rather than explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing export ID), contrast it with list operations, or specify error conditions. The agent must infer usage from the name and schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is a read operation ('Get'), which implies it's non-destructive, but doesn't specify whether it requires authentication, has rate limits, returns cached or real-time data, or what happens if the dataset_def_id doesn't exist. For a read tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just one sentence with no wasted words. It's front-loaded with the core purpose ('Get a specific datasetDef by ID') and doesn't include unnecessary details. Every word earns its place, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values) and is a relatively simple read operation with 2 parameters, the description is minimally complete. However, with 0% schema description coverage and no annotations, it should provide more context about parameter usage and behavioral expectations. The description meets the bare minimum but doesn't compensate for the lack of structured documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning neither parameter has descriptions in the schema. The description mentions 'by ID' which partially explains the 'dataset_def_id' parameter, but doesn't clarify what format the ID should be (integer as per schema) or provide examples. It completely ignores the 'tenant_id' parameter, leaving its purpose and when it's required undocumented. The description adds minimal value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('a specific datasetDef by ID'), making the purpose immediately understandable. It distinguishes itself from sibling tools like 'cdp_list_dataset_defs' by specifying retrieval of a single item rather than listing multiple items. However, it doesn't fully explain what a 'datasetDef' is or its significance in the CDP context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'cdp_list_dataset_defs' for browsing datasets or 'cdp_get_dataset_defs' (if it existed) for bulk retrieval. There's no context about prerequisites, permissions needed, or typical use cases for fetching a dataset definition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but provides minimal information. It states this is a retrieval operation ('Get'), implying it's likely read-only, but doesn't confirm this or describe any behavioral traits like authentication requirements, rate limits, error conditions, or what happens if the dispatch ID doesn't exist. For a tool with zero annotation coverage, this is inadequate disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is maximally concise with a single, clear sentence that states the core purpose upfront. There's no wasted language or unnecessary elaboration. Every word earns its place in communicating the essential function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a simple retrieval tool with an output schema (which should document return values) and only two parameters, the description covers the basic purpose adequately. However, with no annotations and 0% schema description coverage, it leaves significant gaps in understanding parameter semantics and behavioral context that could hinder effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions retrieving by ID, which aligns with the 'dispatch_id' parameter, but provides no additional semantic context beyond what's evident from the parameter name. With 0% schema description coverage and two parameters (dispatch_id and tenant_id), the description fails to explain what a 'dispatch definition' is, what format the ID should be in, or when/why the optional tenant_id parameter might be needed. It doesn't compensate for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('a specific dispatch definition'), making the purpose immediately understandable. It distinguishes from sibling tools like 'cdp_list_dispatches' by specifying retrieval of a single item by ID rather than listing multiple items. However, it doesn't fully differentiate from other 'get' tools in the system.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, appropriate contexts, or compare with similar tools like 'cdp_get_dispatch' vs 'cdp_list_dispatches' or other retrieval tools in the system. The agent receives no usage direction beyond the basic purpose statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states this is a 'Get' operation, implying a read-only action, but fails to mention potential side effects, authentication requirements, rate limits, or error handling. The description adds minimal context beyond the basic operation type.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words, front-loading the key action ('Get'). It is appropriately sized for a simple retrieval tool, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (simple retrieval), no annotations, 0% schema coverage, but the presence of an output schema (which handles return values), the description is minimally adequate. However, it lacks details on parameter semantics and behavioral traits, leaving gaps that could hinder correct usage despite the output schema covering return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning parameters are undocumented in the schema. The description mentions 'by ID', which hints at the 'group_id' parameter, but does not explain the 'tenant_id' parameter (its purpose, when it's required, or default behavior). It adds some meaning for one parameter but leaves the other unexplained, 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.
Purpose4/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 ('a specific execution summary group by ID'), making the purpose evident. It distinguishes from siblings like 'cdp_list_execution_summary_groups' (which lists groups) by specifying retrieval of a single group via ID, though it doesn't explicitly name the sibling for comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 'cdp_list_execution_summary_groups' or 'cdp_get_execution_bucket', nor does it mention prerequisites such as authentication or tenant context. Usage is implied by the need to fetch a specific group, but explicit alternatives or exclusions are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states this is a GET operation, implying it's read-only and non-destructive, but doesn't disclose any behavioral traits like authentication requirements, rate limits, error conditions, or what happens if the ID doesn't exist. For a tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Get a mailer account by id') and includes the API endpoint for technical context. There is zero waste or redundancy, making it appropriately sized for a simple retrieval tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (simple GET with 2 parameters) and the presence of an output schema (which handles return values), the description is minimally adequate. However, with no annotations and 0% schema coverage, it lacks crucial context like parameter meanings and behavioral details, leaving the agent to rely heavily on the schema and trial-and-error.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description mentions 'by id' but doesn't explain what 'id' represents (e.g., a mailer account identifier) or the optional 'tenant_id' parameter. It adds minimal semantics beyond the parameter names, failing 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.
Purpose4/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 ('a mailer account by id'), making the purpose specific and understandable. It distinguishes from siblings like 'cdp_list_mailer_accounts' (list operation) and 'cdp_create_mailer_account' (create operation) by focusing on retrieval of a single account. However, it doesn't explicitly contrast with other get operations like 'cdp_get_mailer_batch', leaving some room for improvement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing mailer account ID), when not to use it (e.g., for listing accounts), or refer to sibling tools like 'cdp_list_mailer_accounts' for broader queries. The agent must infer usage from the name and context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states this is a 'GET' operation, implying it's likely read-only and non-destructive, but doesn't confirm this or detail other behaviors like authentication requirements, rate limits, error handling, or what happens if the ID is invalid. For a tool with zero annotation coverage, this leaves significant gaps in understanding its operational traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('Get a mailer batch by id') and includes the API endpoint for context. There is no wasted verbiage, and it directly communicates the essential information without redundancy or unnecessary detail.
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 (simple retrieval), 2 parameters with 0% schema coverage, no annotations, and an output schema present (which likely describes return values), the description is minimally adequate. It states what the tool does but lacks details on parameters, behavioral context, and usage guidelines. The output schema reduces the need to explain returns, but the description doesn't fully compensate for other gaps, making it just viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description mentions 'by id', which hints at the 'id' parameter's purpose, but doesn't explain its format (e.g., string type, expected values) or mention the 'tenant_id' parameter at all. It adds minimal semantic value beyond the parameter names, 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.
Purpose4/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 ('a mailer batch by id'), making the purpose specific and understandable. It distinguishes from sibling tools like 'cdp_list_mailer_batches' (which lists multiple batches) by focusing on retrieval of a single batch via ID. However, it doesn't explicitly contrast with other 'get' tools (e.g., 'cdp_get_mailer_account'), leaving some ambiguity in 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. It doesn't mention prerequisites (e.g., needing a valid batch ID), exclusions (e.g., not for creating or updating batches), or direct comparisons to sibling tools like 'cdp_list_mailer_batches' for broader queries. Usage is implied only by the action 'Get', but no explicit context 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?
No annotations are provided, so the description carries the full burden. It implies a read operation ('Get') but doesn't disclose behavioral traits like authentication requirements, rate limits, error handling, or what happens if the identifier doesn't exist. The description is minimal and fails to add meaningful context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It front-loads the core action and includes the API endpoint for technical context, making it appropriately sized and well-structured for its purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (2 parameters, no nested objects) and the presence of an output schema, the description is minimally adequate. However, with no annotations and 0% schema coverage, it lacks details on authentication, error cases, or parameter meanings, making it incomplete for safe and effective use without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It mentions 'by id' which maps to the 'id' parameter, but doesn't explain the 'tenant_id' parameter or its purpose. The description adds minimal value beyond what the schema's property names imply, leaving key semantics unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('mailer identifier by id'), making the purpose specific and understandable. However, it doesn't differentiate from sibling tools like 'cdp_get_mailer_identifier_by_campaign_dispatch' or 'cdp_list_mailer_identifiers', which would require explicit scope or usage context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'cdp_get_mailer_identifier_by_campaign_dispatch' or 'cdp_list_mailer_identifiers'. It lacks context about prerequisites, such as needing a specific identifier, or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read-only operation ('Get'), but doesn't specify authentication requirements, rate limits, error conditions, or what the output contains. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary details. It uses minimal words to convey the essential action and resource, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, 1 required), no annotations, and an output schema present, the description is minimally adequate. It states what the tool does but lacks behavioral details, parameter explanations, and usage context. The output schema reduces the need to describe return values, but overall completeness is limited.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It mentions 'by id' which hints at the 'id' parameter, but doesn't explain the 'tenant_id' parameter or its optionality. The description adds minimal value beyond the schema, failing to fully address the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('a mailer subuser by id'), making the purpose specific and understandable. However, it doesn't distinguish this tool from sibling tools like 'cdp_get_mailer_account' or 'cdp_list_mailer_subusers', which would require explicit differentiation for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context for usage, or compare it to sibling tools like 'cdp_list_mailer_subusers' for listing multiple subusers or 'cdp_get_mailer_account' for related resources.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It implies a read operation ('Get') but does not disclose behavioral traits like authentication requirements, rate limits, error handling, or whether it's idempotent. The HTTP method hint ('GET') is minimal and doesn't add meaningful context beyond the action verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose with no wasted words. It includes the HTTP endpoint as supplementary detail without cluttering the main message, making it appropriately sized for a simple retrieval tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (2 parameters, 1 required) and the presence of an output schema (which handles return values), the description is minimally adequate. However, with no annotations and 0% schema coverage, it lacks context on permissions, errors, and parameter details, leaving gaps for safe and effective use by an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'instance ID' which maps to the required parameter 'instance_id', but does not explain the 'tenant_id' parameter (optional, default null) or provide any semantic context for either parameter (e.g., format, examples, or what 'mapped' means in relation to them). The description adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('a mapped provisioned resource') with a specific identifier ('by instance ID'), making the purpose explicit. It distinguishes from siblings like 'cdp_get_provision_instance' by specifying 'mapped', though it could be more explicit about what 'mapped' entails. No tautology or vagueness is present.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 other 'get' tools in the sibling list (e.g., 'cdp_get_provision_instance' or 'cdp_list_provision_instances'). It lacks context about prerequisites, exclusions, or typical use cases, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It implies a read-only operation ('Get'), but doesn't disclose authentication needs, rate limits, error handling, or response format. The existence of an output schema helps, but the description itself lacks critical context for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero wasted words. It's front-loaded with the core purpose ('Get a specific message definition'), making it easy to parse quickly. Every word earns its place by conveying essential information efficiently.
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 (simple retrieval), 2 parameters, and the presence of an output schema, the description is minimally adequate. However, with no annotations and 0% schema coverage, it lacks details on authentication, error cases, and parameter semantics. It meets a bare minimum but leaves gaps an agent would need to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so parameters are undocumented in the schema. The description mentions 'by ID' which hints at 'message_def_id', but doesn't explain the 'tenant_id' parameter (its purpose, when it's required, or why it defaults to null). It adds minimal value beyond the schema's structural information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('a specific message definition by ID'), making the purpose immediately understandable. It distinguishes from sibling tools like 'cdp_list_message_defs' (which lists multiple) and 'cdp_create_message_def' (which creates). However, it doesn't specify what a 'message definition' is in this context, which slightly 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a valid message_def_id), contrast with 'cdp_list_message_defs' for browsing, or indicate error conditions (e.g., what happens if the ID doesn't exist). Usage is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is a GET operation, implying read-only behavior, but doesn't address critical aspects like authentication requirements, error handling, rate limits, or what the output contains. This leaves significant gaps for safe and effective tool invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. It includes the HTTP method and endpoint pattern as extra context without unnecessary verbosity, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values) and no annotations, the description is minimally adequate for a simple read operation. However, it lacks details on parameter usage and behavioral context, making it incomplete for reliable agent use despite the output schema covering return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning parameters are undocumented in the schema. The description only mentions retrieving by 'id', which partially covers 'status_id' but ignores 'tenant_id' entirely. It fails to explain parameter formats, optionality, or relationships, providing insufficient compensation for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('a single orchestration status record by id'), making the purpose specific and understandable. However, it doesn't differentiate from sibling tools like 'cdp_get_orchestration_status_for_connector' or 'cdp_list_orchestration_status', which would require explicit comparison to achieve a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description mentions retrieving by ID but doesn't explain when to choose this over list operations or other get variants, leaving the agent without context for selection among similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states it's a GET operation (implying read-only) but doesn't mention authentication requirements, rate limits, error conditions, or what the orchestration status entails. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single sentence that directly states the tool's purpose and includes the API endpoint. There's no wasted verbiage, and it's front-loaded with the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (which should describe the return values), the description doesn't need to explain outputs. However, for a tool with 2 parameters (0% schema coverage) and no annotations, the description is too sparse—it doesn't clarify parameter semantics, usage context, or behavioral traits beyond the basic GET operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description only mentions 'connector' and 'tenantId' in the endpoint path without explaining what these IDs represent, their format, or where to obtain them. It adds minimal semantic value beyond what's inferable from the parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('orchestration status for a specific connector'), making it immediately understandable. It distinguishes from the sibling 'cdp_get_orchestration_status' by specifying 'for a connector' rather than general status, though it doesn't explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'cdp_get_orchestration_status' or 'cdp_get_connector'. It lacks context about prerequisites, timing, or typical use cases, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read-only operation ('Fetch') but doesn't specify permissions, rate limits, response format, or error handling. This is inadequate for a tool with potential complexity in log retrieval.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the key action and resource. It includes the API endpoint for context without unnecessary elaboration, making it appropriately 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 has an output schema (which handles return values) and no annotations, the description is minimally complete for a read operation. However, it lacks details on parameters, behavioral traits, and usage context, leaving gaps in overall understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter details. The description mentions the API endpoint but doesn't explain what 'status_id' or 'tenant_id' represent, their formats, or examples. It 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Fetch') and resource ('log for an orchestration status record'), making the purpose specific and understandable. It distinguishes from siblings like 'cdp_get_orchestration_status' by focusing on the log, but doesn't explicitly contrast with other log-related tools (none are listed).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., needing an existing orchestration status), exclusions, or related tools like 'cdp_get_orchestration_status', leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It implies a read operation ('Get'), but doesn't disclose permissions needed, rate limits, error conditions, or what happens if the ID doesn't exist. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (simple retrieval), 2 parameters with 0% schema coverage, no annotations, but an output schema exists, the description is minimally complete. It states the core action but lacks parameter details and behavioral context, though the output schema may cover return values. This is borderline adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but fails to do so. It mentions 'by ID' which aligns with 'connector_id', but doesn't explain the 'tenant_id' parameter or provide any context about parameter formats, constraints, or interactions. With 2 parameters and no schema descriptions, this is inadequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('a specific output connector by ID'), making the purpose unambiguous. It doesn't explicitly differentiate from sibling tools like 'cdp_list_output_connectors' or 'cdp_get_output_connector_def', but the specificity of 'by ID' implies a retrieval of a single item rather than 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 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 'cdp_list_output_connectors' or 'cdp_get_output_connector_def'. The description only states what it does, not the context or prerequisites for its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states this is a read operation ('Get'), which implies it's non-destructive, but doesn't address authentication needs, rate limits, error responses, or whether it returns full or partial definition data. For a tool with zero annotation coverage, this leaves significant gaps in understanding its operational behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words. It front-loads the core purpose ('Get a specific output connector definition') and specifies the key constraint ('by ID') efficiently. Every part of the sentence contributes essential information, making it highly concise and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (simple retrieval by ID), 2 parameters, and the presence of an output schema (which handles return values), the description is minimally adequate. However, with no annotations and 0% schema coverage, it fails to address authentication, errors, or parameter details, leaving the agent under-informed. It meets the bare minimum but doesn't compensate for the lack of structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description mentions 'by ID', which loosely maps to 'connector_def_id', but doesn't explain what this ID is (e.g., numeric identifier), its format, or how to obtain it. It completely ignores 'tenant_id' (optional parameter), leaving its purpose and when to use it undocumented. The description adds minimal value beyond the parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('a specific output connector definition by ID'), making the purpose unambiguous. It distinguishes this from sibling tools like 'cdp_list_output_connector_defs' (which lists multiple) and 'cdp_get_output_connector' (which retrieves an instance rather than a definition). However, it doesn't specify what an 'output connector definition' entails (e.g., configuration template), leaving some room for interpretation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives. The description implies it's for retrieving a single definition by ID, but it doesn't mention prerequisites (e.g., needing the ID from a list operation), contrast it with 'cdp_get_output_connector' (for instances), or specify error conditions (e.g., invalid ID). The agent must infer usage from the name and context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It mentions the HTTP method (GET) and a parameter effect ('provisioningAllowed' flag), but lacks details on permissions, rate limits, error conditions, or response format. For a read operation with zero annotation coverage, this leaves significant gaps in understanding tool 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 a single, efficient sentence that front-loads the core purpose and adds parameter guidance. No wasted words, though it could be slightly more structured (e.g., separating purpose from parameter notes).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters with 0% schema coverage and no annotations, the description is incomplete—it only explains one parameter's effect. However, the presence of an output schema reduces the need to describe return values in the description. For a read tool with moderate complexity, it's minimally adequate but lacks comprehensive 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 description coverage is 0%, so the schema provides no parameter documentation. The description adds value by explaining the 'validate' parameter's effect (includes 'provisioningAllowed' flag), but doesn't clarify 'service_id' or 'tenant_id' semantics. It partially compensates for the coverage gap but leaves two parameters unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('provisioning limit for a specific service'), making the purpose explicit. It distinguishes from siblings like 'cdp_list_provision_limits' by specifying retrieval for a single service rather than listing all limits. However, it doesn't fully differentiate from 'cdp_get_provision_service' or 'cdp_get_provision_instance', which might retrieve related provisioning 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. It mentions a 'validate' parameter effect but doesn't explain when to set it true/false or compare with sibling tools like 'cdp_list_provision_limits' for bulk retrieval. No prerequisites, exclusions, or context for tool selection are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates a read operation ('Get') but doesn't mention any side effects, authentication requirements, rate limits, or error handling. For a tool that likely interacts with a provisioning system, this omission is significant, leaving the agent without crucial operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Get a specific provision service by ID or name') and includes the API endpoint in parentheses for additional context. There is no wasted verbiage, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no annotations, but with an output schema), the description is minimally adequate. It covers the basic purpose but lacks details on usage, behavior, and parameter semantics. The presence of an output schema mitigates the need to describe return values, but overall completeness is limited, especially for a read operation in a system with many sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description adds minimal value by implying 'service_id_or_name' can be either an ID or name, but it doesn't explain the format, constraints, or purpose of 'tenant_id' (which is optional). For a tool with 2 parameters, this leaves most semantics undocumented, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('a specific provision service'), specifying it can be retrieved by 'ID or name'. It distinguishes from sibling tools like 'cdp_list_provision_services' by focusing on a single service rather than listing multiple. However, it doesn't explicitly contrast with other 'get' tools (e.g., 'cdp_get_provision_instance'), leaving some 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 guidance is provided on when to use this tool versus alternatives. The description mentions retrieving by 'ID or name' but doesn't specify prerequisites (e.g., authentication), error conditions, or when to choose this over similar tools like 'cdp_get_provision_instance'. This lack of context makes it harder 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states this is a read operation ('Get'), implying it's non-destructive, but doesn't disclose behavioral traits like authentication needs, rate limits, error conditions, or whether it's idempotent. For a tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the core purpose. The second sentence adds useful return value context without redundancy. It's efficiently structured but 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no annotations, but has an output schema), the description is minimally adequate. The output schema reduces the need to explain return values, but the lack of behavioral disclosure and incomplete parameter semantics leaves gaps. It meets basic requirements but lacks depth for safe and 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 0%, so the description must compensate. It mentions 'by ID', which clarifies the purpose of 'report_def_id', but doesn't explain 'tenant_id' or provide format/constraint details. The description adds minimal value beyond the schema, failing to fully address the coverage gap, warranting a 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 the action ('Get') and resource ('report definition by ID'), making the purpose evident. It distinguishes from sibling tools like 'cdp_list_report_defs' (which lists) and 'cdp_create_report_def' (which creates), but doesn't explicitly contrast them. The description is specific 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 is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, when-not scenarios, or direct comparisons with sibling tools like 'cdp_list_report_defs' for browsing or 'cdp_copy_report_def' for duplication. Usage context is implied but not articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool returns a full definition, which hints at a read-only operation, but does not disclose behavioral traits like error conditions, permissions required, rate limits, or whether it's idempotent. For a retrieval tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with zero waste, front-loading the core purpose and then specifying the return content. Every word earns its place, making it easy to parse and understand quickly without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (so return values are documented elsewhere), the description covers the basic purpose adequately. However, with no annotations, low schema coverage, and multiple parameters, it lacks details on usage, behavior, and parameter meaning, making it incomplete for optimal agent operation despite the output schema support.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'by ID' which relates to 'squery_def_id', but does not explain the 'tenant_id' parameter or provide any details on parameter formats, constraints, or interactions. With two parameters and no schema descriptions, the description adds minimal semantic value beyond the parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('SQueryDef by ID'), making the purpose specific. It distinguishes from siblings like 'cdp_list_squery_defs' (which lists multiple) and 'cdp_create_squery_def' (which creates), but doesn't explicitly contrast them. The description is not tautological and directly explains 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, context, or exclusions, leaving the agent to infer usage from the name and parameters alone. This lack of explicit guidance reduces effectiveness in tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is a read operation ('Get'), implying it's non-destructive, but doesn't address authentication needs, rate limits, error conditions, or what happens if the workflow ID doesn't exist. The optional version parameter hints at versioning behavior, but this isn't elaborated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just two sentences, with zero wasted words. The first sentence states the core purpose, and the second adds crucial optional functionality. Every element earns its place, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (which should document return values), the description's main gaps are in parameter semantics and behavioral context. For a simple read operation with three parameters (one required), the description covers the basic purpose but misses important details about parameter usage and system behavior that would help the agent use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It only mentions the workflow_id and version parameters, ignoring tenant_id entirely. It doesn't explain what constitutes a valid workflow ID, how version numbering works, or when tenant_id should be specified, leaving significant gaps in parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('a specific workflow by ID'), making the purpose evident. It distinguishes this from list-style operations by specifying retrieval of a single item, though it doesn't explicitly differentiate from other 'get' siblings like cdp_get_workflow_job or cdp_get_workflow_step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like cdp_list_workflows for browsing or cdp_get_workflow_job for related data, nor does it specify prerequisites or contextual constraints for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that results are paged (helpful), but doesn't mention whether this is a read-only operation, requires authentication, has rate limits, or what happens if tenant_id is null. For a list tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with zero waste. The first states the core action, the second adds critical behavioral detail (paging). It's front-loaded and appropriately sized for a list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (list with paging), no annotations, 0% schema coverage, but with an output schema (which handles return values), the description is partially complete. It covers the basic action and paging behavior but misses parameter explanations, authentication needs, and sibling differentiation that would make it fully adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'for a tenant' (hinting at tenant_id) and 'paged results' (hinting at offset/limit), but doesn't explain parameter purposes, defaults, or constraints. With 3 undocumented parameters, the description adds minimal semantic value beyond what's implied.
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 ('campaign definitions'), specifying scope ('for a tenant') and output behavior ('Returns paged results'). It distinguishes from sibling tools like 'cdp_get_campaign' (singular fetch) and 'cdp_list_campaign_runs' (different resource), though not explicitly named. The purpose is specific but could better differentiate 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 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. It mentions 'for a tenant' but doesn't clarify if tenant_id is required or optional, or when to use this over other campaign-related tools like 'cdp_list_campaign_templates' or 'cdp_list_campaign_runs'. The description lacks context about prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'Fetch all' but doesn't disclose behavioral traits like pagination, rate limits, authentication needs, or what 'connector links' represent. The API endpoint hint is minimal context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise with a single sentence that front-loads the core action. No wasted words, though this brevity contributes to gaps in other dimensions.
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 1 parameter with 0% schema coverage, no annotations, but an output schema exists, the description is minimally adequate. It states the basic purpose but lacks details on parameters, behavior, or differentiation from siblings, leaving significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds no information about the 'tenant_id' parameter, its purpose, or when to use it. The description fails to explain parameter 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 action ('Fetch all') and resource ('connector links'), with the specific API endpoint provided. It distinguishes from siblings like 'cdp_list_connector_links_by_class' by implying this is a general list without filtering by class, though not explicitly 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 versus alternatives like 'cdp_list_connector_links_by_class' or 'cdp_list_connectors'. The description mentions no filtering, but lacks explicit comparisons or prerequisites for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states it's a list operation, implying it's read-only and non-destructive, but doesn't disclose behavioral traits like pagination (hinted by offset/limit parameters), authentication needs, rate limits, or what 'configured' entails. This leaves significant gaps for safe and effective use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words, front-loading the core action and resource. It's appropriately sized for a simple list tool, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (a list operation) and the presence of an output schema (which handles return values), the description is somewhat complete but lacks key context. With no annotations and 0% schema coverage, it should explain more about parameters and behavior to fully guide the agent, but the output schema reduces the burden slightly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so parameters are undocumented in the schema. The description mentions 'for a tenant', which loosely relates to 'tenant_id', but doesn't explain the optional nature of parameters, what offset/limit do, or their defaults. It adds minimal meaning beyond the schema, failing to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('all configured connectors for a tenant'), making the purpose specific and understandable. However, it doesn't differentiate from sibling tools like 'cdp_list_connector_templates' or 'cdp_list_output_connectors', which list related but different resources, so it misses full 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, such as 'cdp_get_connector' for a single connector or other list tools for different resource types. There's no mention of prerequisites, context, or exclusions, leaving usage entirely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it's a list operation (implying read-only), but doesn't cover critical aspects like authentication requirements, rate limits, pagination behavior (implied by offset/limit parameters but not explained), error handling, or whether it's idempotent. For a tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two sentences that directly state the tool's purpose and return values. Every word earns its place with zero redundancy. It's front-loaded with the core functionality, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (list operation with pagination parameters), no annotations, and an output schema (which handles return value documentation), the description is minimally adequate. It covers the basic 'what' but lacks context on authentication, pagination usage, error scenarios, and sibling differentiation. The output schema reduces the burden, but behavioral gaps remain significant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description mentions 'for a tenant' which loosely relates to tenant_id, but doesn't explain what tenant_id is, its format, or default behavior. It doesn't address offset and limit at all, leaving their purpose (pagination) and usage undocumented. With 3 parameters and no schema help, the description adds minimal semantic 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 the action ('List') and resource ('all available OLAP cubes for a tenant'), specifying what it returns ('cube unique names and captions'). It distinguishes itself from siblings by focusing on cube metadata listing, unlike other list tools for different resources (e.g., cdp_list_audience_defs, cdp_list_dashboards). However, it doesn't explicitly differentiate from other cube-related tools like cdp_get_cube_status, making it slightly less specific than a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., authentication), compare it to other cube-related tools (e.g., cdp_get_cube_status for status checks), or specify scenarios where listing cubes is appropriate (e.g., initial discovery vs. detailed retrieval). This leaves the agent with minimal context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it's a list operation, implying read-only behavior, but doesn't mention pagination (via offset/limit parameters), authentication needs, rate limits, or what 'accessible' means in terms of permissions. This leaves significant gaps for a tool with parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values), 3 parameters with 0% schema coverage, and no annotations, the description is incomplete. It covers the basic purpose but lacks parameter details, behavioral context, and usage guidelines, making it minimally adequate but with clear gaps for effective tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so parameters are undocumented in the schema. The description mentions 'tenant' but doesn't explain the three parameters (tenant_id, offset, limit) or their roles (e.g., pagination, optional defaults). It adds minimal value beyond implying a tenant context, failing to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('all accessible dashboards for a tenant'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'cdp_get_dashboard' (which retrieves a single dashboard) or other list tools, missing full 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?
No guidance is provided on when to use this tool versus alternatives. The description lacks context on prerequisites, access requirements, or comparisons to siblings like 'cdp_list_widgets' or 'cdp_get_dashboard', leaving the agent without 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?
No annotations are provided, so the description carries full burden. It states it's a list operation (implying read-only), but doesn't disclose behavioral traits like pagination behavior (though offset/limit parameters hint at it), authentication requirements, rate limits, error conditions, or whether it returns all exports or only active ones. For a list tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It front-loads the core purpose ('List all data export definitions') and efficiently specifies the scope ('for a tenant'). Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (list operation), 3 parameters with 0% schema coverage, no annotations, but an output schema exists, the description is minimally adequate. The output schema likely covers return values, reducing the need for description detail. However, for a tool with undocumented parameters and no behavioral context, it should do more to compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides only parameter names (tenant_id, offset, limit) with no descriptions. The description mentions 'for a tenant' which loosely relates to tenant_id, but doesn't explain what tenant_id is, whether it's required, or the semantics of offset/limit for pagination. It adds minimal value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List all') and resource ('data export definitions for a tenant'), making the tool's purpose immediately understandable. It distinguishes from siblings like 'cdp_get_data_export' (singular) and 'cdp_run_data_export' (execution), but doesn't explicitly contrast with other list tools like 'cdp_list_audience_defs' or 'cdp_list_campaigns' beyond 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?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., authentication), when not to use it, or how it differs from other list tools in the server. The agent must infer usage from the name and context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states it's a list operation (implying read-only), but doesn't disclose any behavioral traits such as pagination, rate limits, authentication requirements, sorting, or what 'dispatch definitions' entail. For a tool with zero annotation coverage, this leaves significant gaps in understanding how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action ('List dispatch definitions'), making it immediately clear. Every word earns its place, and there's no redundancy or 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?
Given the tool's low complexity (list operation), 2 parameters, and the presence of an output schema (which handles return values), the description is minimally adequate. However, with no annotations and 0% schema coverage, it lacks details on behavioral context and parameter semantics, making it incomplete for confident use without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description mentions 'for a campaign' which hints at 'campaign_id', but doesn't explain what 'campaign_id' is, its format, or the optional 'tenant_id' parameter. It adds minimal meaning beyond the bare schema, failing to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('dispatch definitions for a campaign'), making the purpose specific and understandable. It distinguishes from siblings like 'cdp_get_dispatch' (singular fetch) and 'cdp_list_campaigns' (different resource), though it doesn't explicitly contrast with 'cdp_list_campaign_runs' or 'cdp_get_run_dispatches' which are related but not identical.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a valid campaign_id), exclusions, or comparisons to siblings like 'cdp_get_dispatch' (for single dispatch) or 'cdp_get_run_dispatches' (for run-specific dispatches). Usage is implied only by the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'List' implies a read-only operation, the description doesn't mention pagination behavior (despite offset/limit parameters), authentication requirements, rate limits, or what the output contains. For a list tool with three parameters, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core purpose without unnecessary words. It's appropriately sized for a list operation and gets straight to the point with zero wasted 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 that an output schema exists (which should document return values), the description's main gaps are parameter semantics and usage guidance. However, with no annotations and 0% schema coverage for three parameters, the description doesn't provide enough context for effective tool selection and invocation. It's minimally adequate but leaves important questions unanswered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and three parameters (tenant_id, offset, limit), the description provides no information about parameter meanings or usage. It doesn't explain what tenant_id filters, how offset/limit work for pagination, or whether parameters are optional (they are, but this isn't stated). The description fails to compensate for the complete lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 ('DQE Phase 1 data quality rules'), making the purpose immediately understandable. However, it doesn't differentiate from its sibling 'cdp_list_dqe2_rules' beyond the phase number, missing an opportunity to clarify what distinguishes DQE Phase 1 from Phase 2 rules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'cdp_get_dqe1_rule' (for retrieving a single rule) and 'cdp_list_dqe2_rules' (for Phase 2 rules), there's no indication of when this list operation is appropriate versus those other options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions a requirement ('Requires a schedule type') but doesn't describe whether this is a read-only operation, what permissions are needed, how results are returned (e.g., pagination via offset/limit), or error conditions. The description is minimal and leaves key behavioral traits unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief (two sentences) and front-loaded with the core purpose. Every sentence adds information (listing action and required parameter, then optional filters). However, it could be more structured by explicitly separating required and optional parameters.
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 (6 parameters, 1 required), 0% schema coverage, no annotations, but an output schema exists, the description is incomplete. It doesn't explain parameter meanings, behavioral traits, or usage context adequately. The output schema may cover return values, but the description fails to provide necessary operational context for a tool with multiple parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions schedule_type, entityType, and entityId, but doesn't explain what these mean (e.g., what values schedule_type accepts, what entityType refers to). It omits tenant_id, offset, and limit entirely, leaving 3 of 6 parameters undocumented. The description adds minimal value beyond naming some 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 action ('List schedules') and the target resource ('for a tenant'), which is specific and distinguishes it from sibling tools like cdp_get_schedule (singular) or cdp_create_schedule. However, it doesn't explicitly differentiate from other list tools (e.g., cdp_list_campaigns) beyond 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by stating 'Requires a schedule type' and mentions optional filters, but doesn't provide explicit guidance on when to use this tool versus alternatives like cdp_get_schedule or cdp_list_workflows. No when-not-to-use scenarios or prerequisites beyond the required parameter are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states a list operation but does not describe key traits like whether it's read-only, paginated (implied by offset/limit parameters but not explained), rate limits, authentication needs, or error handling. For a tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary details. It uses clear language and avoids redundancy, making it appropriately sized for its informational content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (a list operation), no annotations, 0% schema coverage, but the presence of an output schema (which handles return values), the description is minimally adequate. However, it lacks details on pagination, tenant context, and behavioral traits, making it incomplete for effective use without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning parameters (tenant_id, offset, limit) are undocumented in the schema. The description only mentions 'for a tenant', loosely relating to tenant_id but not explaining its purpose, format, or optionality. It adds minimal meaning beyond the schema, failing to compensate for the coverage gap, especially for offset and limit which are common pagination parameters but unaddressed.
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') and resource ('SQueryDefs (SQL query definitions) for a tenant'), providing a specific verb+resource combination. However, it does not distinguish this tool from sibling list tools like 'cdp_list_cubic_set_defs' or 'cdp_list_report_defs', which follow similar patterns but target different resources, so it lacks 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?
The description provides no guidance on when to use this tool versus alternatives, such as other list tools for different resources or more specific query tools. It mentions 'for a tenant' but does not clarify prerequisites, exclusions, or related tools like 'cdp_get_squery_def' for individual retrieval, leaving usage context implied at best.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it's a list operation, implying read-only behavior, but doesn't mention any traits like pagination (though offset/limit parameters suggest it), authentication needs, rate limits, or what happens if tenant_id is null. The description is minimal and leaves key behavioral aspects unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It is appropriately sized and front-loaded, directly stating the tool's purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a list operation with 3 parameters), no annotations, 0% schema coverage, but with an output schema present, the description is incomplete. It lacks details on parameter semantics, behavioral traits, and usage context. The output schema mitigates the need to describe return values, but other gaps remain significant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It only mentions 'tenant' implicitly via 'for a tenant', but doesn't explain the purpose of tenant_id, offset, or limit parameters. The description adds minimal meaning beyond the schema, failing to clarify parameter roles or 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 action ('List') and the resource ('summary customizations for a tenant'), providing a specific verb+resource combination. It distinguishes itself from siblings like 'cdp_get_summary_customization' (singular retrieval) by indicating it lists multiple items, though it doesn't explicitly differentiate from other list tools like 'cdp_list_audience_defs' beyond 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, such as 'cdp_get_summary_customization' for a single customization or other list tools for different resources. It lacks context on prerequisites, exclusions, or typical scenarios for listing summary customizations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it's a list operation, implying read-only behavior, but doesn't disclose pagination behavior (despite offset/limit parameters), authentication requirements, rate limits, or what 'accessible to the current user' entails. The description is minimal and lacks behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core purpose and appropriately sized for a simple list tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which likely describes the return structure), the description doesn't need to explain return values. However, with no annotations, 0% schema coverage for parameters, and multiple sibling tools, the description is too minimal—it doesn't address pagination, filtering, or differentiation from alternatives, leaving gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions no parameters at all, failing to explain what 'offset' and 'limit' do, their default values, or how they affect the listing. With two undocumented parameters, the description adds zero value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('tenants'), specifying that it returns all tenants accessible to the current user. It distinguishes from siblings like 'cdp_get_tenant' (singular) by indicating it's a list operation, but doesn't explicitly contrast with other list tools (e.g., 'cdp_list_users').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, when not to use it, or how it differs from other tenant-related tools like 'cdp_get_tenant' or 'cdp_list_tenant_clusters'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions listing resources but doesn't disclose behavioral traits like pagination (implied by offset/limit parameters), rate limits, authentication requirements, or whether it's a read-only operation. The description is minimal and lacks necessary context for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded and appropriately sized for a simple list operation, avoiding unnecessary elaboration while stating the core purpose 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 3 parameters with 0% schema coverage, no annotations, and an output schema (which reduces need to describe returns), the description is incomplete. It covers the basic purpose but lacks parameter details and behavioral context, making it adequate only for minimal understanding with significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds no parameter semantics beyond the schema's titles (Tenant Id, Offset, Limit). For instance, it doesn't explain what 'tenant_id' filters, how offset/limit work for pagination, or default behaviors. This leaves parameters largely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('UDMP resources'), specifying they are 'available data resources in the platform'. This distinguishes it from other list tools like cdp_list_udmp_tables, though it could be more explicit about what UDMP resources entail compared to 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 is provided on when to use this tool versus alternatives. For example, it doesn't mention when to use cdp_list_udmp_tables or cdp_describe_resource instead, or any prerequisites like authentication. The description only states what it does, not when to apply it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'faster response' (a performance trait) and 'fewer fields' (output format), which adds some behavioral context. However, it doesn't disclose critical details like whether this is a read-only operation, if it requires authentication, pagination behavior (implied by offset/limit parameters but not explained), rate limits, or error conditions. For a list tool with zero annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('List all users') and immediately adds qualifying details ('in lightweight format') and benefits ('fewer fields, faster response'). There is zero wasted verbiage, and every word earns its place by conveying 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?
Given the tool's moderate complexity (list operation with pagination parameters), no annotations, 0% schema description coverage, but with an output schema present, the description is incomplete. It covers the 'what' and 'why' (lightweight format) but misses parameter explanations, behavioral details (e.g., pagination, auth), and doesn't leverage the output schema to clarify what 'fewer fields' entails. For a tool with undocumented parameters, this is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 3 parameters (tenant_id, offset, limit) with 0% description coverage in the schema (titles only). The description provides no information about these parameters—it doesn't explain what tenant_id refers to, how offset/limit work for pagination, or their default behaviors. With low schema coverage, the description fails to compensate, leaving parameters undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List all users') and specifies the format ('lightweight format') and performance characteristics ('fewer fields, faster response'). It distinguishes itself from potential siblings like 'cdp_list_users' by emphasizing the lightweight nature, though it doesn't explicitly name that sibling. The purpose is specific and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning 'fewer fields, faster response,' suggesting this tool is preferred when speed is prioritized over data completeness. However, it doesn't explicitly state when NOT to use it (e.g., when full user details are needed) or name alternative tools like 'cdp_list_users' or 'cdp_get_user_lite' from the sibling list. The guidance is 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the default return fields (id, name, editedby, editeddate), which adds some behavioral context, but fails to disclose critical traits like pagination behavior (implied by offset/limit parameters), authentication needs, rate limits, or whether it's a read-only operation. For a list tool with zero annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('List all accessible widgets for a tenant') and adds useful detail about default return fields. There is zero waste, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no annotations, but with an output schema), the description is partially complete. It covers the basic purpose and return format, but lacks parameter explanations, usage guidelines, and behavioral details. The output schema likely documents return values, reducing the burden, but key operational context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'tenant' but doesn't explain the 'tenant_id' parameter's purpose, format, or default behavior. It ignores 'offset' and 'limit' entirely, leaving pagination undocumented. The description adds minimal value beyond the bare schema, failing to clarify parameter usage or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('all accessible widgets for a tenant'), specifying the scope. It distinguishes from siblings like 'cdp_get_widget' (singular retrieval) and 'cdp_copy_widget' (copy operation), though it doesn't explicitly name alternatives. The purpose is specific and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 'cdp_get_widget' (for single widget details) or 'cdp_list_dashboards' (for related resources). The description implies usage for listing widgets but offers no context about prerequisites, tenant selection, or pagination strategies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'List all steps', implying a read-only operation, but doesn't clarify critical aspects like pagination, rate limits, authentication requirements, or what 'all' entails (e.g., if it includes archived steps). For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('List all steps') and specifies the resource ('in a workflow DAG'). There is no wasted verbiage, and it directly communicates the tool's function without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, 1 required), no annotations, and an output schema (which handles return values), the description is minimally adequate. It states what the tool does but lacks details on parameters, usage context, and behavioral traits. The output schema mitigates some completeness issues, but the description alone is insufficient for full understanding without additional structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 3 parameters (workflow_id, version, tenant_id) have descriptions in the schema. The tool description adds no information about these parameters—it doesn't explain what a workflow_id is, how version affects the listing (e.g., defaulting to latest), or when tenant_id is needed. With low schema coverage, the description fails to compensate, leaving parameters largely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 ('steps (nodes) in a workflow DAG'), making the purpose specific and understandable. It distinguishes itself from siblings like 'cdp_list_workflows' or 'cdp_list_workflow_edges' by focusing on steps within a workflow. However, it doesn't explicitly differentiate from 'cdp_get_workflow_step' (singular), which might retrieve a single step, so it's not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a valid workflow_id), exclusions, or comparisons with siblings like 'cdp_list_workflow_step_types' or 'cdp_get_workflow_step'. Without such context, an agent might struggle to choose appropriately among similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions 'soft-deleted' and implies a mutation (restore), but fails to disclose critical behavioral traits such as required permissions, whether the restore is reversible, potential side effects, or rate limits. This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('Restore a soft-deleted mailer account') and includes the API endpoint for technical context. There is no wasted verbiage, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is an output schema (which handles return values) and no annotations, the description is minimally complete for a mutation tool but lacks depth. It specifies the action and resource but omits important context like error conditions, success indicators, and parameter meanings, making it adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description adds no semantic information about the 'id' (e.g., that it refers to a mailer account ID) or 'tenant_id' parameters, failing to compensate for the lack of schema documentation. This leaves both parameters poorly understood.
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 ('Restore') and resource ('a soft-deleted mailer account'), making the purpose specific and understandable. However, it does not explicitly differentiate from sibling tools like 'cdp_restore_emailable_page' or 'cdp_restore_mailer_subuser', which share the 'restore' action but target different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as 'cdp_update_mailer_account' or 'cdp_create_mailer_account', nor does it mention prerequisites like needing a soft-deleted account ID. It lacks context for distinguishing from other restore or mailer-related 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Restore' implies a mutation (undoing a deletion), the description doesn't specify required permissions, whether the restoration is immediate or asynchronous, potential side effects (e.g., reactivating associated features), or error conditions. For a mutation tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Restore a soft-deleted mailer subuser') and includes the HTTP method and endpoint for context. There is no wasted verbiage, making it highly concise and well-structured for quick 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 tool has an output schema (which likely describes the response), the description doesn't need to explain return values. However, as a mutation tool with no annotations, 0% schema description coverage, and two parameters, the description is incomplete—it lacks details on behavioral traits, parameter meanings, and usage context. The presence of an output schema raises the baseline, but gaps remain significant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description mentions 'POST /v2/{tenantId}/mailer/subusers/{id}', which hints that 'id' and 'tenant_id' are path parameters, but it doesn't explain what 'id' refers to (e.g., subuser identifier) or when 'tenant_id' is required versus optional. The description adds minimal semantic value beyond the schema's structure.
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 ('Restore') and resource ('soft-deleted mailer subuser'), which is specific and unambiguous. It distinguishes from sibling tools like 'cdp_delete_mailer_subuser' and 'cdp_create_mailer_subuser' by focusing on restoration of deleted items. However, it doesn't explicitly differentiate from 'cdp_restore_mailer_account' or 'cdp_restore_emailable_page', which are similar restore operations on different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., that the subuser must be soft-deleted first), when restoration might fail, or what happens after restoration. Given the sibling tools include various mailer operations, explicit context for choosing this restore tool is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'resume' implies a state change (from suspended to active), the description doesn't address permission requirements, side effects, rate limits, or what happens if the job isn't suspended. It lacks crucial context for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point with no wasted words. It's appropriately sized for a simple action tool and front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 3 parameters (2 required) and no annotations, the description is minimal but covers the basic action. The existence of an output schema helps, but the description doesn't address behavioral aspects or parameter meanings. It's adequate for the simplest understanding but lacks depth needed for confident tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The tool description adds no information about the three parameters (workflow_id, job_id, tenant_id) - it doesn't explain what they represent, their format, or how they relate to resuming a job. This leaves parameters completely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Resume a suspended workflow job' clearly states the action (resume) and target resource (suspended workflow job), making the tool's purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'cdp_rerun_job' or 'cdp_kill_job' which also operate on jobs, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'cdp_rerun_job' or 'cdp_kill_job' (both sibling tools). It doesn't mention prerequisites (e.g., the job must be suspended) or context for when resuming is appropriate versus other job actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is an update operation (implying mutation) but doesn't disclose any behavioral traits: no information about required permissions, whether changes are reversible, rate limits, error conditions, or what happens to fields not included in the update. The description adds minimal context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two sentences that directly state the action and parameter format. Every word earns its place with zero redundancy. It's front-loaded with the core purpose and follows with essential parameter guidance.
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 this is a mutation tool with 3 parameters (2 required), 0% schema coverage, no annotations, but with an output schema present, the description is minimally adequate. The output schema existence means return values are documented elsewhere, but the description lacks crucial context about permissions, side effects, and parameter details needed for safe invocation of an update operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description mentions 'updated fields as a JSON string' which partially explains the 'body' parameter, but doesn't clarify what fields can be updated, the JSON structure, or the purpose of 'audience_def_id' and 'tenant_id'. It adds some meaning but doesn't adequately compensate for the complete lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 ('existing audience definition'), making the purpose unambiguous. It distinguishes from siblings like cdp_create_audience_def (creation) and cdp_delete_audience_def (deletion), though it doesn't explicitly differentiate from other update tools like cdp_update_campaign. The description is specific enough to understand what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing audience definition ID), when not to use it, or how it differs from similar update tools in the sibling list (e.g., cdp_update_campaign, cdp_update_report_def). The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states it's an update operation (implying mutation) but doesn't cover critical aspects like required permissions, whether changes are reversible, rate limits, error conditions, or what the output schema contains. This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action. It wastes no words, though it could be slightly more structured (e.g., separating parameter hints).
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 a mutation tool with 3 parameters (0% schema coverage), no annotations, but an output schema exists, the description is minimally adequate. It covers the basic purpose and hints at parameters, but lacks behavioral context, usage guidelines, and full parameter semantics, leaving the agent reliant on the output schema for 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 description coverage is 0%, so the schema provides no parameter descriptions. The description adds minimal semantics: it mentions 'ID' (mapping to 'dashboard_id') and 'updated fields as a JSON string' (mapping to 'body'), but doesn't explain the optional 'tenant_id' or provide format details for the JSON string. It partially compensates but leaves key parameters inadequately documented.
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 ('Update') and resource ('an existing dashboard by ID'), making the purpose evident. It distinguishes from siblings like 'cdp_create_dashboard' (creation) and 'cdp_delete_dashboard' (deletion), but doesn't explicitly differentiate from other update tools (e.g., 'cdp_update_widget').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., dashboard must exist), exclusions, or comparisons to other update tools in the sibling list, leaving the agent with no contextual usage cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is an update operation (implying mutation) and mentions the HTTP method (PUT), but fails to disclose critical traits: whether it requires specific permissions, if it's idempotent, what happens on partial updates, or any rate limits. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two sentences that directly state the tool's function and parameter format. Every word earns its place: the first sentence defines the action and resource, while the second specifies the parameter requirement. There's no fluff or redundancy, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (mutation operation), lack of annotations, and 0% schema description coverage, the description is minimally adequate. It identifies the tool as an update operation and specifies the parameter format, but fails to cover behavioral aspects, parameter details, or usage context. The presence of an output schema (per context signals) means return values are documented elsewhere, slightly mitigating the incompleteness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions that 'body' should be 'the updated erasure request body as a JSON string', which adds some meaning beyond the schema's generic 'string' type. However, it doesn't explain the structure of the JSON, what fields are updatable, or the purpose of 'tenant_id' (optional tenant context). With 2 parameters and no schema descriptions, this partial guidance is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and resource ('an existing data erasure request'), making the purpose immediately understandable. It distinguishes itself from sibling tools like 'cdp_request_data_erasure' (create) and 'cdp_delete_data_erasure_request' (delete) by focusing on modification. However, it doesn't specify what aspects can be updated (e.g., status, metadata), which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing request ID), compare it to 'cdp_data_erasure_status_override' (a sibling that might handle status changes), or indicate when not to use it (e.g., for creating new requests). The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states 'Update' which implies a mutation, but doesn't disclose behavioral traits like required permissions, whether the update is idempotent, rate limits, or what happens on failure. The mention of 'JSON string' for the body adds some context, but overall, critical behavioral information is missing for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two sentences with zero waste. It front-loads the core action ('Update an emailable page') and adds necessary technical detail (HTTP endpoint and JSON requirement). Every word earns its place, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (mutation with 3 parameters), lack of annotations, and 0% schema description coverage, the description is incomplete. It doesn't cover parameter meanings, behavioral risks, or usage context. However, the presence of an output schema reduces the need to explain return values, and the conciseness is appropriate for the provided information, making it minimally adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'updated definition as a JSON string' which loosely maps to the 'body' parameter, but doesn't explain what 'page_id' or 'tenant_id' are, their formats, or provide examples. With 3 parameters (2 required) and no schema descriptions, the description adds minimal value beyond implying JSON usage for 'body'.
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 ('an emailable page'), making the purpose explicit. It distinguishes from sibling tools like 'cdp_create_emailable_page' and 'cdp_delete_emailable_page' by specifying it's an update operation. However, it doesn't fully differentiate from other update tools (e.g., 'cdp_update_campaign') beyond 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 doesn't mention prerequisites (e.g., needing an existing page), exclusions, or when to choose other tools like 'cdp_create_emailable_page' for creation or 'cdp_get_emailable_page' for retrieval. The HTTP method hint (PUT) is technical but doesn't offer practical usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but lacks behavioral details. It states it's an update operation but doesn't disclose permissions required, whether it's idempotent, what happens on partial updates, or error handling. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two short sentences with zero wasted words. It's front-loaded with the core action and resource, making it easy to scan and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which reduces need to describe return values) but zero schema description coverage and no annotations, the description is minimally complete. It identifies the tool as an update operation but lacks details on parameters, behavior, and usage context, making it only partially adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds minimal value. It mentions 'updated fields as a JSON string' for the 'body' parameter, but doesn't explain the JSON structure, what fields are updatable, or the purpose of 'tenant_id'. This leaves key parameter semantics undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and resource ('a message definition by ID'), making the purpose evident. It distinguishes from siblings like 'cdp_create_message_def' (create) and 'cdp_delete_message_def' (delete), but doesn't explicitly differentiate from other update tools (e.g., 'cdp_update_campaign').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., needing an existing message definition), exclusions, or compare it to similar update tools in the sibling list, leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states this is an update operation (implying mutation) but doesn't disclose critical behavioral traits: required permissions, whether the update is partial/full, validation rules for the JSON body, error handling, or what the output contains. For a mutation tool with zero annotation coverage, this leaves the agent guessing about important operational aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (two sentences) and front-loaded with the core purpose. Every word earns its place—there's no fluff or redundant information. It efficiently communicates the essential action and input format.
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 (mutation operation with 3 parameters), lack of annotations, and 0% schema coverage, the description is incomplete. However, the presence of an output schema somewhat mitigates the need to describe return values. The description covers the basic 'what' but misses crucial context about how the update works, error conditions, and parameter details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'ID' (mapping to report_def_id) and 'updated fields as a JSON string' (mapping to body), but provides no details about JSON structure, accepted fields, or format. The optional tenant_id parameter isn't mentioned at all. With 3 parameters and no schema descriptions, the description adds minimal value beyond naming two parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Update an existing report definition by ID. Pass updated fields as a JSON string.' It specifies the verb ('update'), resource ('report definition'), and key mechanism (ID-based update with JSON payload). However, it doesn't explicitly differentiate from sibling update tools like cdp_update_audience_def or cdp_update_campaign, which follow the same pattern.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing report definition ID), when not to use it, or what happens if the ID doesn't exist. With many sibling tools including cdp_copy_report_def and cdp_create_report_def, the lack of differentiation 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Update an existing role,' implying a mutation operation, but does not disclose critical traits such as required permissions, whether the update is reversible, side effects (e.g., impact on users with this role), rate limits, or error handling. The JSON string formatting note adds minimal context, leaving significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two sentences—with zero wasted words. It is front-loaded with the core purpose ('Update an existing role.') and follows with specific parameter formatting advice. Every sentence earns its place, making it highly efficient in structure.
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 (mutation with 6 parameters, no annotations, schema coverage 0%), the description is incomplete. It lacks behavioral context, usage guidelines, and full parameter semantics. While an output schema exists (which mitigates the need to describe return values), the description does not address critical aspects like authentication needs, error conditions, or how partial updates (null parameters) are handled, making it inadequate for safe and 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 0%, so the description must compensate. It mentions 'whitelist/blacklist/included as JSON strings,' which adds semantic meaning for three parameters beyond their schema titles. However, it does not explain the other three parameters (role_id, tenant_id, name) or their relationships. With 6 parameters total and partial coverage, the description provides some value but falls short of fully compensating for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Update an existing role.' It specifies the verb ('Update') and resource ('role'), and distinguishes it from sibling tools like 'cdp_create_role' (creation) and 'cdp_delete_role' (deletion). However, it does not explicitly differentiate from other update tools (e.g., 'cdp_update_user'), which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions 'Pass whitelist/blacklist/included as JSON strings,' but this is parameter formatting advice, not usage context. There is no mention of prerequisites, when-not-to-use scenarios, or comparisons with sibling tools like 'cdp_get_role' or 'cdp_list_roles' for read operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions 'Update' (implying mutation) and that fields are passed as JSON, but doesn't disclose critical behavioral traits like required permissions, whether the update is partial/full, validation behavior, error handling, or rate limits. For a mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two sentences with zero waste. It's front-loaded with the core purpose and follows with a brief parameter note. Every word earns its place, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (mutation with 3 parameters), lack of annotations, and 0% schema coverage, the description is incomplete. However, the presence of an output schema (from context signals) means return values are documented elsewhere, reducing the burden slightly. Still, for a mutation tool, more behavioral and parameter context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description adds minimal value: it mentions 'ID' (implied for 'squery_def_id') and 'updated fields as a JSON string' (implied for 'body'), but doesn't explain the JSON structure, purpose of 'tenant_id', or any constraints. With 3 parameters and 0% schema coverage, the description fails to compensate adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and resource ('existing SQueryDef by ID'), making the purpose unambiguous. It distinguishes from siblings like 'cdp_create_squery_def' (create) and 'cdp_delete_squery_def' (delete), but doesn't explicitly differentiate from other update tools like 'cdp_update_audience_def' or 'cdp_update_campaign' beyond 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?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing SQueryDef ID), constraints, or when other tools like 'cdp_copy_squery_def' or 'cdp_clone_resource' might be more appropriate. The description only states what it does, not when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states it's an update operation. It lacks details on permissions required, whether updates are partial or full, side effects (e.g., on dependent resources), rate limits, or error handling. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with zero waste, front-loading the core action and key parameter details. Every word serves a purpose, making it highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters with 0% schema coverage, no annotations, but an output schema exists, the description is minimally adequate. It covers the basic operation and required parameters but lacks behavioral context, optional parameter explanation, and output details (though the output schema mitigates this). For a mutation tool, more guidance is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'widget_id' and 'body' (as a JSON string), covering the two required parameters, but doesn't explain 'tenant_id' (optional) or provide examples of valid JSON structures for 'body'. This leaves significant gaps in parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and resource ('an existing widget by ID'), making the purpose evident. It distinguishes from sibling tools like 'cdp_create_widget' and 'cdp_delete_widget' by specifying it's for updates, though it doesn't explicitly contrast with other update tools (e.g., 'cdp_update_campaign').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 doesn't mention prerequisites (e.g., needing an existing widget ID), exclusions (e.g., what fields can't be updated), or refer to related tools like 'cdp_get_widget' for fetching IDs or 'cdp_copy_widget' for duplication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool performs a validation check, implying a read-only operation, but does not disclose critical details like authentication requirements, rate limits, error conditions, or what 'valid' entails (e.g., expiration time). This leaves significant gaps for a tool that likely interacts with user security data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('Validate a password reset code') and adds clarifying detail. There is no wasted verbiage, making it appropriately sized and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is an output schema (which handles return values), no annotations, and low schema coverage, the description is minimally adequate. It covers the basic purpose but lacks depth in behavioral context and parameter guidance. For a security-related tool with two required parameters, more detail on validation outcomes and usage context would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the input schema provides no descriptions for parameters. The description mentions 'reset code' and 'given user', hinting at the parameters, but does not add meaningful semantics such as format examples (e.g., username format, reset code structure) or constraints beyond what the bare schema titles imply. It partially compensates but falls short given the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('validate') and resource ('password reset code'), and it explains the action ('checks whether the reset code is still valid for the given user'). However, it does not explicitly differentiate from sibling tools like 'cdp_generate_password_reset', which might be related, leaving room for improvement in 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, such as 'cdp_generate_password_reset' or 'cdp_update_password', nor does it mention prerequisites like needing a pre-generated reset code. It only describes what the tool does without contextual usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only mentions the GET endpoint and conditional behavior based on event_id. It doesn't describe authentication needs, rate limits, error conditions, whether this is a read-only operation (implied by 'Get' but not explicit), or what the response format looks like. For a status-checking tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences that directly address the tool's function and key parameter behavior. It's front-loaded with the main purpose and follows with conditional logic. There's no wasted language, though it could be slightly more structured by explicitly separating parameter explanations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (status retrieval with optional filtering), no annotations, 0% schema coverage, but presence of an output schema, the description is minimally adequate. The output schema existence means return values don't need description, but the description should better explain parameter usage and behavioral context. It covers the basic purpose but leaves too many operational questions unanswered for a tool interacting with data purge systems.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% (parameters only have titles 'Tenant Id' and 'Event Id'), so the description must compensate. It only mentions event_id ('If event_id is supplied, returns status for that specific purge event'), adding some semantics for that parameter. However, it completely ignores tenant_id - not explaining its purpose, whether it's required, or how it affects the query. With 2 parameters and low schema coverage, this partial coverage is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get data-purge status' with the specific verb 'Get' and resource 'data-purge status'. It distinguishes from siblings by focusing on purge status retrieval rather than other CDP operations like cache management or campaign execution. However, it doesn't explicitly differentiate from similar status-checking tools like 'cdp_get_data_erasure_status' or 'cdp_get_orchestration_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?
The description provides implied usage guidance by stating 'If event_id is supplied, returns status for that specific purge event', suggesting it can be used for both general status checks and specific event queries. However, it lacks explicit when-to-use guidance compared to alternatives (e.g., when to use this vs. 'cdp_get_data_erasure_status'), and doesn't mention prerequisites like authentication or tenant context requirements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool sends a specific body payload ('{"dataExportProperties":"{}"}') to match UI contracts, which is useful behavioral detail. However, it doesn't mention critical aspects like whether this is a read-only or destructive operation, authentication requirements, rate limits, expected response format, or error conditions. For a tool that likely triggers data processing, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (two sentences) and front-loaded with the core purpose. Every sentence adds value: the first explains what the tool does, and the second provides crucial implementation detail about the payload. There's zero wasted verbiage.
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 likely triggers a data export (a potentially significant operation), no annotations, 0% schema description coverage, and an output schema (which helps but isn't described), the description is insufficient. It lacks parameter explanations, behavioral context (permissions, side effects), and doesn't leverage the output schema to describe what results to expect. The description feels like internal developer notes rather than agent guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It doesn't mention either parameter ('export_id' or 'tenant_id') or explain their purpose. The description focuses on the fixed payload sent, not the inputs. With 2 parameters (one required) and no schema descriptions, this leaves the agent guessing about what values to provide and why.
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 ('Execute a data export immediately') and specifies the resource ('via the DATA_EXPORT_DEFAULT workflow'). It distinguishes from siblings like 'cdp_create_data_export' (creation) and 'cdp_update_data_export' (modification) by focusing on immediate execution. However, it doesn't explicitly contrast with 'cdp_run_workflow' which might be a more general alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning 'Equivalent to clicking 'Send Now' in the Vega Data Export UI,' suggesting it's for triggering an existing export. It doesn't provide explicit when-not-to-use guidance or name specific alternatives like 'cdp_schedule_data_export' (if it existed) or 'cdp_run_workflow' for non-default workflows. The guidance is helpful but incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the CDP backend may detach the schedule from its workflow if referenceId/entityType/entityId don't match, which is a critical behavioral warning. However, it doesn't cover permissions needed, whether changes are reversible, rate limits, or response format, leaving significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with two sentences that are front-loaded: the first states the core action and endpoint, the second provides critical behavioral guidance. There's no wasted text, though it could be slightly more structured 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 a mutation tool with 3 parameters, 0% schema coverage, no annotations, but an output schema exists, the description is moderately complete. It covers the main action and a key behavioral risk, but lacks details on permissions, error handling, and parameter specifics, relying on the output schema for return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for 3 parameters, the description adds some value: it explains that 'body' is a JSON string of the full schedule body and references cdp_create_schedule for the canonical shape. However, it doesn't clarify 'schedule_id' or 'tenant_id' semantics, nor does it detail the JSON structure or constraints, leaving parameters largely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates an existing schedule row with specific HTTP method (PUT) and endpoint details. It distinguishes from cdp_create_schedule by referencing it for the canonical shape, but doesn't explicitly differentiate from other update tools like cdp_update_audience_def or cdp_update_campaign 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 when updating an existing schedule and references cdp_create_schedule for the body structure, but doesn't explicitly state when to use this vs. alternatives like cdp_deactivate_schedule or cdp_delete_schedule, nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the cache key generation behavior, which is useful context. However, it doesn't disclose critical behavioral traits: whether this is a read-only operation (implied by 'Get' but not explicit), error handling (e.g., if ID not found), performance characteristics, or authentication needs. For a cache retrieval tool with zero annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with two concise sentences. The first states the core purpose, and the second adds important behavioral context about key generation. Every sentence earns its place with zero 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 3 parameters with 0% schema coverage, no annotations, but an output schema exists, the description is minimally adequate. It covers the basic purpose and key generation behavior, but lacks parameter explanations, error handling, and other context needed for reliable use. The output schema reduces the need to describe return values, but other gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'ID' and 'query parameters' (the latter not in schema), but doesn't explain the three actual parameters (cache_type, id, tenant_id). The description adds minimal value beyond the schema's property names, failing to clarify what cache_type represents, what format id should be, or when tenant_id is needed.
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 a cached value by ID' (verb+resource). It distinguishes from siblings like 'cdp_cache_get_by_key' and 'cdp_cache_get_by_group' by specifying the lookup method (ID-based). However, it doesn't explicitly contrast with these alternatives in the description text itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through 'The cache key is auto-generated using the ID and any query parameters,' suggesting this is for retrieving cached data when you have an ID. However, it provides no explicit guidance on when to use this vs. other cache retrieval methods (by_key, by_group) or when not to use it (e.g., for uncached data).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the action ('Copy a dashboard') but lacks details on permissions needed, whether it's a safe operation, rate limits, or what the duplicate entails (e.g., if it copies settings or data). This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences that directly state the purpose without any fluff. It is front-loaded and every word earns its place, making it efficient for quick 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 tool has an output schema (which handles return values) but no annotations and low schema coverage, the description is minimal. It covers the basic action but lacks behavioral context and parameter semantics, making it adequate but with clear gaps for a 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 description coverage is 0%, so the description must compensate. It implies 'dashboard_id' is used to identify the source dashboard but does not explain 'tenant_id' or provide any parameter details beyond the basic action. The description adds minimal value over the schema, resulting in a 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 the verb ('Copy') and resource ('dashboard by ID'), specifying it creates a duplicate. However, it does not differentiate from sibling tools like 'cdp_clone_resource' or 'cdp_copy_widget', which might have overlapping purposes, leaving some ambiguity in sibling context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'cdp_clone_resource' or 'cdp_copy_widget', nor any prerequisites or exclusions. The description only states what it does, without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool creates a duplicate, implying a write operation, but does not address permissions, whether the copy inherits settings, rate limits, or what the output looks like. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two short sentences that directly state the purpose and outcome, with no wasted words. It is front-loaded and efficiently communicates the core functionality without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which reduces the need to describe return values) but no annotations and low schema coverage, the description is incomplete. It covers the basic purpose but lacks usage guidelines, behavioral details, and parameter explanations, making it adequate only for simple contexts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only mentions 'widget_id' implicitly ('Copy a widget by ID') and does not explain 'tenant_id' or their formats. Since there are 2 parameters, the description adds minimal value beyond the schema, resulting in a baseline score of 3 due to the lack of detailed parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Copy a widget by ID') and the outcome ('Creates a duplicate of the widget'), providing a specific verb and resource. It distinguishes from siblings like 'cdp_create_widget' (new widget) and 'cdp_update_widget' (modify existing), but does not explicitly differentiate from 'cdp_clone_resource' or other copy tools, which slightly limits its 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 provides no guidance on when to use this tool versus alternatives, such as 'cdp_create_widget' for new widgets or 'cdp_clone_resource' for broader cloning. It also lacks prerequisites, like needing an existing widget ID, which is implied but not stated explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but lacks critical behavioral details. It hints at mutation ('Create') but doesn't specify permissions, side effects, or error handling. The note about automatic array wrapping adds some context but is insufficient for a creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose. The second sentence provides essential parameter details without redundancy, though the Vega UI reference is slightly extraneous.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters with 0% schema coverage and no annotations, the description partially fills gaps by explaining body and folder_id semantics. However, as a creation tool with an output schema, it should ideally mention the expected response or success indicators.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates by explaining 'body' must be a JSON string with 'name' and 'exportDefItems', and 'folder_id' placement. It clarifies the controller's array wrapping behavior, adding meaningful context beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a new data export definition') and resource ('data export'), making the purpose evident. It distinguishes from siblings like 'cdp_copy_data_export' and 'cdp_update_data_export' by focusing on creation, though it doesn't explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'cdp_copy_data_export' or 'cdp_update_data_export'. The description mentions folder placement but doesn't explain prerequisites, dependencies, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool deletes a data export definition, implying a destructive operation, but fails to mention critical details like whether deletion is permanent, requires specific permissions, has side effects (e.g., affecting scheduled exports), or returns confirmation data. This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words, making it highly efficient and front-loaded. Every word contributes to the core purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a deletion tool with 2 parameters, 0% schema coverage, no annotations, and an output schema (which reduces the need to describe returns), the description is minimally adequate. It states what the tool does but lacks details on behavior, parameters, and usage context, leaving the agent to infer or rely on other sources.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'by ID', which aligns with the 'export_id' parameter, but doesn't explain the optional 'tenant_id' parameter or provide context beyond what the schema's titles imply. With 0% schema description coverage, the description adds minimal value, as it doesn't clarify parameter formats, constraints, or usage examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and the resource ('a data export definition by ID'), making the purpose immediately understandable. It distinguishes from siblings like 'cdp_copy_data_export' or 'cdp_update_data_export' by specifying deletion, though it doesn't explicitly contrast with them in the text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 'cdp_delete_data_erasure_request' or other deletion tools in the sibling list. The description lacks context about prerequisites, such as needing an existing export ID, or when deletion is appropriate versus deactivation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the 'soft-delete' behavior (implying reversible deletion rather than permanent removal), which is valuable context beyond just 'delete'. However, it lacks details on permissions needed, side effects, rate limits, or what the soft-delete entails operationally.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the key action ('soft-delete a mailer account') without unnecessary words. The HTTP method inclusion is concise and adds technical context without 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 deletion tool with no annotations, 0% schema coverage, but an output schema (which handles return values), the description is minimally adequate. It covers the core action and hints at reversibility ('soft-delete'), but lacks parameter explanations, usage context, and full behavioral details needed for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description mentions no parameters at all, failing to compensate for the coverage gap. It doesn't explain what 'id' or 'tenant_id' represent or their significance for the operation.
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 ('soft-delete') and resource ('a mailer account'), making the purpose specific and understandable. However, it doesn't explicitly distinguish this tool from other delete operations in the sibling list (like cdp_delete_mailer_subuser or general delete tools), which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, prerequisites, or exclusions. Given the sibling tools include cdp_restore_mailer_account, there's an implied alternative for undoing deletions, but this isn't stated in the description itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Delete' implies a destructive mutation, the description doesn't specify whether this action is reversible, requires specific permissions, has side effects (e.g., cascading deletions), or includes confirmation steps. For a destructive tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and wastes no space, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a destructive mutation tool with no annotations, 0% schema description coverage, but an output schema exists, the description is minimally adequate. It states what the tool does but lacks critical context like behavioral traits, parameter details, and usage guidelines. The presence of an output schema means return values are documented elsewhere, but the description doesn't compensate for other 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 mentions 'by ID', which aligns with the required 'message_def_id' parameter, but doesn't explain the optional 'tenant_id' parameter or provide any additional context beyond what the schema shows (e.g., format of IDs, default behavior for tenant_id). With 0% schema description coverage, the description adds minimal value over the bare schema, meeting the baseline for adequate but incomplete parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and resource ('a message definition by ID'), making the purpose specific and understandable. However, it doesn't distinguish this tool from other delete operations in the sibling list (e.g., cdp_delete_audience_def, cdp_delete_campaign), which all follow the same 'Delete [resource] by ID' pattern.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., needing the message definition ID), what happens after deletion, or if there are any restrictions (e.g., cannot delete if in use). Without such context, an agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool generates a SQL query but does not describe any behavioral traits such as whether it's read-only, if it has side effects, rate limits, or authentication needs. For a tool with no annotation coverage, this is inadequate, as it leaves the agent uncertain about operational risks.
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 and front-loaded, consisting of only two sentences that directly state the tool's function and parameter usage. There is no wasted verbiage, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no annotations, but with an output schema), the description is minimally adequate. It explains the core function but lacks details on behavioral traits, parameter specifics beyond 'body,' and usage context. The presence of an output schema mitigates the need to describe return values, but overall completeness is limited.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 some meaning by specifying that the 'body' parameter should be a 'dataset definition as a JSON string,' which clarifies its purpose beyond the schema's generic 'Body' title. However, with 0% schema description coverage and two parameters (body and tenant_id), it does not fully compensate for the lack of schema details, especially for 'tenant_id,' which remains undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Generate a SQL query from a dataset definition.' It specifies the verb ('Generate'), resource ('SQL query'), and source ('dataset definition'). However, it does not explicitly differentiate from sibling tools like 'cdp_query_sql' or 'cdp_query_sql_post', which might be for executing queries rather than generating them, leaving some 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?
The description provides no guidance on when to use this tool versus alternatives. It mentions passing the dataset definition as a JSON string but does not specify prerequisites, context, or exclusions. Given the presence of sibling tools like 'cdp_query_sql', the lack of comparative 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Get' implies a read operation, the description doesn't specify whether this requires authentication, has rate limits, returns structured data, or handles errors. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core purpose ('Get a specific audience definition'), making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (simple retrieval), 2 parameters, 0% schema coverage, no annotations, but an output schema exists, the description is minimally adequate. The output schema likely details return values, reducing the need for that in the description, but more guidance on usage and parameters 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 0%, so the description must compensate. It mentions 'by ID', which clarifies the purpose of 'audience_def_id', but doesn't explain 'tenant_id' (e.g., optional tenant context) or provide format details. The description adds some value but doesn't fully cover the two parameters, resulting in a 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 the action ('Get') and resource ('a specific audience definition by ID'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'cdp_list_audience_defs' (which likely lists multiple) or 'cdp_get_audience_count' (which might return counts rather than definitions), so it doesn't achieve full 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. It doesn't mention prerequisites (e.g., needing an existing audience definition ID), exclusions, or comparisons to similar tools like 'cdp_list_audience_defs' for browsing or 'cdp_get_audience_count' for metrics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Get' implies a read operation, but doesn't mention whether this requires specific permissions, what happens if the campaign ID doesn't exist, rate limits, or the response format. For a read tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose with no wasted words. It's appropriately sized for a simple retrieval tool and front-loaded with the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (a simple read operation), the presence of an output schema (which handles return values), and the lack of annotations, the description is minimally adequate. However, it fails to address key contextual aspects like error handling, authentication needs, or differentiation from sibling tools, leaving 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 description mentions 'by ID', which aligns with the 'campaign_id' parameter in the schema. However, schema description coverage is 0%, and the description doesn't explain the optional 'tenant_id' parameter or provide any additional context about parameter formats, constraints, or usage beyond what's implied. It adds minimal value over the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('campaign definition by ID'), making the purpose specific and understandable. However, it doesn't differentiate from sibling tools like 'cdp_list_campaigns' or 'cdp_get_campaign_run', which provide related but distinct 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites like authentication, compare it to sibling tools (e.g., 'cdp_list_campaigns' for listing all campaigns), or specify when it's appropriate to fetch a single campaign by ID versus other methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a read operation ('Get'), but provides no information about authentication requirements, rate limits, error conditions, or what the output contains. For a tool that retrieves sensitive OAuth client data, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core purpose without any wasted words. It's appropriately sized for a simple retrieval tool and front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values), 2 parameters with 0% schema coverage, and no annotations, the description is minimally adequate but incomplete. It covers the basic purpose but lacks parameter explanations and behavioral context that would help an agent use it correctly, especially for the optional 'tenant_id' 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?
Schema description coverage is 0%, so the schema provides no parameter documentation. The description mentions 'by numeric ID' which corresponds to the 'client_id' parameter, but doesn't explain the optional 'tenant_id' parameter or provide any context about parameter formats, constraints, or relationships. The description adds minimal value beyond what's implied by the parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('a specific OAuth client by numeric ID'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'cdp_list_clients' or 'cdp_get_user', but the specificity of 'by numeric ID' provides some implicit distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like 'cdp_list_clients' (for listing all clients) or other 'cdp_get_*' tools. The description only states what it does, not when it should be selected over other available options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool returns 'the full definition including the model (Saiku query JSON)', which adds useful context about the output content. However, it lacks critical behavioral details such as whether this is a read-only operation, error handling for invalid IDs, authentication requirements, or rate limits. For a retrieval tool with zero annotation coverage, this leaves significant gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, consisting of two sentences that directly state the purpose and output. Every word earns its place, with no redundant or vague language. It efficiently communicates the core functionality without unnecessary elaboration, making it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, retrieval operation), the description is minimally adequate. It benefits from having an output schema (which reduces the need to detail return values) but suffers from no annotations and low parameter schema coverage. The description covers the basic purpose and output content but lacks guidance, behavioral context, and full parameter semantics, making it incomplete for optimal agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'by ID', which aligns with the 'cubic_set_def_id' parameter, adding semantic meaning beyond the schema's 0% description coverage. However, it doesn't explain the optional 'tenant_id' parameter or provide details on ID format, constraints, or examples. With low schema coverage (0%), the description partially compensates but falls short of fully clarifying both parameters, warranting a 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 the action ('Get') and resource ('CubicSetDef by ID'), making the purpose specific and understandable. It distinguishes from siblings like 'cdp_list_cubic_set_defs' (which lists multiple) by focusing on retrieval of a single item by ID. However, it doesn't explicitly contrast with other 'get' tools (e.g., 'cdp_get_cube_status'), leaving some ambiguity in 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. It doesn't mention prerequisites (e.g., needing a valid ID), exclusions, or comparisons to similar tools like 'cdp_list_cubic_set_defs' for browsing or 'cdp_copy_cubic_set_def' for duplication. Usage is implied only by the action 'Get', with no explicit context or constraints provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states this is a read operation ('Get'), which implies it's non-destructive, but doesn't disclose any behavioral traits like authentication requirements, rate limits, error handling, or what happens if the rule ID doesn't exist. For a tool with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized for a simple retrieval tool and front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there's an output schema (which handles return values), no annotations, and simple parameters, the description is minimally adequate. However, for a tool with zero schema description coverage and no annotations, it should provide more context about parameter usage and behavioral expectations to be truly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for both parameters, the description doesn't add any meaning beyond what the schema provides. It mentions 'by ID' which relates to the 'rule_id' parameter, but doesn't explain what format the ID should be, where to find it, or what the optional 'tenant_id' parameter does. The description fails to compensate for the complete lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('a specific DQE Phase 1 rule'), making the purpose unambiguous. It distinguishes from the sibling 'cdp_list_dqe1_rules' by specifying retrieval of a single rule by ID rather than listing multiple rules. However, it doesn't fully explain what a 'DQE Phase 1 rule' 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 implies usage when you need to retrieve a specific rule by its ID, which differentiates it from the list operation. However, it doesn't provide explicit guidance on when to use this versus alternatives like 'cdp_get_dqe2_rule' or other rule-related tools, nor does it mention prerequisites or error conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states it's a 'Get' operation, implying read-only behavior, but doesn't disclose authentication requirements, rate limits, error conditions, or what the output contains. For a tool with no annotation coverage, this is insufficient behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded with the essential information, making it efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values) but no annotations and 0% schema description coverage, the description is minimally adequate. It identifies the core operation but lacks context about DQE Phase 2 rules, authentication, or error handling that would help an agent use it effectively in real 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 0%, so the schema provides no parameter documentation. The description mentions 'by ID' which implies the 'rule_id' parameter, but doesn't explain the optional 'tenant_id' parameter or provide any format/validation details. It adds minimal value beyond what's inferable from parameter names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and target resource ('a specific DQE Phase 2 rule by ID'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'cdp_get_dqe1_rule' or 'cdp_list_dqe2_rules', which would require mentioning the specific rule type or contrasting with list operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, when it's appropriate compared to list operations, or any context about DQE Phase 2 rules that would help an agent decide. This leaves the agent without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a 'Get' operation, implying read-only behavior, but doesn't specify authentication requirements, rate limits, error conditions, or what happens if the instance doesn't exist. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. There's no wasted verbiage or unnecessary elaboration, making it immediately clear what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there's an output schema (which handles return values), no annotations, and low parameter complexity, the description is minimally adequate. However, for a tool that presumably retrieves important infrastructure objects, it should provide more context about what a 'provisioned instance' represents and the significance of the optional tenant_id 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 description mentions retrieving by 'ID', which aligns with the 'instance_id' parameter. However, with 0% schema description coverage and two parameters (instance_id and tenant_id), the description doesn't explain what a 'provisioned instance' is, what format the ID should be, or when/why to use the optional tenant_id parameter. The baseline is 3 since the description adds minimal value beyond what's implied by the parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('a specific provisioned instance by ID'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'cdp_list_provision_instances' or 'cdp_get_mapped_provision_instance', but the specificity of 'by ID' provides some implicit distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, when-not-to-use scenarios, or how this differs from related tools like 'cdp_list_provision_instances' (for listing) or 'cdp_get_mapped_provision_instance' (for mapped instances).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that the tool 'Get[s] the latest execution status,' implying a read-only operation, but does not disclose other behavioral traits such as authentication needs, rate limits, error handling, or what 'latest' means in terms of data freshness. For a tool with no annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, consisting of two concise sentences that directly state the purpose and key parameters. Every sentence earns its place by providing essential information without redundancy or unnecessary details, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 parameters, no annotations, but has an output schema), the description is partially complete. It covers the basic purpose and some parameters but lacks behavioral context and full parameter semantics. The presence of an output schema means the description need not explain return values, but it should still address usage guidelines and transparency gaps for a tool with no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate for undocumented parameters. It mentions 'defId and defType' and 'step details,' which partially maps to parameters (def_id, def_type, steps), but does not explain the meaning or usage of 'tenant_id' or provide context for 'defType' default values or 'steps' boolean. With 4 parameters and low coverage, the description adds limited value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get the latest execution status for a campaign definition.' It specifies the verb ('Get') and resource ('execution status for a campaign definition'), making it easy to understand. However, it does not explicitly differentiate from sibling tools like 'cdp_get_campaign_run' or 'cdp_get_dispatch', which might have overlapping functions, so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some implied usage guidance by stating 'Requires defId and defType. Optionally include step details,' which indicates prerequisites and optional parameters. However, it does not explicitly say when to use this tool versus alternatives (e.g., compared to 'cdp_get_campaign_run' or 'cdp_get_dispatch'), and it lacks exclusions or clear context for selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It states a read operation ('Get'), implying it's likely non-destructive, but doesn't confirm safety aspects like read-only nature, authentication requirements, error handling, or rate limits. For a tool with zero annotation coverage, this lack of behavioral context is a significant gap, though 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. It avoids redundancy and gets straight to the point, making it easy to parse. Every word earns its place, adhering to best practices for brevity in tool descriptions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (simple retrieval), two parameters with 0% schema coverage, no annotations, and an output schema present, the description is minimally adequate. The output schema likely defines return values, reducing the need for description detail. However, the lack of behavioral context and incomplete parameter guidance means it doesn't fully compensate for missing annotations, keeping it at a baseline level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description mentions 'by ID', which aligns with the 'user_id' parameter, adding some semantic value. However, it doesn't explain the optional 'tenant_id' parameter or provide details like ID format, validation, or default behaviors. With two parameters and low schema coverage, the description partially compensates but leaves key gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('a specific self-service user by ID'), making the purpose unambiguous. It distinguishes from sibling tools like 'cdp_list_selfservice_users' by specifying retrieval of a single user rather than a list. However, it doesn't explicitly contrast with 'cdp_get_user' or 'cdp_get_user_lite', which might also fetch user data, leaving slight ambiguity in 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. It doesn't mention prerequisites (e.g., authentication), when-not-to-use scenarios, or compare with similar tools like 'cdp_get_user' or 'cdp_list_selfservice_users'. The agent must infer usage solely from the name and parameters, which is insufficient for informed tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states this is a read operation ('Get'), which implies it's non-destructive, but doesn't disclose behavioral traits like authentication requirements, rate limits, error handling, or what happens if the user ID doesn't exist. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose with zero wasted words. It's appropriately sized for a simple retrieval tool and front-loads the key 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 low complexity (a simple get-by-ID operation), no annotations, 0% schema coverage, but with an output schema present, the description is minimally adequate. It covers the basic purpose but lacks details on parameters, behavioral context, and usage guidelines. The output schema mitigates the need to describe return values, but other gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description mentions 'by ID', which clarifies that 'user_id' is the primary identifier, but doesn't explain the optional 'tenant_id' parameter or provide context like ID formats or constraints. It adds minimal value beyond the parameter names 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 ('Get') and resource ('a specific CDP user by ID'), making the purpose unambiguous. It distinguishes from sibling tools like 'cdp_list_users' or 'cdp_get_user_lite' by specifying retrieval of a single user via ID. However, it doesn't explicitly contrast with these siblings in the description text 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 alternatives like 'cdp_list_users' (for multiple users) or 'cdp_get_user_lite' (for a lighter version). It also lacks information about prerequisites, such as authentication or tenant context. Usage is implied only through the parameter names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Get' (read operation) but doesn't disclose behavioral traits like authentication needs, rate limits, error conditions, or what 'lightweight format' entails (e.g., limited fields). This leaves significant gaps for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. Every word earns its place, with no redundant or vague phrasing.
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 annotations, 0% schema coverage, but an output schema exists, the description is minimally adequate. It covers the basic purpose but lacks behavioral context and parameter semantics. The output schema mitigates the need to explain return values, but overall completeness is limited for a tool with two parameters and no 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 description coverage is 0%, so the description must compensate. It mentions 'by ID', which aligns with the required 'user_id' parameter, but doesn't explain 'tenant_id' (optional, nullable) or provide any format/constraint details. The description adds minimal value beyond the schema's parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('a specific user'), specifying it's in 'lightweight format by ID'. It distinguishes from the sibling 'cdp_get_user' by indicating a lighter version, though it doesn't explicitly contrast with 'cdp_list_users_lite' for bulk retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'cdp_get_user' (full format) or 'cdp_list_users_lite' (bulk lightweight). The description implies single-user retrieval but lacks explicit usage context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that it 'Get details,' which implies a read-only operation, but doesn't disclose any behavioral traits such as authentication requirements, rate limits, error handling, or what 'details' include. For a tool with no annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, consisting of only two sentences that directly state the purpose and parameter requirements. There is no wasted text, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a read operation with 3 parameters) and the presence of an output schema (which likely defines return values), the description is minimally adequate. However, with no annotations and 0% schema coverage, it lacks details on authentication, error cases, and parameter semantics, leaving gaps for an AI agent to infer behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning parameters are undocumented in the schema. The description mentions 'workflow_id and job_id' as required, adding some semantic value, but it doesn't explain the optional 'tenant_id' parameter or provide any context on parameter formats, constraints, or examples. With three parameters and low coverage, the description doesn't adequately compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get details of a specific workflow job execution.' It uses a specific verb ('Get') and resource ('workflow job execution'), making it easy to understand. However, it doesn't explicitly differentiate from sibling tools like 'cdp_get_workflow' or 'cdp_get_workflow_step', which are similar retrieval 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 provides some usage context by stating 'Requires the workflow_id and job_id,' which implies these are mandatory parameters. However, it doesn't offer guidance on when to use this tool versus alternatives (e.g., 'cdp_get_workflow' for workflow details or 'cdp_list_workflows' for listing workflows), nor does it mention prerequisites like authentication or tenant context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses one key behavioral trait: 'Returns paged results,' which informs the agent about pagination handling. However, it doesn't mention authentication requirements, rate limits, error conditions, or what the paged response structure looks like (though output schema exists). For a list operation with zero annotation coverage, this is minimal but not entirely absent.
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 short sentences that are front-loaded with the core purpose. Every word earns its place—no fluff or redundancy. It efficiently communicates the essential information in minimal 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 tool's moderate complexity (list operation with pagination), no annotations, and an output schema (which handles return values), the description is partially complete. It covers the basic action and pagination but lacks parameter explanations, error handling, and context about audience definitions. With output schema present, it doesn't need to detail return values, but other gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so parameters are undocumented in the schema. The description mentions 'for a tenant' which loosely relates to 'tenant_id', but doesn't explain the three parameters (tenant_id, offset, limit) or their semantics. It doesn't clarify if tenant_id is required, what offset/limit control, or default behaviors. The description adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and resource ('audience definitions for a tenant'), making the purpose immediately understandable. It distinguishes from sibling tools like 'cdp_get_audience_def' (singular retrieval) and 'cdp_lookup_audience_defs' (lookup operation). However, it doesn't specify what 'audience definitions' are in this context, leaving some domain-specific 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?
The description provides no guidance on when to use this tool versus alternatives. With many sibling list tools (e.g., 'cdp_list_campaigns', 'cdp_list_users'), there's no indication of prerequisites, typical use cases, or differences from other listing operations. The mention of 'paged results' is a behavioral detail, not usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'Returns paged results', which adds useful context about pagination behavior. However, it doesn't disclose other critical traits such as whether this is a read-only operation (implied by 'List' but not explicit), potential rate limits, authentication needs, or error handling. For a tool with zero annotation coverage, this leaves significant gaps in behavioral understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and front-loaded, consisting of three sentences that efficiently convey purpose, requirements, and output behavior. Every sentence earns its place: the first states the action, the second specifies required inputs, and the third notes pagination. There is no wasted verbiage, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (5 parameters, 1 required), zero schema description coverage, no annotations, but with an output schema (which handles return values), the description is partially complete. It covers the core purpose and some parameters but lacks details on behavioral traits and full parameter semantics. The output schema reduces the need to explain return values, but the description should do more to compensate for missing annotations and low schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It mentions 'defId and defType (e.g. DATASET_DEF)', providing meaning for two of the five parameters (def_id and def_type). However, it doesn't explain tenant_id, offset, or limit, leaving three parameters without semantic context. This partial coverage fails to adequately compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List execution history (dataset descriptions) for a campaign definition.' It specifies the verb ('List'), resource ('execution history'), and scope ('for a campaign definition'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'cdp_list_campaigns' or 'cdp_get_campaign_run', which list campaigns or get a specific run respectively, so it misses full 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage by stating 'Requires defId and defType (e.g. DATASET_DEF)', indicating prerequisites for use. It doesn't offer explicit guidance on when to use this tool versus alternatives (e.g., 'cdp_list_campaigns' for listing campaigns or 'cdp_get_campaign_run' for a specific run), nor does it specify exclusions or when-not-to-use scenarios, leaving usage context partially covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states it's a list operation. It doesn't disclose behavioral traits like whether it requires authentication, returns paginated results, has rate limits, or what 'available' means (e.g., active vs. all clusters). This leaves significant gaps for a tool that likely interacts with infrastructure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with zero wasted words. It's front-loaded with the core action and resource, making it highly efficient and easy to parse at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (list operation), no annotations, and an output schema exists (which handles return values), the description is minimally adequate. However, it lacks context about the compute clusters domain (e.g., what 'available' implies) and doesn't address the undocumented parameter, leaving 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 description mentions no parameters, while the schema has one optional parameter (tenant_id) with 0% coverage. The description doesn't compensate by explaining what tenant_id does or when to use it. However, with 0 parameters mentioned, the baseline is 4, but since there is one undocumented parameter, it drops to 3 as the description fails to address 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 'List available compute clusters' clearly states the verb ('List') and resource ('available compute clusters'), making the purpose immediately understandable. It distinguishes from sibling tools that list other resources (like campaigns, users, dashboards), though it doesn't explicitly contrast with similar list 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context, or differentiate from other list operations (like cdp_list_tenant_clusters or cdp_list_provision_instances). The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool lists compaction requests, implying a read-only operation, but doesn't clarify if it's safe, whether it requires authentication, what happens if tenant_id is null, or if there are rate limits. For a tool with zero annotation coverage, this minimal description lacks critical behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core purpose and appropriately sized for a simple list operation. Every word earns its place, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one optional parameter) and the presence of an output schema (which handles return values), the description is somewhat complete but lacks depth. It covers the basic purpose but misses usage guidelines, behavioral details, and parameter semantics beyond a vague reference. For a read operation with output schema support, it's minimally viable but could better address the parameter's role and tool 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 description mentions 'for a tenant', which aligns with the 'tenant_id' parameter in the schema. However, schema description coverage is 0%, so the schema provides no parameter details. The description adds some meaning by indicating the parameter's purpose but doesn't explain the parameter's format, optionality (default null), or what happens if omitted. With one parameter and low schema coverage, this is a baseline adequate but incomplete explanation.
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 'List compaction requests for a tenant' clearly states the action (list) and resource (compaction requests), with a scope qualifier (for a tenant). It distinguishes from sibling tools like 'cdp_create_compaction_request' and 'cdp_unschedule_compaction_request' by focusing on listing rather than creating or unscheduling. However, it doesn't specify if it lists all requests or filtered ones, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, such as needing a valid tenant ID, or compare it to other list tools like 'cdp_list_tenants' or 'cdp_list_compaction_requests' (if there were multiple variants). There's no explicit when/when-not usage context, leaving the agent to infer based on the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only partially discloses behavior. It mentions server-side filtering via 'q' and references a GET endpoint, implying a read-only operation, but doesn't cover pagination behavior (offset/limit), authentication needs, rate limits, error conditions, or response format. For a list tool with zero annotation coverage, this leaves significant gaps in understanding its operational traits.
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 efficiently structured in two sentences: the first states the core purpose, and the second adds key usage detail for filtering. Every sentence earns its place with no redundant or vague language, making it appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (list operation with 4 parameters), no annotations, and an output schema (which reduces need to describe return values), the description is partially complete. It covers the basic purpose and filtering but misses parameter semantics for most inputs and behavioral details like pagination or auth. It's adequate for a simple list tool but lacks depth for full agent guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but only adds meaning for 'q' (server-side filtering with examples like 'isPublished:true'). It ignores tenant_id, offset, and limit parameters entirely, leaving their purpose and usage undocumented. With 4 parameters and low coverage, the description provides insufficient semantic context 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 ('List prediction definitions') and resource ('for a tenant'), which distinguishes it from siblings like cdp_get_prediction (singular retrieval) or cdp_create_prediction (creation). However, it doesn't explicitly differentiate from other list tools like cdp_list_campaigns or cdp_list_audience_defs beyond 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving prediction definitions with optional filtering via the 'q' parameter, but provides no explicit guidance on when to use this tool versus alternatives like cdp_get_prediction (for single definitions) or other list tools. It mentions server-side filtering as a feature but doesn't state prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states it's a list operation (implying read-only), but doesn't mention permissions needed, pagination behavior, rate limits, or what 'available' means (e.g., active vs. all packages). This leaves significant gaps for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point with no wasted words. It's appropriately sized for a simple list tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 optional parameter) and presence of an output schema (which handles return values), the description is minimally adequate. However, with no annotations and incomplete parameter guidance, it doesn't fully equip an agent for reliable use, keeping it at the baseline of adequacy.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'for a tenant' which aligns with the 'tenant_id' parameter, adding some context beyond the schema's 0% description coverage. However, with only 1 parameter and low schema coverage, the description doesn't fully explain the parameter's role (e.g., whether it's required, what happens if null, format expectations). Baseline 3 is appropriate as it adds minimal but not comprehensive semantic 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 the action ('List') and resource ('available provisioning packages for a tenant'), making the purpose specific and understandable. However, it doesn't distinguish this tool from other list tools in the sibling set (e.g., cdp_list_provision_instances, cdp_list_provision_services), which would require a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, prerequisites, or context for its application. It's a bare statement of purpose without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states it's a 'fetch' operation (implying read-only), but doesn't disclose behavioral traits like authentication requirements, rate limits, pagination, error handling, or whether it's idempotent. For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that efficiently conveys the core purpose without unnecessary words. It's front-loaded with the key action and resource, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which should detail return values), the description's job is lighter. However, with no annotations and 0% schema description coverage, it lacks context on authentication, error handling, and usage scenarios. For a simple read operation with output schema, it's minimally adequate but could benefit from 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?
The description mentions 'tenant' which aligns with the 'tenant_id' parameter in the schema, adding some context. However, schema description coverage is 0%, and the description doesn't explain parameter semantics beyond the name (e.g., what happens if tenant_id is null, format expectations, or default behavior). With one parameter and no schema descriptions, it provides minimal but not comprehensive semantic 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 the action ('Fetch') and resource ('provisioning limits for all services of a tenant'), making the purpose specific and understandable. However, it doesn't explicitly distinguish this tool from sibling tools like 'cdp_get_provision_limit' (singular) or 'cdp_list_provision_services', which might list services rather than their limits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., authentication), when it's appropriate (e.g., for capacity planning), or contrast it with similar tools like 'cdp_get_provision_limit' (which might fetch limits for a specific service).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It implies a read operation ('List') but doesn't disclose behavioral traits like pagination, rate limits, authentication requirements, or what 'available' means (e.g., filtered by permissions). The description is minimal and lacks essential context for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core purpose and appropriately sized for a simple list operation, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 optional parameter) and the presence of an output schema, the description is minimally adequate. However, with no annotations and 0% schema coverage, it lacks context on behavioral aspects like safety or constraints, making it incomplete for optimal agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'for a tenant', which aligns with the 'tenant_id' parameter in the schema. However, schema description coverage is 0%, and the description doesn't add details like parameter format, optionality, or default behavior. It provides basic semantics but doesn't compensate for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and resource ('available self-service roles for a tenant'), providing a specific verb+resource combination. It distinguishes from siblings like 'cdp_list_roles' by specifying 'self-service' roles, though it doesn't explicitly contrast them in the description text 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 alternatives like 'cdp_list_roles' or other list tools. It mentions 'for a tenant' but doesn't explain prerequisites, context, or exclusions, leaving the agent without 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?
No annotations are provided, so the description carries the full burden. It implies a read operation ('List') but doesn't disclose behavioral traits like pagination, rate limits, authentication requirements, or what 'all' entails (e.g., active only). For a list tool with zero annotation coverage, this leaves significant gaps in understanding how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action and resource. There is no wasted verbiage, making it highly concise and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (list operation, 1 optional parameter) and the presence of an output schema (which handles return values), the description is minimally adequate. However, with no annotations and 0% schema description coverage, it lacks details on behavior, usage context, and parameter nuances, leaving room for improvement in 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 description mentions 'for a tenant', which aligns with the 'tenant_id' parameter in the schema. However, schema description coverage is 0%, and the description doesn't add details like parameter format, optionality (it's optional with default null), or semantics beyond the basic tenant scope. With one parameter and low schema coverage, it provides minimal but not substantial additional meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('all self-service users for a tenant'), making the purpose specific and understandable. It distinguishes from siblings like 'cdp_list_users' by specifying 'self-service' users, though it doesn't explicitly contrast them in the description text 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 alternatives like 'cdp_list_users' or 'cdp_get_selfservice_user'. It mentions a tenant scope but doesn't explain prerequisites, exclusions, or contextual triggers for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It implies a read-only operation ('List') but does not specify aspects like authentication needs, rate limits, pagination, or error handling. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that directly states the tool's function without unnecessary words. It is front-loaded and efficient, making it easy to grasp quickly with zero 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 tool's low complexity (one parameter, read-only implied), the presence of an output schema (which handles return values), and no annotations, the description is minimally adequate. However, it lacks details on behavioral traits and usage context, making it incomplete for optimal agent understanding despite the 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?
The input schema has one parameter with 0% description coverage, and the tool description does not mention parameters at all. Since there is only one parameter and the schema provides basic structure (title 'Tenant Id'), the baseline score of 3 is appropriate, as the description adds no value beyond the schema but the schema itself is minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and resource ('clusters assigned to the current tenant'), making the purpose specific and understandable. However, it does not explicitly differentiate from sibling tools like 'cdp_list_clusters' or 'cdp_list_tenant_clusters' (if they exist in context), which slightly limits its 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, such as other list tools in the sibling set (e.g., 'cdp_list_clusters'). It lacks context on prerequisites, exclusions, or specific scenarios, offering only a basic statement of function without 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?
No annotations are provided, so the description carries the full burden. It mentions 'pagination' and 'optional search filter', which are behavioral traits, but lacks critical details: required permissions, rate limits, whether it's a read-only operation, default pagination behavior, or response format. For a list tool with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('List all CDP users for a tenant') and adds key features ('with pagination; optional search filter'). There is no wasted text, and it's appropriately sized for a list tool, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 parameters, no annotations, but has an output schema), the description is minimally adequate. It covers the basic purpose and hints at parameters, but lacks behavioral context and usage guidelines. The output schema existence means return values are documented elsewhere, reducing the burden, but the description should still address permissions or constraints for a complete picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter details. The description adds some semantics by mentioning 'tenant' (implied by tenant_id), 'pagination' (implied by offset/limit), and 'optional search filter' (mapped to search). However, it doesn't explain parameter formats, defaults, or constraints (e.g., search syntax, limit ranges). This partially compensates but doesn't fully cover the 4 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('CDP users for a tenant'), specifying the action and target. It distinguishes from siblings like 'cdp_get_user' (single user) and 'cdp_list_users_lite' (lite version) by implying a comprehensive list, though it doesn't explicitly name alternatives. The mention of 'pagination' and 'optional search filter' adds useful scope but doesn't fully differentiate from all 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 explicit guidance on when to use this tool versus alternatives is provided. The description mentions 'pagination' and 'optional search filter', which imply usage for browsing or searching users, but it doesn't specify prerequisites (e.g., tenant context), exclusions, or compare to siblings like 'cdp_list_users_lite'. Without such context, the agent must infer usage from the name and parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states this is a list operation but doesn't disclose behavioral traits like whether it's paginated, requires authentication, has rate limits, returns structured data, or what happens with the tenant_id parameter. For a read operation with zero annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose. It's appropriately sized for a simple list operation, with no unnecessary words or redundant information. The parenthetical clarification adds value without bloating the text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter and an output schema (which handles return values), the description is minimally adequate. However, with no annotations and incomplete parameter documentation, it doesn't provide enough context about authentication requirements, pagination, error conditions, or relationship to other workflow tools. The output schema helps but doesn't compensate for missing 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?
Schema description coverage is 0%, but the description doesn't mention the tenant_id parameter at all. With 1 parameter that's undocumented in both schema and description, the description adds no parameter semantics. However, since there's only one parameter and it has a default (null), the baseline is 3 as the agent can likely infer usage from context.
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 'available workflow step types', with additional clarifying context 'node types for workflow DAGs'. It distinguishes from most siblings (which handle different resources like campaigns, connectors, etc.), though it doesn't explicitly differentiate from other 'list' tools like cdp_list_workflow_steps or cdp_list_workflow_edges.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. The description doesn't mention prerequisites, typical use cases, or how it relates to other workflow-related tools like cdp_get_workflow_step or cdp_list_workflows. The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the action is a POST request and requires a JSON string body, but lacks critical behavioral details: it doesn't specify if this is a destructive/mutative operation (likely yes, but unstated), what permissions are needed, whether it's idempotent, rate limits, or what the output contains (though an output schema exists). For a mutation tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first clause, followed by essential usage detail in the second. Both sentences are necessary and zero-waste, efficiently conveying key information 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?
Given complexity (a mutation tool for retrying provisioning), no annotations, and an output schema (which mitigates need to describe returns), the description is minimally adequate. It covers the basic what and how but lacks behavioral context (e.g., side effects, auth needs) and full parameter guidance, leaving gaps for safe and correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds some meaning for 'body' ('Pass same body as initial provisioning as JSON string'), clarifying its purpose and format. However, it doesn't explain 'instance_id' (e.g., what ID this refers to) or 'tenant_id' (optional, but purpose unclear). With 3 parameters and low schema coverage, the description only partially addresses the gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Retry provisioning') and resource ('a failed instance'), distinguishing it from siblings like 'cdp_create_provision_instance' (initial creation) and 'cdp_reactivate_provision_instance' (reactivation). However, it doesn't explicitly differentiate from 'cdp_provision_instance_action' which might handle similar retry scenarios, leaving some 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 context by specifying 'failed instance' and 'Pass same body as initial provisioning', suggesting it's for retrying after a failure. However, it doesn't explicitly state when to use this versus alternatives like 'cdp_reactivate_provision_instance' or 'cdp_update_provision_instance', nor does it mention prerequisites (e.g., instance must be in a failed state).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions that folder_id 'matches UI save behaviour, which always sends ?folderId=...', which adds some context about default behavior. However, it doesn't disclose critical traits like permission requirements, whether updates are partial or complete, error handling, or what the output contains. For a mutation tool with zero annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with only two sentences, both packed with relevant information. The first sentence states the core purpose, while the second provides specific parameter guidance. There is zero wasted verbiage, making it efficiently 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 that this is a mutation tool with 4 parameters (2 required), 0% schema description coverage, no annotations, but an output schema exists, the description is moderately complete. It covers the core action and some parameter semantics, but lacks behavioral context (permissions, side effects) and full parameter documentation. The output schema mitigates the need to describe return values, but overall completeness is adequate with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains that 'body' should contain 'updated fields as a JSON string' and that 'folder_id' moves the campaign into a folder, matching UI behavior. However, it doesn't clarify 'campaign_id' (presumably identifies which campaign to update) or 'tenant_id' (purpose unclear). The description adds value for two parameters but leaves two undocumented, resulting in partial compensation.
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 ('an existing campaign definition'), making the purpose unambiguous. It distinguishes from creation tools (like 'cdp_create_campaign') by specifying 'existing', but doesn't explicitly differentiate from other update tools (like 'cdp_update_audience_def') beyond 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 doesn't mention prerequisites (e.g., needing an existing campaign), compare with sibling update tools, or specify scenarios where this is appropriate versus creating a new campaign or using other campaign-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. 'Update' implies a mutation operation, but it doesn't disclose permissions required, whether changes are reversible, rate limits, or what happens to unspecified fields. The mention of 'JSON string' for the body parameter adds some context, but overall behavioral traits are largely undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single sentence that front-loads the core action ('Update an existing mapping template') and follows with essential parameter guidance. There is zero wasted verbiage; every word serves a purpose, making it efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation with 3 parameters, 0% schema coverage, no annotations, but with an output schema), the description is minimally adequate. The output schema likely covers return values, reducing the need for description there. However, for a mutation tool, it lacks critical context like error conditions, side effects, or authentication needs, leaving gaps despite the 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 0%, so the description must compensate but only partially does. It clarifies that 'body' should be a 'JSON string' containing 'updated fields', which adds meaning beyond the schema's generic 'string' type. However, it doesn't explain 'template_id' (e.g., how to obtain it) or 'tenant_id' (e.g., when it's required), leaving two of three parameters with minimal semantic context.
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 ('an existing mapping template'), making the purpose immediately understandable. It distinguishes from sibling tools like 'cdp_create_mapping_template' (create) and 'cdp_delete_mapping_template' (delete) by focusing on modification. However, it doesn't specify what a 'mapping template' is or what fields can be updated, keeping it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing template ID), when not to use it (e.g., for creation or deletion), or how it relates to sibling tools like 'cdp_get_mapping_template' or 'cdp_list_mapping_templates'. The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states this is a creation tool, implying a write operation, but doesn't disclose behavioral traits like required permissions, whether the operation is idempotent, rate limits, or what happens on duplicate names. The mention of 'advanced configuration' via JSON body adds some context but is insufficient for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with two sentences: the first states the purpose and basic usage, the second adds channel options. It's front-loaded with the core action and parameters, though the channel list could be more structured. There's minimal waste, but it could be slightly more organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, 2 required, mutation tool) and no annotations, the description is moderately complete. It covers the main parameters and usage modes, and an output schema exists, so return values needn't be explained. However, for a creation tool with zero annotation coverage, it should include more behavioral context like permissions or error handling to be fully 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 coverage is 0%, so the description must compensate. It adds meaning by explaining that name and connector_type are required for simple creation, and that a JSON body can be used for advanced configuration. It also lists channel options (email, export, sms, ads, facebook, any), which clarifies the channel parameter. However, it doesn't explain tenant_id or provide details on connector_type values or JSON body structure, leaving gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a new connector') and specifies the required parameters (name and connector_type), distinguishing it from sibling tools like cdp_get_connector or cdp_update_connector. However, it doesn't explicitly differentiate from cdp_create_connector_template or cdp_create_output_connector, which are similar creation 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 by mentioning two modes (simple creation with name/connector_type vs. advanced configuration with JSON body), but doesn't explicitly state when to use this tool versus alternatives like cdp_create_connector_template or cdp_create_output_connector. It provides some context about channel options but lacks clear exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states it's a read operation ('Get details'), implying non-destructive behavior, but doesn't address permissions needed, error conditions (e.g., invalid tenant ID), rate limits, or response format. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise—two sentences that directly address the tool's purpose and parameter semantics without any fluff. The first sentence states what the tool does, and the second provides crucial parameter context. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter, read-only operation) and the existence of an output schema (which handles return values), the description is minimally adequate. However, with no annotations and incomplete parameter documentation in the schema, the description should ideally address more behavioral aspects like authentication requirements or error handling to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context about the single parameter 'target_tenant_id' by explaining that tenant IDs 'may be numeric, a GUID, or a slug'. This clarifies the expected format beyond what the schema provides (just 'string' type with 0% description coverage). Since there's only one parameter, the description adequately compensates for the schema's lack of detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get details') and resource ('specific tenant by ID'), making the purpose unambiguous. It distinguishes from sibling tools like 'cdp_list_tenants' by specifying retrieval of a single tenant rather than listing multiple. However, it doesn't explicitly contrast with other 'get_' tools that might fetch different resource types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., authentication), when-not-to-use scenarios, or compare it to similar tools like 'cdp_get_user' or 'cdp_list_tenants'. The agent must infer usage from the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It implies a read-only operation ('List'), but doesn't disclose behavioral traits like whether it requires authentication, returns paginated results, has rate limits, or what the output format is. This is inadequate for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without any wasted words. It's appropriately sized for a simple list operation.
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 (list operation), no annotations, and an output schema exists (which handles return values), the description is minimally adequate. However, it lacks details on authentication, pagination, or error handling, which are gaps for a tool with zero annotation 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?
The description adds no parameter semantics beyond the input schema, which has 0% coverage. However, there is only one optional parameter ('tenant_id'), and the tool likely functions without it. The baseline is 4 for zero parameters, but since there is one undocumented parameter, it's slightly penalized but still high due to minimal parameter 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 the verb ('List') and resource ('all available permission actions that can be assigned to roles'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'cdp_list_roles' or 'cdp_get_role', which would require a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are no mentions of prerequisites, context, or exclusions, leaving the agent without usage direction beyond the basic purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'Supports optional search and tenantIds' which gives some operational context, but doesn't describe important behavioral aspects like whether this is a read-only operation, pagination behavior (implied by offset/limit parameters but not explained), authentication requirements, rate limits, or what happens when no tenant is specified. The description provides minimal behavioral context beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences that each add value. The first sentence states the core purpose, and the second provides important parameter context. There's no wasted language, and the structure is front-loaded with the primary function. It could be slightly more structured by explicitly separating parameter explanations.
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 with 0% schema coverage and no annotations, the description provides basic operational context but leaves significant gaps. It covers the core purpose and some parameter usage, but doesn't address behavioral aspects, error conditions, or relationships between parameters. The existence of an output schema reduces the need to describe return values, but the description should do more to compensate for the lack of annotations and parameter documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter documentation. The description adds meaningful context for two parameters ('search' and 'tenantIds'), including format guidance for tenantIds ('comma-separated string'). However, it doesn't address the other three parameters (tenant_id, offset, limit) or explain their relationships (e.g., tenant_id vs tenant_ids, pagination with offset/limit). The description partially compensates for the schema gap but leaves significant parameter semantics undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List all roles') and resource ('for a CDP tenant'), providing a specific verb+resource combination. It distinguishes itself from other 'list' tools by specifying the resource type (roles), but doesn't explicitly differentiate from other role-related tools like 'cdp_get_role' or 'cdp_create_role' beyond the inherent 'list' vs 'get/create' distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning 'multi-tenant queries' and optional parameters, but doesn't provide explicit guidance on when to use this tool versus alternatives. It doesn't mention when NOT to use it or refer to specific sibling tools for different scenarios (like 'cdp_get_role' for single role retrieval).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool 'Returns whether SSO is required for the user', which implies a read-only operation returning a boolean or status, but doesn't disclose behavioral traits like authentication requirements, rate limits, error conditions, or what 'SSO state' entails (e.g., enabled/disabled, configuration details). For a tool with zero annotation coverage, this leaves significant gaps in understanding how it behaves.
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 appropriately sized and front-loaded: the first sentence states the core purpose, and the second adds optional parameter context. Every sentence earns its place with no wasted words, making it easy to scan and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, read-only operation), no annotations, and an output schema present, the description is minimally complete. It covers the purpose and parameters but lacks behavioral context (e.g., permissions, errors) that annotations would typically provide. The output schema likely details return values, so the description doesn't need to explain them, but overall completeness is adequate with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning by explaining that 'username' identifies the user and 'tenant' optionally scopes the check, which clarifies the purpose of both parameters beyond their schema titles. However, it doesn't provide details on parameter formats, constraints, or examples (e.g., username format, tenant ID structure). With 2 parameters and low schema coverage, the description offers basic semantics but lacks depth.
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: 'Check the SSO state for a given user' with the specific verb 'check' and resource 'SSO state'. It distinguishes from siblings by focusing on SSO state checking, unlike other tools that handle caching, campaigns, or user management. However, it doesn't explicitly differentiate from similar 'get' operations like cdp_get_user, though the SSO-specific focus 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning 'optionally scoped to a specific tenant', suggesting when to use the tenant parameter. However, it doesn't provide explicit guidance on when to use this tool versus alternatives (e.g., other user-related tools like cdp_get_user or authentication tools), nor does it mention prerequisites or exclusions. The guidance is limited to parameter usage without broader context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a read operation ('Get'), which implies it's non-destructive, but doesn't clarify authentication requirements, rate limits, error conditions, or what specific 'session and permissions info' includes. The mention of 'current bearer token' hints at authentication context but lacks depth about security implications 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 efficiently structured in two sentences: the first states the core purpose, the second adds parameter guidance. Every word earns its place with zero redundancy, and key information is front-loaded. It's appropriately sized for a simple lookup tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (authentication context, 2 parameters), no annotations, and an output schema (which reduces need to describe returns), the description is minimally adequate. It covers the basic purpose and one parameter's use but misses details about the token parameter, authentication behavior, and what 'session and permissions info' entails. For a security-related tool, this leaves gaps in understanding proper 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 description coverage is 0%, so the schema provides no parameter documentation. The description mentions 'tenant_name' as optional for scoping, adding some semantic context beyond the schema. However, it doesn't explain the 'token' parameter's purpose or format, leaving half the parameters (1 of 2) without meaningful description. This partially compensates but doesn't fully address the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and target resources ('session and permissions info for the current bearer token'), making the purpose explicit. It distinguishes itself from sibling tools by focusing on authentication/authorization context rather than data operations like cdp_get_user or cdp_get_token. However, it doesn't explicitly contrast with other 'get' tools that might return similar metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context by mentioning 'Optionally specify a tenant_name to scope the response,' which implies when to use the optional parameter. However, it lacks explicit guidance on when to choose this tool over alternatives like cdp_get_token or cdp_get_user for authentication-related queries, and doesn't mention prerequisites such as needing a valid token.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the HTTP method (GET) and endpoint, implying a read-only operation, but doesn't disclose behavioral traits like authentication needs, rate limits, pagination, error handling, or what the response format looks like. The description adds some context about the generic controller and filters, but overall behavioral disclosure is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, starting with the core purpose. It uses two sentences efficiently: one for the main action and one for parameter context. There's minimal waste, though it could be slightly more structured (e.g., bullet points for filters).
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 6 parameters with 0% schema coverage, no annotations, but an output schema exists, the description is moderately complete. It covers the purpose and key parameters but lacks details on behavioral aspects, error cases, and output structure. The presence of an output schema reduces the need to explain return values, but more context on usage and constraints would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate. It effectively explains the semantics of parameters: resource_type defaults to 'statusmessage' and the controller is generic, and lists filters (event_type, entity_type, entity_id, workflow_id). However, it doesn't cover tenant_id or provide details on parameter formats, constraints, or interactions, leaving some gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get status messages for a workflow/entity event' with specific resource and filter details. It distinguishes itself from siblings by focusing on status messages rather than other CDP entities like campaigns, users, or workflows, though it doesn't explicitly compare to similar 'get' tools like cdp_get_workflow_job or cdp_get_orchestration_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?
The description implies usage context by mentioning 'workflow/entity event' and filters, but doesn't explicitly state when to use this tool versus alternatives. It notes that resource_type defaults to 'statusmessage' and the controller is generic, suggesting flexibility, but lacks guidance on prerequisites, exclusions, or specific scenarios where this tool is preferred over other status-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the tool's behavior by describing two authentication methods and what they fetch, but it lacks critical details: it doesn't specify if this is a read-only operation (though 'Get' implies it), what permissions are required, rate limits, error conditions, or the format of the returned token information. For a tool with no annotations, this leaves significant gaps in behavioral understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and front-loaded: it states the purpose in the first three words, followed by a clear explanation of the two usage modes in a single sentence. Every word earns its place with no redundancy or fluff, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the context: no annotations, 0% schema description coverage, 4 parameters, and an output schema exists (so return values are documented elsewhere). The description is complete enough for basic understanding but lacks depth. It covers the tool's purpose and two authentication methods, but doesn't address behavioral aspects like security requirements, error handling, or parameter interactions. With an output schema, it doesn't need to explain returns, but other gaps remain for a tool with no annotation support.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description adds some semantics by explaining that 'token' is for bearer token authentication and 'username/password' for Basic auth, and implies 'scheme' might relate to authentication (default 'A1USER'). However, it doesn't cover all four parameters comprehensively (e.g., the purpose of 'scheme' beyond the default, or how parameters interact). It compensates partially but not fully for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get token information.' It specifies the verb ('Get') and resource ('token information'), and distinguishes between two authentication methods (bearer token vs. username/password). However, it doesn't explicitly differentiate from sibling tools like 'cdp_create_token' or 'cdp_revoke_token' beyond the 'Get' action, which is implied but not stated.
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 implied usage guidance by explaining two authentication scenarios (bearer token for specific token info, username/password for user's token). It doesn't explicitly state when to use this tool versus alternatives (e.g., 'cdp_create_token' for creating tokens or 'cdp_login' for authentication), nor does it mention prerequisites or exclusions. The guidance is functional but lacks comparative context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'Requires type parameter,' indicating a constraint, but lacks details on permissions, rate limits, pagination, or what 'List available' entails (e.g., all templates vs. filtered). For a read operation with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero waste: the first states the purpose, and the second adds crucial parameter guidance. It's front-loaded and appropriately sized, earning its place efficiently 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 2 parameters with 0% schema coverage, no annotations, but an output schema exists, the description is moderately complete. It covers the purpose and key parameter but misses details on tenant_id, behavioral traits, and relies on the output schema for return values. For a simple list tool, this is adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning for 'template_type' by providing examples (PLAYBOOK, MESSAGE, AUDIENCE), which clarifies the parameter beyond the schema's generic string type. However, it doesn't address the 'tenant_id' parameter at all, leaving half of the parameters undocumented. This partial compensation results in a 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 the verb ('List') and resource ('available campaign templates'), making the purpose explicit. It distinguishes from siblings by focusing specifically on templates rather than campaigns or other resources, though it doesn't explicitly contrast with similar list tools like cdp_list_campaigns or cdp_list_message_defs.
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 mentioning the required type parameter with examples (PLAYBOOK, MESSAGE, AUDIENCE), suggesting when to use it for template listing. However, it doesn't provide explicit guidance on when to choose this over alternatives like cdp_get_campaign_template or when not to use it, nor does it mention prerequisites beyond the parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It doesn't disclose whether this is a read-only operation, whether it requires authentication, how results are returned (e.g., pagination behavior), rate limits, or error conditions. The description only states what the tool does, not how it behaves.
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 efficiently structured in two sentences: the first states the core functionality, the second adds valuable domain context. There's no wasted text, though it could be slightly more front-loaded with key behavioral information given the lack of 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?
Given that there's an output schema (which handles return values), no annotations, and 3 parameters with 0% schema coverage, the description is incomplete. It explains what CubicSetDefs are but doesn't address parameter usage, behavioral traits, or provide sufficient context for safe invocation. The output schema reduces the burden but doesn't compensate for missing parameter and behavioral information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter documentation. The description mentions 'for a tenant' which hints at 'tenant_id', but doesn't explain the three parameters (tenant_id, offset, limit) or their purposes. It doesn't clarify whether tenant_id is required, what offset/limit do, or default behaviors.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 specific action ('List all CubicSetDefs'), identifies the resource ('OLAP query definitions'), and provides domain context ('Saiku-based cube queries used by CUBE-type reports'). It distinguishes itself from sibling tools like 'cdp_get_cubic_set_def' (singular retrieval) and 'cdp_copy_cubic_set_def' (copy operation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning 'for a tenant' and the purpose of CubicSetDefs, but doesn't explicitly state when to use this tool versus alternatives like 'cdp_list_cube_metadata' or 'cdp_list_report_defs'. No guidance is provided about prerequisites, permissions, or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions listing 'raw audience definitions' but doesn't disclose behavioral traits like whether this is a read-only operation, if it requires specific permissions, pagination behavior (implied by offset/limit parameters but not explained), rate limits, or what the output looks like. The description adds minimal context beyond the basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero waste. It front-loads the core purpose and follows with a usage guideline, making it efficient and well-structured. 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's moderate complexity (listing with filtering/pagination), no annotations, 0% schema coverage, but an output schema exists, the description is partially complete. It explains the purpose and a use case but lacks parameter explanations and behavioral details. The output schema mitigates the need to describe return values, but other gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The tool description does not mention any parameters, failing to explain what 'tenant_id', 'offset', 'limit', or 'lookup' mean or how they affect the listing. This leaves all 4 parameters undocumented, which is a significant gap given the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List datasetDefs') and resource ('raw audience definitions for a tenant'), making the purpose understandable. It distinguishes from siblings by specifying it lists 'datasetDefs' rather than other resources like campaigns or connectors, though it doesn't explicitly contrast with similar list tools like 'cdp_list_audience_defs'.
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 for when to use this tool: 'Useful for discovering shared definitions before calling cdp_copy_datasetdef.' This gives a specific use case and mentions a related tool, though it doesn't explicitly state when not to use it or compare with all alternatives like 'cdp_get_dataset_def' or other list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the HTTP method (POST) and that some actions require a body, but doesn't disclose critical behavioral traits like whether these actions are destructive, require specific permissions, have rate limits, or what the typical response looks like. For a mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with only two sentences that directly convey essential information: what the tool does, available actions, and parameter requirements. Every word earns its place with zero wasted text, making it front-loaded and 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 the tool has 4 parameters with 0% schema coverage and no annotations, but does have an output schema, the description provides basic action and parameter guidance but lacks behavioral context. It's minimally adequate for understanding what the tool does but insufficient for safe operation without additional documentation about effects, permissions, 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 description coverage is 0%, so the description must compensate. It adds value by explaining that 'action' accepts specific values (regenerate_credentials, apply_policy_change) and that 'body' is required for apply_policy_change and should be a JSON string. However, it doesn't explain 'instance_id' or 'tenant_id' semantics, leaving two of four parameters with minimal context.
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 actions on a provision instance, specifying two concrete actions (regenerate_credentials, apply_policy_change). It distinguishes from siblings like cdp_create_provision_instance or cdp_update_provision_instance by focusing on specific operational actions rather than creation or general updates. However, it doesn't explicitly differentiate from all sibling tools in the extensive 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?
The description implies usage when needing to perform one of the two listed actions on a provision instance, and mentions that apply_policy_change requires a body parameter. However, it doesn't provide explicit guidance on when to choose this tool over alternatives like cdp_update_provision_instance or cdp_reactivate_provision_instance, nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that credentials are sent via Authorization header and returns token details (access_token, token_type, expires_in), which is useful behavioral context. However, it lacks details on rate limits, error conditions, or whether this invalidates existing tokens. The description doesn't contradict annotations (none provided), but it's incomplete for a security-sensitive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise with three sentences that efficiently cover authentication method, credential transmission, and return values. Each sentence adds value without redundancy, and key information is front-loaded. No wasted words or structural issues.
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 complexity (authentication/token creation), no annotations, and an output schema (implied by 'Has output schema: true'), the description is reasonably complete. It covers the core operation and return values, though it lacks details on error handling, security implications, or parameter specifics. The output schema likely documents return structure, reducing burden on 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 0%, so the description must compensate. It mentions 'Basic authentication' and 'Credentials', implying username and password parameters, but doesn't explain the optional 'scheme' parameter or its default value 'A1USER'. The description adds some meaning by linking parameters to authentication context, but fails to fully document all three parameters, leaving gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates an access token using Basic authentication, specifying the verb 'Create' and resource 'access token'. It distinguishes from siblings like cdp_get_token (retrieval) and cdp_extend_token (extension), though not explicitly named. However, it doesn't fully differentiate from cdp_login (authentication-related) without explicit comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 cdp_login, cdp_extend_token, or cdp_revoke_token is provided. The description mentions Basic authentication but doesn't specify prerequisites (e.g., valid credentials) or exclusions (e.g., when a token already exists). 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the tool is for polling an async calculation, which implies it might return pending or error states, but doesn't disclose behavioral traits like rate limits, authentication needs, error handling, or what the output contains (though an output schema exists). For a tool with no annotation coverage, this is a significant gap, warranting a score of 2.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the key information: the purpose and usage guideline. There is no wasted text, and it's appropriately sized for the tool's complexity, earning a score of 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (async polling with 2 parameters), no annotations, and an output schema (which handles return values), the description is partially complete. It covers purpose and usage but lacks parameter details and behavioral context. With the output schema mitigating some gaps, a score of 3 reflects an adequate but incomplete description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about the parameters (tenant_id and job_id). It doesn't explain what these parameters mean, their requiredness, or how they relate to the async calculation. With two parameters and no schema descriptions, the description fails to compensate, resulting in a score of 1.
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 the result of an async audience calculation' specifies the verb ('Get') and resource ('result'), and distinguishes it from its sibling 'cdp_calculate_audience' by indicating it's for polling after that calculation. However, it doesn't fully differentiate from other get-like siblings (e.g., 'cdp_get_audience_count'), making it a 4 rather than 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'poll after cdp_calculate_audience', providing clear context and naming the specific alternative tool. This gives the agent direct guidance on the sequence of operations, meeting the criteria for a score of 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a read operation ('Get') and describes the return content ('full definition including reportDef and visualization settings'), which is helpful. However, it lacks critical behavioral details like authentication requirements, error conditions (e.g., invalid widget ID), rate limits, or whether the operation is idempotent. The description adds some value but leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (two short sentences) and front-loaded with the core purpose. Every word earns its place: 'Get a widget by ID' establishes the action, and 'Returns full definition...' adds necessary output context without redundancy. No wasted words or structural issues.
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 moderate complexity (2 parameters, read operation), the description covers the essential purpose and output content. The existence of an output schema means the description doesn't need to detail return values. However, with no annotations and 0% schema coverage, the description should provide more behavioral and parameter guidance to be fully complete for safe agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description mentions 'by ID' which clarifies the purpose of 'widget_id', but doesn't explain 'tenant_id' at all. It adds minimal semantic value beyond what's inferable from parameter names, failing to fully compensate for the schema coverage gap. With 2 parameters (one required), the description should do more to explain their roles.
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 ('Get') and resource ('widget by ID'), making the purpose immediately understandable. It distinguishes from siblings like 'cdp_list_widgets' by specifying retrieval of a single widget rather than listing. However, it doesn't explicitly contrast with other get operations like 'cdp_get_dashboard' or 'cdp_get_report_def' beyond the widget focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a valid widget ID), when not to use it (e.g., for listing widgets), or refer to sibling tools like 'cdp_list_widgets' for broader queries. The agent must infer usage solely from the tool name and parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the tool's destructive nature (revoking tokens) and authentication options, but misses critical behavioral details like required permissions, side effects (e.g., logged-out sessions), rate limits, or response format. For a security-sensitive mutation tool, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core purpose and efficiently details the two input modes. Every word earns its place with no redundancy or fluff, making it highly concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (security mutation with 4 parameters), lack of annotations, and 0% schema coverage, the description is incomplete. It covers purpose and parameter semantics partially but misses behavioral context (e.g., auth requirements, effects). The presence of an output schema (per context signals) mitigates the need to describe return values, but other gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It effectively explains the semantics of 'token' (for specific revocation) and 'username/password' (for bulk revocation), adding crucial meaning beyond the schema's generic titles. However, it omits the 'scheme' parameter entirely, leaving one of four parameters undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('revoke') and resource ('access token'), specifying it can target a specific token or all tokens for a user. It distinguishes from siblings like 'cdp_create_token' or 'cdp_extend_token' by focusing on revocation, but doesn't explicitly contrast with other token-related tools beyond naming 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?
It implies usage by describing two input scenarios (bearer token vs username/password), which suggests when to use each approach. However, it lacks explicit guidance on when to choose this tool over alternatives (e.g., vs 'cdp_delete_token' if it existed), prerequisites, or error conditions, leaving usage context partially inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and adds valuable behavioral context: it specifies the HTTP method (POST), endpoint pattern (/v2/{tenantId}/spam/score), required request format (JSON array), and error behavior for incorrect input. However, it doesn't mention rate limits, authentication needs, or what the scoring output looks like (though output schema exists).
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 appropriately sized and front-loaded with the core purpose. Every sentence adds value: first states purpose, second specifies request format, third warns about error. No wasted words, though the parameter mismatch slightly reduces effectiveness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 parameters with 0% schema coverage, no annotations, but an output schema exists, the description is moderately complete. It covers the endpoint and format requirements but fails to properly document parameters (creating confusion with mismatched names). The output schema reduces need to describe return values, but parameter documentation gap is significant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but doesn't adequately explain parameters. It mentions array elements like 'subject', 'body', 'fromAddress', 'fromName' which don't match the actual schema parameters ('body' and 'tenant_id'). This creates confusion rather than adding clarity beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Score email/message content for spam likelihood' with specific verb ('score') and resource ('email/message content'). It distinguishes from siblings by its unique spam scoring function, though it doesn't explicitly contrast with similar tools since none exist in the sibling list for spam analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying the required JSON array format and error condition ('Passing a single object returns E400'), but it doesn't provide explicit guidance on when to use this tool versus alternatives or any prerequisites. No sibling tools offer similar spam scoring, so differentiation isn't needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the tool updates a password and requires a reset code, but doesn't disclose behavioral traits like authentication needs, rate limits, error conditions, or what happens on success (e.g., if the user is logged out). For a mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the purpose and lists parameters without waste. Every word contributes to understanding the tool's function and inputs.
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 a mutation tool with no annotations, 3 parameters, 0% schema coverage, and an output schema (which reduces need to explain returns), the description is moderately complete. It covers the purpose and parameters but lacks behavioral details like security implications or error handling, which are important for a password update operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists all three parameters (username, reset code, new password) and explains their purpose, adding meaning beyond the schema's bare titles. This covers the parameters adequately, though it doesn't detail constraints like password complexity.
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 ('Update a user's password') and resource ('user's password'), specifying it uses a reset code. It distinguishes from siblings like 'cdp_update_user' or 'cdp_generate_password_reset' by focusing on password updates via reset codes, though not explicitly naming alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by stating 'using a valid reset code,' suggesting it's for password reset scenarios. However, it doesn't explicitly say when to use this vs. other user-update tools or provide prerequisites beyond the reset code, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the operation is asynchronous and returns a jobId for polling, which is useful behavioral context. However, it lacks details on permissions, rate limits, error handling, or what the segment definition JSON should contain, leaving gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by essential usage details. Both sentences earn their place by providing critical information without redundancy, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (asynchronous mutation with 2 parameters, 0% schema coverage, no annotations, but with an output schema), the description is partially complete. It covers the asynchronous nature and polling mechanism but lacks details on parameters, error cases, and behavioral traits. The output schema may handle return values, but the description should do more to guide usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning for the 'body' parameter by specifying it as a 'segment definition as a JSON string', which clarifies its purpose beyond the schema. However, it does not explain the 'tenant_id' parameter or provide examples or constraints for the JSON, leaving significant gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Start an asynchronous audience count calculation') and the resource ('audience'), specifying it's asynchronous. It distinguishes from sibling tools like 'cdp_get_audience_count' by indicating this initiates a calculation job rather than retrieving a count directly. However, it doesn't explicitly differentiate from all siblings, such as 'cdp_execute_audience_def', which might have overlapping purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool: for starting an asynchronous calculation that returns a jobId to poll later with 'cdp_get_calculated_count'. It implies an alternative by referencing the polling tool, but does not explicitly state when not to use it or compare with other audience-related tools like 'cdp_get_audience_count'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the tool performs a POST operation (implying a write/mutation) and describes the endpoint structure, but lacks critical behavioral details like authentication requirements, rate limits, error handling, or what constitutes a successful event post. This is a significant gap for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in two sentences: the first states the purpose and endpoint, the second details parameter usage. Every sentence provides essential information with zero waste, making it easy to parse front-loaded key details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values), no annotations, and 3 parameters with 0% schema coverage, the description adequately covers the purpose and parameters but lacks behavioral context for a mutation tool. It's minimally viable but leaves gaps in usage guidelines and transparency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates well by explaining all three parameters: 'body' as a JSON string with required fields (eventType, identityHash, properties), 'api_version' as a routable path segment with default 'v2', and 'tenant_id' as part of the endpoint path. It adds meaningful context beyond the bare schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 specific action ('Post a real-time tracking event'), target resource ('to the CDP'), and method (HTTP POST with endpoint path). It distinguishes itself from sibling tools by focusing on event tracking rather than cache operations, audience calculations, or other CDP functions listed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives. While the description mentions the API endpoint and parameter defaults, it doesn't specify use cases, prerequisites, or exclusions. The agent must infer usage from the purpose 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?
With no annotations provided, the description carries the full burden. It discloses that the tool sends an email (a side effect) and requires specific parameters, which is useful. However, it doesn't mention critical behavioral aspects like whether this action is reversible, what permissions are needed, rate limits, or what happens if the username doesn't exist. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by side effects and requirements in subsequent sentences. Every sentence adds value—no wasted words—and it's appropriately sized for a tool with two parameters and clear functionality.
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 that there's an output schema (which handles return values), no annotations, and low schema coverage, the description does a good job covering the basics: purpose, side effects, and parameter context. However, for a mutation tool that sends emails and likely requires specific permissions, it could benefit from mentioning security implications or error conditions to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context beyond the input schema. While the schema only lists 'username' and 'source' with titles and types (0% description coverage), the description explains that 'username' identifies the user and 'source' can be 'VEGA or CONFIG', clarifying the purpose of these parameters. This compensates well for the low schema coverage, though it doesn't detail format constraints or provide examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 specific action ('Generate a password reset link'), the target resource ('for a user'), and the side effect ('Sends a reset email to the user's registered address'). It distinguishes itself from sibling tools like 'cdp_update_password' or 'cdp_validate_password_reset' by focusing on link generation and email notification rather than direct password modification or validation.
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 a user needs a password reset link sent via email, but it doesn't explicitly state when to use this tool versus alternatives like 'cdp_update_password' (for direct password changes) or 'cdp_validate_password_reset' (for validating reset tokens). It mentions required parameters but doesn't provide context about 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates this is a publish/mutation operation (implied by 'Publish'), mentions the specific workflow used ('CAMPAIGN_FLOW_DEFAULT'), and references the UI equivalent. However, it doesn't address important behavioral aspects like required permissions, whether the action is reversible, rate limits, or what happens to campaigns in different states. For a mutation tool with zero annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in three sentences that each add distinct value: stating the core action, providing usage guidance with sibling differentiation, and giving UI context. There is no wasted text, and the most critical information (what the tool does and when to use it) appears first.
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 this is a mutation tool with no annotations, 3 parameters (all undocumented in schema), and an output schema exists, the description does well on purpose and usage but falls short on parameter semantics and behavioral transparency. The existence of an output schema means return values are documented elsewhere, but for a publish operation that likely changes system state, more behavioral context would be valuable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for all 3 parameters, the description provides no information about what 'entity_id', 'tenant_id', or 'web_action' represent, their formats, or how they affect the publish operation. The description mentions 'triggered/web campaign' which might relate to 'entity_id', but this is insufficient to compensate for the complete lack of parameter documentation in both schema and description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 specific action ('Publish a triggered/web campaign via the CAMPAIGN_FLOW_DEFAULT workflow'), identifies the resource ('triggered/web campaign'), and explicitly distinguishes it from a sibling tool ('cdp_start_campaign only works for batch 'send now' runs'). This provides precise differentiation within the toolset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool ('correct action for real-time/triggered campaigns (web, API, journey)') and when not to use it (contrasting with 'cdp_start_campaign' for batch runs). It also mentions the UI equivalent ('Mirrors what the Vega UI does when you click 'Publish''), giving clear 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?
No annotations are provided, so the description carries the full burden. It implies a read-only operation ('Get') but doesn't disclose behavioral traits like pagination (offset/limit usage), authentication needs, rate limits, error conditions, or response format. The mention of identifiers is helpful but insufficient for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste. The first sentence states the purpose and required parameters; the second provides crucial usage guidance. Every word earns its place, and the structure is front-loaded with 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?
Given the tool's moderate complexity (7 parameters, OLAP-specific) and the presence of an output schema (which handles return values), the description is reasonably complete. It covers purpose and prerequisites but lacks details on parameter semantics and behavioral traits. With no annotations, it could be more comprehensive, but the output schema mitigates some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists the four required parameters (cube_id, dimension_id, hierarchy_id, level_name) but doesn't explain their semantics, format, or source. It ignores the optional parameters (tenant_id, offset, limit), leaving them completely undocumented. This adds minimal 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 action ('Get the values') and target ('for a specific dimension level within an OLAP cube hierarchy'). It distinguishes from siblings by specifying its unique OLAP cube data retrieval function, unlike other tools that handle caching, campaigns, or user management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use this tool ('Requires cube_id, dimension_id, hierarchy_id, and level_name') and provides a clear alternative for discovery ('Use cdp_get_cube_metadata first to discover these identifiers'). This directly guides the agent on prerequisites and sequencing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that the tool revokes tokens (destructive behavior) and explains different revocation scopes (single token vs all user tokens). However, it doesn't mention authentication requirements, rate limits, or what happens after logout (e.g., session termination 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?
Two sentences with zero waste. The first sentence states the core purpose, the second explains parameter usage. Every word earns its place, and the structure is front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, 0% schema coverage, but with an output schema present, the description is reasonably complete. It covers the destructive nature and parameter semantics well. The output schema likely handles return values, so the description doesn't need to explain them. Some behavioral context like auth requirements is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 3 parameters, the description fully compensates by explaining the semantic meaning of each parameter: 'token' revokes a specific bearer token, while 'username/password' revokes all tokens for that user. This adds crucial context beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('logout and revoke') and resource ('current bearer token'), distinguishing it from siblings like 'cdp_login' and 'cdp_revoke_token'. However, it doesn't explicitly differentiate from 'cdp_revoke_token' which might handle token revocation differently.
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 on when to use specific parameters (token vs username/password), implying usage scenarios. It doesn't explicitly state when not to use this tool or name alternatives like 'cdp_revoke_token', but the parameter guidance is helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly describes the mutation behavior ('Creates a copy with a new ID'), output format ('returns the cloned object'), and resource constraints ('any resource that supports versioning'), but doesn't mention permission requirements, rate limits, or error conditions that would be important for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in three sentences: first states the core purpose, second provides scope and output details, third gives specific parameter guidance. Every sentence adds value with zero wasted words, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a mutation tool with 3 parameters (0% schema coverage), no annotations, but with an output schema, the description does well by explaining the cloning behavior, resource constraints, and parameter usage. However, for a mutation tool, it should ideally mention permission requirements or side effects that aren't covered by the output schema alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate for the undocumented parameters. It provides crucial semantic information about resource_path format ('must include the ID, e.g. 'campaigndefs/123'') and path_style usage ('Set path_style to 'none' for campaign/config/connector resources'), though it doesn't explain tenant_id's purpose or provide examples for all parameter 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 states the specific action ('Clone any CDP resource instance') and resource scope ('campaigns, workflows, connectors, predictions, reports, etc.'), distinguishing it from sibling tools like cdp_clone_campaign and cdp_clone_prediction by being a generic cloning tool for any versioned resource rather than specific resource types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use the tool ('Works on any resource that supports versioning') and includes a specific parameter usage guideline ('Set path_style to 'none' for campaign/config/connector resources'), but doesn't explicitly mention when NOT to use it or name alternative tools for non-versioned resources.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes what the tool returns (field names, types, editability, default page size) and mentions the 'path_style' parameter behavior, which adds useful context. However, it doesn't disclose other behavioral traits like authentication requirements, rate limits, error conditions, or whether it's a read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with two sentences that are front-loaded with the core purpose. Every sentence adds value: the first explains what the tool does and its scope, the second provides specific parameter guidance. There is no wasted 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 that there's an output schema (which handles return values), no annotations, and 3 parameters with 0% schema coverage, the description does a good job explaining the tool's purpose and two parameters. However, it misses the 'tenant_id' parameter and doesn't cover behavioral aspects like authentication or error handling, leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate. It explains the 'resource_path' parameter with examples (collections vs instances) and provides guidance on 'path_style' for specific resource types. However, it doesn't mention the 'tenant_id' parameter at all, leaving one of three parameters undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verb ('Get') and resource ('JSON Schema description of any CDP resource'), and distinguishes itself from siblings by focusing on schema retrieval rather than data manipulation or other operations. It specifies it works on both collections and instances, making the scope explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool (to get schema descriptions for CDP resources) and includes a specific usage note about setting 'path_style' for certain resource types. However, it does not explicitly state when not to use it or name alternative tools for related purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the authentication method (Basic auth), the output (bearer token with details), and the optional tenant scoping. However, it doesn't mention critical behavioral aspects like rate limits, error conditions, session management, or whether this invalidates previous tokens. For a security-sensitive authentication tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly front-loaded with the core purpose in the first clause, followed by optional parameter context and return values. Every sentence earns its place with no wasted words, making it highly efficient while remaining complete.
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 that this is an authentication tool with no annotations, 3 parameters, and an output schema exists (so return values are documented elsewhere), the description does well by covering the authentication mechanism, optional parameter context, and output summary. However, for a security-critical operation, it should ideally mention authentication prerequisites, error handling, or token lifecycle details to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate. It explicitly mentions 'tenant_name' and explains its purpose ('to scope the login'), adding valuable semantic context beyond the bare parameter names in the schema. However, it doesn't explain the semantics of 'username' and 'password' beyond what's obvious from their names, leaving some parameter meaning implicit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Authenticate a user via Basic auth and generate a bearer token'), the resource (user authentication), and distinguishes it from all sibling tools which are unrelated to authentication. It goes beyond just restating the name by explaining the authentication mechanism and token generation.
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 for when to use this tool ('Authenticate a user') and mentions an optional parameter ('Optionally specify a tenant_name to scope the login'), which gives some guidance on usage variations. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools, though cdp_logout is clearly complementary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool performs a mutation ('Roll back', 'PUT as current') and returns a value ('Returns the new version number'), which is helpful. However, it lacks details on permissions, side effects, error conditions, or rate limits that would be important for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with three sentences: purpose, equivalent operation, and parameter guidance. Each sentence adds value without redundancy, and key information is front-loaded. It avoids unnecessary elaboration while covering essential points.
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 complexity (mutation with 4 parameters, 0% schema coverage, no annotations), the description does a good job explaining purpose, usage, and some parameters. The presence of an output schema means return values are documented elsewhere, reducing the burden. However, for a mutation tool, more behavioral context (e.g., permissions, idempotency) would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the meaning of 'resource_path' (must include ID, e.g., 'workflows/456') and 'path_style' (set to 'none' for specific resources), adding crucial context beyond the bare schema. It does not cover 'tenant_id' or 'version' semantics, but the coverage of two key parameters is substantial given 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?
The description clearly states the tool's purpose with specific verbs ('Roll back', 'Set') and resource scope ('any CDP resource', 'any versioned resource'). It distinguishes itself from siblings by focusing on version rollback rather than creation, deletion, or other operations listed in the 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 provides clear context for when to use the tool ('Roll back any CDP resource to a specific version') and includes an example for resource_path formatting. However, it does not explicitly state when NOT to use it or name specific alternatives among the many sibling tools, though the unique purpose implies differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes a critical behavioral constraint ('standalone messageDefs created here CANNOT be referenced from a campaign by resourceId — the server rejects shared references with E0420'), which is essential for correct usage. However, it doesn't mention other potential behavioral aspects like permissions needed, rate limits, or whether the operation is idempotent.
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 efficiently structured with four sentences that each add value: stating the purpose, providing the parameter format, giving a critical warning with error details, and specifying the appropriate usage context. There's no wasted text, and the most important information (the warning) is prominently placed.
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 that there's an output schema (which handles return values) but no annotations and 0% schema description coverage, the description does well on purpose and guidelines but falls short on parameter documentation. The critical behavioral warning compensates somewhat, making it mostly complete for safe usage but incomplete for parameter understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, meaning parameters are completely undocumented in the schema. The description only vaguely mentions 'Pass as a JSON string list' without explaining what the 'body' parameter should contain or what format the JSON should have. It doesn't address the 'tenant_id' parameter at all, leaving significant gaps in 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 specific action ('Create standalone message definitions') and resource ('message definitions'), distinguishing it from the sibling tool 'cdp_update_campaign' by explicitly contrasting standalone vs. campaign-bound usage. It provides precise differentiation beyond just the verb and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly defines when to use this tool ('for message templates that are independently managed') and when not to use it ('For campaign-bound emails, instead put the messageDef object INLINE in the campaign's 'messageDefs' array via cdp_update_campaign'), including a named alternative tool. It also provides a specific error code (E0420) that helps avoid misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key traits: it's read-only (safe operation), supports only SELECT statements (restricts usage), and uses POST for long queries (handles large payloads). However, it lacks details on permissions, rate limits, or error handling, which would be helpful for a mutation-like tool (though read-only).
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 highly concise and front-loaded, with three sentences that each add critical information: the core action, the specific use case, and the restriction. There is no wasted text, and it efficiently communicates key points 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 complexity (SQL execution with parameters), no annotations, and an output schema exists (so return values are documented elsewhere), the description is reasonably complete. It covers purpose, usage guidelines, and key behavioral traits, but the lack of parameter details and some behavioral aspects (e.g., error handling) prevents a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It mentions 'SQL query' and 'POST body,' which loosely relates to the 'query' parameter, but provides no details on query format, SQL dialect, or the purpose of 'tenant_id.' This leaves significant gaps in understanding the parameters beyond their names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 specific action ('Execute a read-only SQL query via POST body'), identifies the resource (SQL queries), and distinguishes it from siblings by mentioning it's for long queries that exceed URL limits, unlike the sibling 'cdp_query_sql' which likely uses GET. It explicitly states 'Only SELECT statements are supported,' which further clarifies its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool ('for long queries that may exceed URL length limits') and when not to use it ('Only SELECT statements are supported'), implying it's not for write operations. It also suggests an alternative by contrasting with the sibling 'cdp_query_sql' (implied for shorter queries via GET), though not explicitly named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool triggers an execution (implying a write/mutation operation) and mentions optional parameters, but lacks details on permissions required, rate limits, error handling, or what 'trigger' entails (e.g., async/sync, job ID returned). It adds some context like body examples but misses critical behavioral traits for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by specific parameter guidance and examples. Every sentence adds value: the first states the action, the second explains optional parameters, and the third provides essential body examples. No wasted words, and structure is logical for tool invocation.
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 7 parameters with 0% schema coverage and no annotations, the description does well to explain key parameters and provide body examples. However, as a mutation tool with an output schema (implied by context signals), it lacks details on return values or execution results. It covers input semantics adequately but could benefit from mentioning output expectations or error cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate fully. It effectively explains the semantics of entity_type/entity_id ('for scoped runs'), schedule_id ('for scheduled runs'), and body (with concrete examples like CAMPAIGN_FLOW_DEFAULT). It clarifies that workflow_id is required and other parameters are optional, adding significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Trigger a workflow execution') and resource ('workflow'), distinguishing it from siblings like cdp_deploy_workflow or cdp_invoke_workflow_action. It explicitly mentions scoping options (entityType/entityId, scheduleId) and body parameter usage, making the purpose highly specific and actionable.
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 on when to use optional parameters (e.g., 'for scoped runs' or 'for scheduled runs') and gives examples of when body is required (CAMPAIGN_FLOW_DEFAULT, DATA_EXPORT_DEFAULT). However, it does not explicitly state when NOT to use this tool versus alternatives like cdp_start_campaign or cdp_run_data_export, which are also workflow-related 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?
With no annotations provided, the description carries full burden and does well: it discloses that this is a mutation operation (creates a new independent copy), explains the error condition that triggers its need (E400), and specifies the output usage (embed returned object in campaign audience field). It lacks details on permissions, rate limits, or side effects, but provides substantial behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense, front-loaded sentences with zero waste: first explains the core action and error context, second provides immediate usage guidance. Every phrase earns its place by addressing purpose, trigger, and next steps.
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 2 parameters with 0% schema coverage, no annotations, but an output schema exists, the description is reasonably complete. It explains the why, what, and how-to-use, though could better clarify parameter semantics. The output schema likely covers return values, so description focuses appropriately on 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?
Schema description coverage is 0%, so the description must compensate. It implies 'dataset_def_id' is the source to copy and 'tenant_id' might be contextual, but doesn't explicitly explain either parameter's role or format. The description adds some context about the error scenario but doesn't fully document parameter meanings beyond what's inferable from the schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 ('copy') and resource ('datasetDef/audience definition'), specifies it creates a 'new, independent one', and distinguishes it from sibling tools by explaining the specific error scenario (E400) that necessitates its use, unlike generic copy tools in the list.
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?
Explicitly states when to use ('CDP rejects shared datasetDefs across campaigns with E400') and provides a concrete alternative workflow ('Use this tool to produce a detached copy, then embed the returned object inline in your new campaign's audience field'), giving clear operational context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively warns about the unsupported endpoint (POST /campaign/audienceDefs) and the expected error (E400 'Request method POST is not supported'), which is crucial behavioral context that would not be captured in annotations alone.
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 the main purpose, followed by critical warnings and alternatives in a logical flow. Every sentence adds value: the first states the intent, the second warns of limitations, and the third provides a workaround with references.
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 complexity (creation operation with unsupported endpoint) and no annotations, the description does well to warn users and suggest alternatives. However, it lacks details on parameters and relies on an external resource link. The presence of an output schema mitigates some gaps in return value explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the parameters 'body' or 'tenant_id'. It mentions creating an audience definition but provides no details on what the 'body' should contain or the role of 'tenant_id', leaving parameters largely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 'audience definition', making the purpose explicit. It distinguishes this tool from siblings like cdp_create_campaign by specifying it creates audience definitions specifically, not campaigns or 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when NOT to use this tool (due to unsupported endpoint returning E400) and offers a clear alternative: define audience inline via cdp_create_campaign + cdp_update_campaign. It also references documentation for further 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?
With no annotations provided, the description carries full burden. It discloses that this creates a new schedule row (implying a write/mutation operation) and provides important behavioral context: the canonical shape of the body JSON, the source (ui-core ScheduleService.save), and the required follow-up action. It doesn't mention permissions, rate limits, or error handling, but gives substantial operational guidance.
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 appropriately front-loaded with the core purpose, but includes a lengthy JSON example that could be more concise. While the JSON details are valuable given the 0% schema coverage, the structure could be improved by separating the canonical shape into a more digestible format. Every sentence earns its place, but the presentation is dense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (creation tool with detailed JSON structure), no annotations, 0% schema coverage, but with output schema present, the description is remarkably complete. It explains what the tool does, provides the exact parameter structure with examples, specifies required follow-up actions, and references the source. The output schema will handle return values, so the description appropriately focuses on usage and input semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate fully. It provides extensive parameter semantics: body is a JSON string with detailed canonical shape including field names, types, enums, examples, and optional fields. It also clarifies tenant_id is optional with null default. This goes far beyond what the bare 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 action ('Create a new schedule row') and target resource ('in config/schedules'), which is specific and unambiguous. However, it doesn't explicitly differentiate from sibling tools like cdp_update_schedule or cdp_get_schedule, though the 'create' verb inherently suggests it's for new schedules rather than modifying existing ones.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: after creating a schedule, call cdp_invoke_workflow_action with action='schedule' and the returned scheduleId to arm it. This gives clear post-creation steps and distinguishes it from tools that might activate or manage schedules differently.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses critical behavioral traits: it's a destructive DELETE operation that can leave dangling trigger registrations if not preceded by the unschedule action, specifying affected workflows (AIF_RUNNER, REPORT_RUNNNER_DEFAULT). However, it doesn't mention error handling, response format, or permissions required, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and front-loaded: the first sentence states the core purpose, followed immediately by critical usage guidelines. Every sentence earns its place by providing essential operational context 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's destructive nature, no annotations, and an output schema (which handles return values), the description is mostly complete. It covers purpose, critical prerequisites, and risks, but lacks details on parameters, error cases, or authentication needs, which are important for a deletion tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It implies 'schedule_id' is used to identify the schedule to delete, matching the required parameter, but doesn't explain 'tenant_id' or provide any format details. The description adds minimal value beyond what the schema's property names suggest, failing to fully address the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and resource ('a schedule'), and distinguishes it from siblings like 'cdp_deactivate_schedule' by specifying it's a DELETE operation that removes the schedule entirely. It goes beyond a basic statement by mentioning the API endpoint pattern, which 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool versus alternatives: it instructs to first use 'cdp_invoke_workflow_action' with action='unschedule' to detach the schedule, and warns against using only the DELETE to avoid leaving dangling triggers. This directly addresses when to use this tool and what prerequisite steps are 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?
No annotations are provided, so the description carries the full burden. It discloses several behavioral traits: it's 'read-only' (safety profile), uses 'GET with query in URL' (implementation detail), is 'Suitable for short queries' (performance constraint), and 'Only SELECT statements are supported' (functional limitation). However, it doesn't mention other potential behaviors like error handling, timeout limits, or authentication requirements, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and well-structured: three sentences that each serve a distinct purpose (stating the core function, providing usage guidelines, and specifying constraints). There is zero wasted language, and key information is front-loaded. Every sentence earns its place by adding critical 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?
Given the tool's complexity (SQL execution), lack of annotations, and presence of an output schema, the description is reasonably complete. It covers the core functionality, usage constraints, and behavioral traits like read-only nature and method. The output schema likely handles return values, so the description doesn't need to explain those. However, it could benefit from mentioning authentication or error scenarios for full 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 description adds no specific information about parameters beyond what the input schema provides. With 0% schema description coverage, the description doesn't compensate by explaining what 'query' or 'tenant_id' mean, their formats, or examples. However, since there are only 2 parameters and one is optional with a default, the baseline is 3 as the description doesn't actively mislead but adds no 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 tool's purpose: 'Execute a read-only SQL query against the CDP data warehouse (Impala SQL) using GET with query in URL.' It specifies the action (execute), resource (SQL query against CDP data warehouse), technology (Impala SQL), and method (GET with query in URL). It also distinguishes from its sibling 'cdp_query_sql_post' by stating 'Suitable for short queries. For long queries, use cdp_query_sql_post instead.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidelines: 'Suitable for short queries. For long queries, use cdp_query_sql_post instead.' It clearly states when to use this tool (short queries) and when to use an alternative (long queries), and specifies 'Only SELECT statements are supported,' which further guides appropriate usage. This directly addresses 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behavioral traits: the two-step creation workflow, the rejection of shared messageDefs (error E0420), the optional folder placement behavior, and backend defaults. However, it doesn't mention potential side effects like permissions needed or rate limits, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with zero waste: the first sentence states the purpose, followed by workflow instructions, warnings, and parameter guidance. Each sentence adds critical information, and the text is appropriately front-loaded with the core action and recommended approach.
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 with 5 parameters, 0% schema coverage, no annotations, but with an output schema, the description provides strong context about the creation process, workflow, and parameter usage. It references external documentation for templates and enums, but doesn't explain what the output contains or address all parameters fully, leaving minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Given 0% schema description coverage and 5 parameters, the description adds substantial meaning beyond the bare schema. It explains the purpose of 'name' and 'description' in the initial call, clarifies that 'body' should be omitted initially, and details when to use 'folder_id' versus omitting it. It doesn't cover 'tenant_id' or provide format details, but compensates well for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Create a new campaign definition') and distinguishes it from sibling tools like 'cdp_update_campaign' by outlining a two-step workflow. It explicitly mentions what resources are involved (campaign with audience and messageDefs), making the purpose unambiguous and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool versus alternatives: it recommends a workflow where this tool is called with minimal parameters first, then 'cdp_update_campaign' for full configuration. It also specifies when NOT to use certain approaches (e.g., 'Do NOT reference an existing messageDef by resourceId') and references external documentation for templates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It effectively discloses that this is a mutation tool (e.g., 'schedule', 'publish', 'run') and provides context on parameter dependencies (e.g., 'Requires schedule_id' for schedule actions, 'Requires entity_type='connector' + entity_id' for publish). However, it lacks details on permissions, error handling, or side effects, which are important for a generic mutation tool with 8 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured: it starts with a clear purpose statement, immediately contrasts with a sibling tool, lists common verbs with bullet points for readability, and ends with a note on the 'body' parameter. Every sentence adds value, and there is no redundant or verbose 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 complexity (8 parameters, no annotations, but with an output schema), the description is largely complete: it explains the tool's role, usage guidelines, and parameter semantics. However, as a mutation tool with no annotations, it could benefit from more behavioral context (e.g., idempotency, side effects). The presence of an output schema mitigates the need to describe return values, but some gaps remain for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for 8 parameters, the description compensates excellently by explaining the semantics of key parameters: it clarifies that 'body' is an 'optional JSON string for workflows that need a payload,' and it ties parameters like 'schedule_id', 'entity_type', and 'entity_id' to specific actions (e.g., 'schedule' requires schedule_id, 'publish' requires entity_type and entity_id). This adds crucial meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'invoke[s] an arbitrary action on a workflow' and explicitly distinguishes it from sibling 'cdp_run_workflow' by noting this is a 'generic escape hatch for action verbs that cdp_run_workflow does not support.' It provides specific examples of common verbs (e.g., 'schedule', 'publish'), making the purpose highly specific and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool versus alternatives: it states to use this for actions not supported by 'cdp_run_workflow' (which only sends action=run) and mentions specific sibling tools ('cdp_activate_schedule', 'cdp_deactivate_schedule') as alternatives for certain actions. It also lists common use cases with required parameters, offering clear 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: it's a write operation ('Execute/run'), mentions a backend contract requirement (empty body to avoid 400 errors), and specifies parameter usage ('Set cohort=True for cohort campaigns'). However, it doesn't cover potential side effects, rate limits, or authentication needs, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and well-structured: three sentences that each serve a distinct purpose (purpose, parameter guidance, alternative tool). It's front-loaded with the core functionality and contains no wasted words, making it efficient for an agent 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 complexity (a campaign execution tool with 4 parameters, 0% schema coverage, no annotations, but with an output schema), the description is mostly complete. It covers purpose, usage, parameter semantics, and alternatives. The output schema exists, so return values don't need explanation. However, it lacks details on error conditions or side effects, which would be helpful for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds significant semantic value: explains that entity_id is 'the campaign def resourceId', clarifies cohort usage ('Set cohort=True for cohort campaigns'), and mentions that an empty body is automatically sent. This provides crucial context beyond the bare schema, fully compensating for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Execute/run a campaign immediately ('send now').' It specifies the verb ('execute/run'), resource ('campaign'), and timing ('immediately'), and distinguishes it from sibling tools by explicitly mentioning when to use cdp_publish_web_campaign instead for triggered/web campaigns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidelines: it states when to use this tool ('send now' campaigns) and when not to use it ('For triggered/web campaigns use cdp_publish_web_campaign instead'). It also mentions prerequisites ('Requires entity_id') and distinguishes it from alternatives, making it highly actionable.
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:

[![cdp-mcp MCP server](https://glama.ai/mcp/servers/atharva-joshi77/cdp-mcp/badges/card.svg)](https://glama.ai/mcp/servers/atharva-joshi77/cdp-mcp)

Score Badge

Copy to your README.md:

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

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