AdButler MCP Server
OfficialServer Quality Checklist
Latest release: v2.6.2
- Disambiguation2/5
With 622 tools, many share similar names across different resource types and API versions (e.g., vast_, vast42_, draft_ prefixes), causing confusion. Tools like serve_ad and get_ad, or list_all_campaigns and list_campaigns, have overlapping purposes that require careful reading of descriptions. The scale severely undermines the ability to reliably select the correct tool.
Naming Consistency3/5Most tools follow a verb_noun snake_case pattern with consistent prefixes for variants, but there are inconsistencies like list_report_schedule_generated vs list_report_generated, and some tools like serve_ad/setup_api_key fall outside the CRUD convention. The overall pattern is readable but not perfectly consistent.
Tool Count1/5622 tools is an extreme over-scoping for an MCP server, far exceeding the 15-tool calibration for 'well-scoped'. This creates a massive cognitive load for agents and makes selection inefficient and error-prone.
Completeness4/5The tool surface is extremely comprehensive, covering CRUD for most resource types (advertisers, campaigns, ad items, zones, creatives, placements, contracts, reports, targeting, user databases, etc.). Some minor gaps exist, such as missing update/delete operations for user databases and product catalogs, but the catch-all call_adbutler_api tool mitigates these.
Average 3.2/5 across 508 of 622 tools scored. Lowest: 1.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto the root of your repository:{ "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": [ "your-github-username" ] }Then . Browse examples.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits such as whether the update is partial or full, effects on unspecified fields, permission requirements, or response format. The one-line description discloses none of these.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief but severely under-specified. It conveys almost no useful information, making it a deficient placeholder rather than a concise, information-dense summary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (9 parameters, nested objects), and the absence of annotations or output schema, the description is critically incomplete. It fails to explain return values, error behavior, or any contextual details needed for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all 9 parameters, including the required 'id' and fields like 'name', 'location', 'metadata', etc. Since schema coverage is 100%, the description need not repeat parameter details, and the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an existing native ad item' is effectively a paraphrase of the tool name, providing no additional detail about the resource's fields or scope. It fails to distinguish from sibling tools like create_native_ad_item or draft_update_native_ad_item.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not indicate when to use this tool over create, delete, or draft update variants, nor does it mention any prerequisites or alternatives.
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 must disclose behavioral effects like irreversibility, cascading deletes, or return behavior. It only states the action without any additional context, leaving the agent unaware of consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is short, it is under-specified and merely repeats the tool name. It provides no added value and is better characterized as sparse rather than concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter delete operation, the description technically conveys the basic action, but it omits critical context like whether deletion is permanent, what errors can occur, and any dependencies. Given the lack of annotations and output schema, it is insufficient for an agent to confidently invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the single 'id' parameter with description 'Contact ID' (100% coverage). The tool description adds nothing beyond this, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a contact' is a direct restatement of the tool name 'delete_contact', providing no additional information about scope, type of contact, or distinguishing details from other delete operations. It is a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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, prerequisites, or alternatives. A simple declaration of the operation does not help the agent decide between this and similar delete tools.
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. It only states the action 'Delete' without explaining consequences, irreversibility, permissions required, or any side effects. It adds no behavioral context beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is a short single sentence, it is under-specified rather than appropriately concise. It simply restates the tool name and provides no structural detail or useful elaboration. This is more an example of under-specification, not conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with one parameter, the description is minimally adequate, but it leaves important gaps: it does not clarify what a 'native template' is, how this differs from the similarly named 'delete_ortb_native_template', or what the outcome of deletion is. The absence of an output schema makes this information even more necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'id' with a brief description 'Native template ID', giving 100% schema coverage. The tool description adds no additional semantics about the parameter, so the baseline of 3 applies since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a native template' is a direct restatement of the tool name 'delete_native_template', adding no new information. It is a tautology and does not differentiate this tool from similar siblings like 'delete_ortb_native_template'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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, no prerequisites, and no exclusions. The description provides no context about the deletion process or conditions under which this tool should be chosen.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it only restates the name. It discloses no behavioral traits such as read-only nature, data scope, pagination, or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single under-specified sentence. It is not concise but rather lacking in substance, providing no useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 optional parameters, no output schema, and multiple sibling report tools, the description is completely inadequate. It does not explain the report's purpose, filter behavior, or output format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all 6 parameters described, so the baseline is 3. The description adds no parameter context beyond the schema, but the schema already provides meaningful filter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get geographic summary report' restates the tool name without elaboration. It fails to clarify what a geographic summary report contains or how it differs from sibling report tools like get_vast_geo_summary_report or get_display_report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 gives no context about report scheduling, date ranges, or relationship to other report endpoints.
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 gives no behavioral details such as whether this is a read-only operation, what the report contains, whether it is generated asynchronously, or any side effects. The description carries the full burden and fails entirely.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than conciseness. A single sentence that merely restates the tool name does not 'earn its place' with informative value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a report tool with two parameters, no output schema, and no annotations, the description is completely inadequate. It does not explain what data the report returns, how preset/timezone affect results, or how to distinguish this from closely related reports.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage: 'preset' is described as 'Date preset' and 'timezone' as 'Timezone'. The description adds no additional meaning, but the schema baseline of 3 applies since parameters are already documented. No further compensation is warranted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get VAST auction placements report' is a near-verbatim restatement of the tool name. It names a verb and resource but adds no further distinguishing detail. Given many sibling report tools like get_vast_report and get_auction_placements_report, this fails to clarify what makes this report 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_vast_report or get_auction_placements_report. The description merely states the action without context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 does not state whether the operation is read-only, what the return format is, what 'platform estimate statistics' contains, or any side effects. The description simply restates the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
At one sentence, it is short, but it is under-specified rather than concise. The phrase 'Get VAST platform estimate statistics' is almost a tautology and does not earn its place by adding meaningful information beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two optional parameters, no output schema, and many similar sibling tools (e.g., get_vast_forecast, get_display_platform_estimate), the description is severely incomplete. It lacks any explanation of what the statistics represent, how to interpret output, or when this tool is the right choice.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: both 'preset' and 'timezone' have descriptions. The tool description adds no parameter-level detail, but the structured schema already provides the necessary field meanings, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Get') and identifies a resource ('VAST platform estimate statistics'), so the general purpose is understandable. However, 'statistics' is vague and does not specify what kind of estimate or how it differs from sibling tools like get_vast_forecast or get_display_platform_estimate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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 is no mention of context, prerequisites, or exclusions, leaving the agent to guess which of the many similar reporting/estimation tools is 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?
There are no annotations, so the description carries the full burden of behavioral disclosure. 'Create a VAST 4.2 resource' only states the verb and gives no details about side effects, required permissions, idempotency, failure modes, or return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is short but does not earn its place because it simply repeats the tool name. It is under-specified rather than appropriately concise, offering no useful information to the agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create operation with no annotations and no output schema, this description is severely incomplete. It does not define what a VAST 4.2 resource is, enumerate valid type values, explain the result, or provide any operational context, leaving the agent unable to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with descriptions 'Resource name' and 'Resource type', so the baseline is 3. However, the description adds no additional semantics beyond these highly generic labels, and valid values for 'type' remain completely unspecified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a VAST 4.2 resource' merely restates the tool name 'vast42_create_resource' with 'VAST 4.2' expanded. It fails to specify what a 'resource' is in this context or how it differs from the many other vast42_create_* sibling tools, making it essentially a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 numerous create_* sibling tools (e.g., vast42_create_creative, vast42_create_ad), there is no context, prerequisites, or exclusions to help the agent choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It only states 'Get' with no details about return values, required permissions, side effects, or report generation behavior. This is essentially a placeholder that reveals nothing beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief, but this is under-specification rather than conciseness. It is a fragment that fails to convey anything about the report's purpose, parameters, or behavior, so the text does not earn its place as a useful tool description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is drastically incomplete given the tool's context. It has optional parameters, no output schema, and many sibling forecast/report tools, yet it offers no information about the report's contents, how the forecast is generated, or any usage context. The agent cannot correctly select or invoke this tool based on this description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the two parameters ('Date preset' and 'Timezone'), so the schema already documents them. The description adds no extra meaning or usage nuance for these parameters, landing at the baseline of 3 for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get display forecast report' includes a verb ('Get') and a resource ('display forecast report'), but it does not clearly define what a display forecast is or how it differs from sibling tools like get_display_channel_forecast, get_placement_forecast, or get_vast_forecast. It is a vague purpose with no scope 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any context, prerequisites, or exclusionary conditions, leaving the agent without any decision support for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior on its own, but it only says 'List all VAST report data'. It does not mention that this is a read-only operation, whether pagination is applied (though limit/offset exist), what the response contains, or any filtering or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief, containing no wasted words, but it is under-specified to the point of being vague. Like the 'Process' example, this is not conciseness but insufficient content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, and the proliferation of similar report-related sibling tools (e.g., list_custom_reports, get_vast_custom_report, list_all_generated_reports), this description is wholly inadequate. It fails to clarify what 'VAST report data' means, what the tool returns, or how it differs from its siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents both parameters (limit and offset) with descriptions, covering 100% of schema properties. The description itself adds no extra parameter context, but the high schema coverage sets a baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'List all VAST report data' but does not clearly specify what is being listed—custom report definitions or the data within reports. The tool name 'list_vast_custom_reports' implies listing custom reports, but the description's noun phrase is ambiguous and does not distinguish this from the sibling 'list_custom_reports'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 instead of alternatives like 'list_custom_reports', 'get_vast_custom_report', or other report-related tools. The description lacks any context about use cases or exclusions.
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 responsibility for disclosing behavioral traits. It fails to mention whether deletion is permanent, reversible, scoped, or subject to permissions, which is critical for a destructive operation. The description adds no information beyond the action itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (one sentence) but under-specified. It merely restates the tool's name and provides no useful elaboration, making it closer to under-specification than effective conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations and no output schema, the description should clarify effects (permanence, return value, side effects) and distinguish from sibling schedule deletions. It does not, leaving the agent with insufficient context for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema documents the single 'id' parameter with description 'Schedule ID', achieving 100% schema description coverage. The description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a schedule' clearly states the verb and resource, but 'schedule' is ambiguous given multiple sibling tools like vast_delete_schedule, draft_delete_schedule, and delete_report_schedule. It does not differentiate which schedule type this tool targets, making it vague for an agent choosing between 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not specify context, prerequisites, or exclusions, leaving the agent to guess based on the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It merely states 'Update', which is already in the tool name, and provides no information about side effects, permissions, reversibility, or constraints (e.g., whether the recipient has already signed). This is essentially a non-disclosing tautology.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff. It is front-loaded with the verb and object. However, it is so minimal as to be almost tautological, but that is more a purpose issue than a conciseness issue; the structure itself is clean and quick to read.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters, no annotations, and no output schema, the description is insufficiently complete. It does not state that the tool updates the recipient's name/email, what the required IDs are for, or any preconditions or effects. The schema provides some parameter context, but overall the agent cannot fully understand the tool's purpose or usage flow from the available information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of the parameters with individual descriptions, so the baseline is 3. The tool description itself adds no parameter-level meaning beyond the schema. The optional 'name' and 'email' fields are self-explanatory in the schema, but the description does not clarify how they relate to the recipient update.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update a recipient for a signature request' is a near-verbatim restatement of the tool name 'update_signature_request_recipient'. It provides the verb and resource but adds no additional specificity, such as which recipient fields can be changed, and does not differentiate itself from sibling tools beyond what the name already implies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool, prerequisites, or conditions (e.g., whether the signature request must be in a particular state). It also does not mention alternatives like create_signature_request_recipient or delete_signature_request_recipient. The agent is left to infer usage entirely 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.
- 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 'Create' without describing side effects, required permissions, idempotency, or what happens after creation. The tool mutates state, but this is not explicitly disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. However, it is under-specified, lacking any contextual or behavioral details that would make it more helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters, no annotations, and no output schema, the description should explain what a linear media is, what the result of creation will be, and any constraints or relationships. It provides none of this, making it inadequate for a create operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all 4 parameters, so the schema already documents each parameter. The description adds no additional meaning beyond the schema, but the baseline for full schema coverage is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a VAST 4.2 linear media' identifies the verb (create) and resource (linear media), but it doesn't specify what a linear media is or how it differs from other VAST 4.2 tools like vast42_create_ad or vast42_create_creative. It also doesn't distinguish from the similar sibling vast_create_linear_media.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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 gives no context about prerequisites, relationships to other VAST resources, or situations where other tools should be 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?
With no annotations, the description carries full responsibility for behavioral disclosure. It states the action 'Delete' but does not mention whether deletion is permanent, whether it cascades, or whether special permissions are required. This is a significant gap 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and front-loaded, but it errs on the side of under-specification rather than conciseness. A single sentence can be efficient, yet this one misses opportunities to include behavioral context without adding bulk.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations, no output schema, and only one parameter, the description is insufficient. It does not explain the effects or return behavior, and the sibling set includes many delete_* tools that require clarification. More detail is needed for a complete description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the single 'id' parameter described as 'Platform target ID'. The description adds no parameter-specific meaning, but the schema already documents the parameter adequately, so the baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a platform target' is a direct restatement of the tool name, providing no additional context or differentiation from sibling delete tools such as delete_zone or delete_campaign. It identifies the verb and resource but fails to distinguish when this specific target type is meant.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 alternative delete tools or related platform target operations (list_platform_targets, create_platform_target, update_platform_target). The description offers no exclusions, prerequisites, or 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?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it offers none. It does not state whether unspecified optional fields are left unchanged or reset, whether specific permissions are required, or what happens upon update. This is a critical 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (one sentence) and front-loaded, but it is so minimal that it borders on under-specification. It does not add meaningful value beyond the tool name, so while it has no fluff, it also lacks substance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description must compensate by explaining update semantics, but it does not. It fails to mention behavior like partial vs full updates, return values, or error conditions. The schema covers parameters, but the overall context is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with each parameter well-described (e.g., 'If true, inclusion target; if false, exclusion target'). The description adds no extra parameter meaning, but the schema already handles this dimension, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an existing postal code target' clearly states the action (update) and resource (postal code target), but it is essentially a restatement of the tool name with no additional scope or distinction from siblings like create_postal_code_target. It does not specify what aspects can be updated or how it differs from other update tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives such as create_postal_code_target or delete_postal_code_target. The verb 'update' implies use for modifying existing targets, but there is no clear context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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. It only says 'Create a new contract' without mentioning side effects, required permissions, reversibility, idempotency, rate limits, or what happens on success/failure. For a mutation tool, 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.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and is not verbose, but it is under-specified for an 8-parameter tool. Conciseness is not the same as under-specification; this sentence provides the bare minimum and forces the agent to rely entirely on schema and sibling context. It earns its place but fails to add sufficient value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, no annotations, and 8 parameters, yet the description gives no context about return values, side effects, relationships to other contract operations, or what constitutes a valid contract. Among many contract-related siblings (list_contracts, get_contract, update_contract, create_contract_payment, etc.), this description does not aid in understanding the tool's role beyond the literal action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all 8 parameters, each with a clear description of its meaning (e.g., advertiser is 'Advertiser ID'). According to the calibration baseline, the description need not add parameter info when the schema is this complete. It adds no extra semantics but is not penalized because the schema already carries the burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new contract' clearly states the verb (create) and resource (contract). It is not a mere tautology of the name, and it distinguishes from siblings like create_contract_document or create_contract_template by naming the contract entity itself. However, it provides no additional scoping details, so it doesn't fully differentiate from all contract-related 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/5Does 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 update_contract, create_contract_document, or create_contract_template. There is no mention of prerequisites, typical use cases, or situations where a different tool should be chosen instead.
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. It merely restates the action without revealing any side effects, required permissions, validation rules, or what happens on success. The schema hints at default status and allowed networks but the description itself communicates nothing beyond 'creates something'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief, but it is under-specified rather than economically useful. It essentially restates the tool name and supplies no additional context, failing to earn its place as a valuable explanatory sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create operation with 7 parameters, 2 enums, and no output schema, this one-sentence description is inadequate. It does not explain what a demand source is, what constraints exist, what the expected response is, or how this tool fits into the broader workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter description coverage, so the schema already provides meaning for every field. The description adds no parameter-level insights beyond what is in the schema, thus the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new demand source' uses a clear verb+resource pattern, making the tool's function immediately obvious. It also distinguishes from related tools like update_demand_source, get_demand_source, and create_demand_endpoint by specifying the exact 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, such as whether an advertiser or publisher must exist first, nor any note about related operations like create_demand_endpoint. The description leaves the 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?
With no annotations, the description carries the full burden of behavioral disclosure. It simply says 'Create a new publisher' with no mention of side effects, permissions, required fields, or response behavior. This is a near-tautology and provides no actionable transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence with zero wasted words, but it is under-specified for a tool with 11 parameters and nested objects. It is concise in form but not appropriately sized in content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 11-parameter creation tool with no output schema, the description is drastically incomplete. It does not mention required fields, defaults, return values, or any contextual information needed to use the tool effectively, leaving the agent to rely solely on the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameter semantics are already well documented in the input schema (e.g., email allows login, domain top-level only). The description itself adds no parameter info, but the schema does the heavy lifting, justifying the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new publisher' clearly states the action and resource, distinguishing it from sibling create tools for other entities like create_advertiser. However, it does not explicitly differentiate from related publisher operations like update_publisher or archive_publisher, so it stops short of 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/5Does 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, what prerequisites exist, or how it relates to other publisher lifecycle tools. The description provides no context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 the action 'delete' without disclosing side effects, irreversibility, required permissions, or behavior on non-existent IDs. This is a significant gap for a mutation tool, as the agent has no information about the consequences or conditions of the operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence with no wasted words. It is appropriately sized for the tool's simplicity (single parameter, clear action). The information is front-loaded and immediately understandable. This is a model of conciseness, though it trades off richness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a delete tool with no annotations and no output schema, the description is too minimal to be considered contextually complete. It fails to provide any guidance on usage conditions, side effects, or how it fits with sibling tools. The agent lacks crucial context to safely invoke this destructive operation, such as knowing whether deletion is permanent or if there are dependencies that block deletion.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage—the single parameter 'id' is described as 'Ad item ID'. The tool description adds no parameter-level semantics beyond this. Since the schema fully documents the parameter, the baseline of 3 is appropriate; no additional credit is given for redundant information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a rich media ad item' is a direct restatement of the tool name. It provides no additional information beyond the name itself, making it tautological. While it does specify the resource type (rich media ad item), which distinguishes it from sibling delete tools for other ad item types, the description does not add anything beyond what the name already conveys.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 prerequisites, contexts, or exclusions. With many sibling tools for deleting other ad item types (e.g., delete_image_ad_item, delete_native_ad_item), the lack of even a minimal note such as 'for other ad item types, use the respective delete tool' leaves the agent without explicit usage direction.
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 for disclosing behavioral traits. It only says 'delete' which is already in the tool name; it doesn't disclose whether the operation is permanent, whether it only succeeds for draft items, or any side effects. Thus it earns a 1.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence with no unnecessary words, but it simply restates the tool name without adding new information. It's appropriately sized but not valuable, so it earns a 3.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple one-parameter delete operation, but the description lacks any note about return values, error conditions, or the meaning of 'draft' in this context. With no annotations or output schema, it leaves important contextual gaps, so it earns a 2.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema contains a single required parameter 'id' with a description 'Draft ad item ID', giving 100% coverage. The tool description adds no additional meaning beyond the schema, so it is at the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (delete) and the target resource (draft catalog ad item). However, it does not clarify how this differs from the non-draft 'delete_catalog_ad_item' or why one would use this over that, so it earns a 4 rather than 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the many sibling tools such as 'delete_catalog_ad_item' or 'draft_delete_campaign'. There is no mention of prerequisites, context, or exclusions, so it earns a 1.
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 responsibility for disclosing behavioral traits. It merely restates the tool name and offers no information about the report's contents, return format, read-only nature, or any side effects. This is effectively no disclosure beyond what the tool name already implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, but it is under-specified rather than concise. It fails to earn its place by adding any informative content beyond the tool name, making it closer to a placeholder than a useful description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has six optional parameters, no output schema, no annotations, and many sibling report tools. The description is completely inadequate for guiding an agent on how to invoke this tool correctly, what filters to apply, or what to expect in response. It provides no operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all six optional parameters, so the schema already documents their meaning. The description adds no additional parameter context, but since the schema is thorough, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Get') and resource ('conversion details report'), so its purpose is unambiguous. However, it does not distinguish this report from several sibling report tools like get_click_details_report or get_display_report, 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the many other report tools available. There is no mention of scenarios, prerequisites, or alternatives, so the agent receives no 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. It merely restates the tool's name without disclosing any behavioral traits such as read-only nature, required filters, or return format. This is effectively a tautology.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with no fluff. However, it is under-specified for a tool with optional parameters and no output schema, making it less useful than a concise description that includes key behavioral details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description should clarify what the report contains, how to use parameters, or what output to expect. It does none of this, leaving the tool functionally opaque for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the two parameters, but the schema only provides vague labels ('Date preset', 'Timezone'). The description adds no parameter information, so it does not exceed the baseline. It neither clarifies allowed preset values nor date formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and a resource 'display channel forecast report', making the tool's basic purpose clear. It distinguishes from siblings like get_display_forecast and get_vast_channel_forecast by the 'display channel' qualifier, though it does not explain what a 'channel' means in this context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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, and with many forecast-related siblings, it fails to help an agent choose correctly.
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 transparency. However, it merely restates the tool name without disclosing any behavioral traits such as permissions required, partial vs full update semantics, side effects, or return value. This is essentially no disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, but it is under-specified rather than efficiently concise. It essentially restates the tool name ('update_channel') and offers no additional substance, making it a minimal placeholder rather than a well-structured description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 3 parameters and no output schema, the description is incomplete. It fails to mention that id is required, whether only provided fields are updated, or any constraints or effects. The schema covers parameter mechanics but not the operational behavior, leaving gaps in contextual completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all three parameters (id, name, priority) with descriptions and an enum for priority, giving 100% schema description coverage. The tool description adds no additional parameter meaning, but the baseline of 3 applies since the schema sufficiently documents each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Update') and resource ('an existing channel'), which effectively communicates the tool's purpose. The word 'existing' adds a minor semantic distinction (it does not create channels), though it does not differentiate from sibling 'vast_update_channel' or other channel 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like create_channel, archive_channel, or vast_update_channel. It neither gives context for appropriate use nor excludes other tools, leaving the agent without decision-making 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?
With no annotations, the description carries the full burden of behavioral disclosure. It provides no information beyond the action itself, such as side effects, validation requirements, permissions, or what the response contains. This is essentially a restatement of the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (7 words) and front-loaded, but it is under-specified. It does not provide enough information for correct use. The single sentence is essentially a tautology of the tool name, lacking any useful expansion or structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create operation with no annotations and no output schema, this description is completely inadequate. It does not explain the domain context (e.g., what a 'VAST 4.2 companion' is), relationships to other entities, or any edge cases. The schema provides some param info but the description fails to give the full operational picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (name, width, height all have descriptions). The description adds no parameter details, but the schema already documents the parameters. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Create') and a specific resource ('a VAST 4.2 companion'). It is distinguishable from sibling tools like vast42_get_companion or vast42_update_companion because it is the create operation. However, it does not elaborate on what a VAST 4.2 companion is or how it differs from creating other entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 vs alternatives. No context about prerequisites (e.g., needing an existing ad or creative) or any other conditions. The usage is only implied by the name, but the description provides no explicit direction.
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 disclosing behavioral traits. It only states the action 'update' without indicating whether the update is partial (only supplied fields) or a full replacement, whether permissions are required, or any side effects. 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.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence, but it is under-specified rather than appropriately concise. It does not earn its place beyond repeating the tool name, and it omits essential usage and behavior details. This is closer to the 'Process' example in under-specification than to a well-packed single sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an update operation with no output schema, no annotations, and a simple schema, the description still fails to convey key behavioral context such as whether fields are optional, how partial updates work, or what the required 'id' implies. The description is not complete enough for an agent to safely invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of the parameters with descriptions, so the baseline is 3. The tool description adds no additional meaning about parameters beyond what the schema already states, and no extra context is needed for these straightforward fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update a VAST 4.2 mezzanine' clearly identifies the action (update) and the resource (VAST 4.2 mezzanine), distinguishing it from sibling tools like create, delete, or get mezzanine. However, it lacks any additional scope or elaboration beyond what the tool name already conveys, so it is clear but not richly informative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no context for partial vs. full updates. It is a bare statement with no practical usage direction, so an agent would have no cues about the appropriate circumstances for invoking this tool.
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 carry the full burden of behavioral disclosure. It only states 'Create a new VAST campaign,' which is a generic action and does not reveal whether the operation requires special permissions, whether it immediately persists or is staged, what side effects occur, or what the response contains. 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, making it concise and front-loaded. However, it is so minimal that it borders on tautology, restating the tool's name without adding meaningful detail. While there is no waste, the lack of content reduces its value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's context—three parameters, no output schema, no annotations, and a vast sibling set including create_campaign and draft_create_campaign—this description is far too sparse. It fails to explain return values, prerequisites, or how it differs from related creation tools, making it inadequate for an agent to reliably select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all three parameters (name, contract, advertiser) with 100% coverage, so the baseline is 3. The description adds no additional parameter semantics, but the schema adequately documents each parameter's meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new VAST campaign' uses a specific verb (Create) and resource (VAST campaign), and the 'VAST' prefix distinguishes it from generic campaign tools like create_campaign. However, it does not specify what a VAST campaign entails or how it differs from other VAST-related creation tools like vast_create_schedule or vast_create_ad_item.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as create_campaign, draft_create_campaign, or vast42_create_campaign. No prerequisites (e.g., advertiser must exist) or exclusions are mentioned, 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.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only says 'Create a new VAST non-linear media'. It does not mention side effects, idempotency, required relationships (e.g., to a campaign or ad), or what response to expect. This is a significant transparency gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is front-loaded with the primary action and object. While minimal, it is not a tautology and avoids unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is extremely sparse for a create operation with no output schema and no annotations. It fails to explain what 'non-linear media' is, what constraints or defaults apply, what the response contains, or how it relates to other VAST entities. An agent would have to infer most details from the schema and tool name.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for its four parameters (name, width, height, mime_type), so the schema carries the semantic load. The description adds no additional meaning to these parameters, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and the resource ('VAST non-linear media'), which distinguishes it from sibling tools like vast_list_non_linear_media or vast_update_non_linear_media. However, it does not elaborate on what non-linear media 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 Guidelines1/5Does 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 vast42_create_non_linear or vast_create_linear_media. There is no mention of prerequisites, use cases, or conditions that would make this tool the appropriate choice.
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 disclosing side effects, permanence, or permission requirements. It only says 'Delete' with no information about irreversibility, cascading effects on associated zones, or error behavior. This is a significant gap for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. However, it is so minimal that it essentially restates the tool name, offering little additional structure or value beyond brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a delete operation with no annotations and no output schema, the description is critically incomplete. It does not explain what happens to the channel (immediate deletion vs. soft delete), whether it can be recovered, if there are dependencies, or what the response contains. The tool's complexity and destructive nature demand far more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'id' with description 'VAST channel ID', providing 100% schema description coverage. The tool description adds no parameter information, but the schema already fully documents the only parameter, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a VAST channel' clearly states the action (delete) and the resource (VAST channel), distinguishing it from siblings like vast_delete_channel_zone_assignment and vast_delete_archived_channel. However, it adds no detail beyond the tool name, so it is clear but minimal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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 vast_archive_channel or delete_archived_channel. There is no mention of prerequisites, whether the channel must be active, or exclusion conditions, leaving the agent without 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 it only says 'replace all user data' without warning about irreversible data loss, required permissions, or what happens to existing data. It also doesn't disclose the upload mechanism or whether the operation is atomic.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence, front-loading the action and resource. It's efficient but lacks necessary details, yet as a structure it's appropriately short.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is insufficient for a complex destructive operation: no output schema, no annotations, and no details on the upload format or side effects. It leaves the agent to guess at the request structure and consequences.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema documents the 'id' parameter with description 'User database ID', so coverage is 100%. However, the description mentions 'bulk upload' but doesn't explain how the upload data is supplied, leaving a critical gap for a tool that presumably requires a data payload.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool performs a bulk upload to replace all user data in a user database, using the verb 'replace' and specifying the resource. However, it doesn't explicitly distinguish from sibling bulk upload tools like bulk_upload_replace_data_list, so it's clear but not fully differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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 over alternatives, nor any prerequisites or exclusions. There is no mention of specific scenarios or comparisons with sibling tools.
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. It only states 'Create a new custom HTML ad item', which adds nothing beyond the action itself. It does not mention permissions, validation, side effects, error behavior, or any operational nuances. This is a severe gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that directly states the action. It is front-loaded and contains no verbose or redundant words. It earns its place by providing a minimal purpose statement, though it is quite terse and almost paraphrases the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has 12 parameters, 2 required, enums, and nested objects, yet the description is only one sentence. There is no output schema or annotations to compensate. The description fails to provide any context about the ad item's structure, required fields, or how it relates to sibling ad item creation tools. It is fundamentally inadequate for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all 12 parameters, so the schema itself fully documents each parameter's meaning. The description adds no parameter-level details, but since coverage is high, the baseline of 3 is appropriate. The description does not clarify relationships between parameters or any special semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new custom HTML ad item', which includes a specific verb ('create') and resource ('custom HTML ad item'). It is unambiguous in its basic purpose. However, it does not distinguish itself from sibling tools like draft_create_custom_html_ad_item or other ad creation tools (create_image_ad_item), 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that this creates a published/custom HTML ad item as opposed to a draft, nor does it reference sibling tools like draft_create_custom_html_ad_item or other ad item creators. There is no context about prerequisites or suitable scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the full burden of behavioral disclosure. It simply restates the tool's function without revealing whether the deletion is permanent, what cascading effects occur, or what permissions are required, leaving the agent uninformed about the tool's actual behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no wasted words, but it is under-specified for a delete operation. It lacks essential context such as consequences and usage guidance, making the conciseness more indicative of incompleteness than effective brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a delete operation with a single parameter, but the description omits critical context about reversibility, downstream effects, and distinction from archiving. This makes it incomplete for an agent to safely and correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the only parameter 'id' with a description ('Advertiser ID'), so schema coverage is 100%. The description adds no additional meaning beyond what the schema already provides, and a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Delete' and the resource 'advertiser', making the core purpose unambiguous. It does not, however, distinguish this from related operations like archive_advertiser, 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/5Does 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 archive_advertiser or other deletion methods. There is no mention of prerequisites, soft-delete versus hard-delete, or any distinguishing conditions.
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 alone must disclose behavioral traits. 'Delete a bidder' merely restates the action and implies destructiveness but does not explain irreversibility, cascade effects, required permissions, or error conditions. This provides no information beyond the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (three words) and free of unnecessary content, but it is so under-specified that it lacks meaningful structure. While concise, it does not enrich the tool with contextual details that would justify a higher score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given it is a destructive operation with no annotations and no output schema, the description should at least mention the permanent nature of deletion or success/error behavior. 'Delete a bidder' is minimally complete for a trivial CRUD action but omits crucial contextual details about side effects, leaving the agent at risk of using it inadvertently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the single parameter `id` as 'Bidder ID', so schema coverage is 100%. The description adds no new parameter information, but since the schema is self-explanatory, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does 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 bidder'), using a specific verb that distinguishes it from sibling tools like get_bidder, update_bidder, and create_bidder. It is concise and unambiguous, though it lacks any additional scope or nuance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, prerequisites, or consequences. It simply states the action without mentioning that deletion is permanent or that it should only be used when a bidder is no longer needed, leaving the agent to infer appropriate usage.
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 for behavioral disclosure. It simply says 'Delete a data key' without explaining that deletion is likely permanent, what cascading effects may occur, or any error conditions. This is a significant transparency gap 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally short and direct, containing no wasted text. However, it merely restates the tool name and does not provide any additional value. It is not overly verbose, but it also fails to earn its place by adding context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a delete operation with one parameter, the description is too sparse. It does not disclose the permanent nature of deletion, potential impacts on related data (e.g., data key targets), or any special conditions. Given the absence of annotations, the description should provide more operational context to be complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the single parameter 'id' with the description 'Data key ID', so schema description coverage is 100%. The description itself does not add any parameter semantics, but the baseline for high schema coverage is 3, and the tool name plus schema are sufficient for identifying the parameter's role.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a data key' clearly states the action (delete) and the resource (data key), distinguishing it from sibling tools like create_data_key, get_data_key, and update_data_key. However, it lacks any additional details about scope or specific behavior, 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, consequences, or exclusions, and the only implied usage is for deleting a data key. 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.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and a terse description, there is no disclosure of behavioral traits such as authentication requirements, rate limits, or response format. The description merely restates the tool name, providing no additional value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise at four words, with no redundant content. It is front-loaded and easy to read, though the brevity sacrifices useful context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with six parameters and no output schema, this description is severely incomplete. It fails to explain what click details report means, the expected output, or how to interpret the results, making it inadequate for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes all six parameters with individual descriptions (100% coverage). The description adds no extra semantic meaning beyond what the schema already provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (Get) and resource (click details report), so it conveys what the tool does. However, it doesn't distinguish itself from sibling report tools like get_display_report or get_conversion_details_report, 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/5Does 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 instead of other report tools. There is no mention of context, prerequisites, or alternatives, 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?
With no annotations, the description carries the full burden of behavioral disclosure, but only states that it gets a report. It doesn't mention whether this is a read-only operation, what data is included, whether it supports filtering or aggregation, or any other behavioral traits. This is a significant gap for a tool with 12 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise, front-loaded sentence with no wasted words. It earns its place, though it could benefit from more detail given the tool's complexity; it is not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 12 parameters, many sibling report tools, and no output schema, this description is incomplete. It doesn't explain report types, filtering options, or what the response contains, leaving the agent without enough context to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with clear descriptions for all 12 parameters, so the schema already provides strong parameter semantics. The description itself adds no extra meaning, but the baseline of 3 is appropriate given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get VAST video advertising report' uses a specific verb and resource, and clarifies that it concerns VAST video advertising. However, it doesn't specify what kind of report (e.g., overview, breakdown by campaign) or what metrics it returns, making it only somewhat distinguishable from sibling report 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/5Does 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 alternative report tools like get_display_report, get_vast_forecast, or get_vast_geo_summary_report. The description gives no context for choosing this specific report.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'update an existing advertiser' without describing merge semantics, required ID, validation side effects, or return value. This is essentially a restatement of the tool name and provides no meaningful transparency beyond the fact of mutation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no fluff or repetition. It is front-loaded and easy to parse, though it is arguably too sparse to fully support agent use. Still, as a concise statement of purpose it earns a high score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 7 parameters, no annotations, and no output schema, this description is severely underspecified. It doesn't indicate partial vs. full update, required identifier, side effects, constraints, or return value, leaving the agent without sufficient context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All seven parameters have schema descriptions (100% coverage), so the schema does the heavy lifting. The description itself adds no parameter semantics, but the high schema coverage justifies the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (update) and resource (advertiser), and the word 'existing' distinguishes it from create_advertiser. However, it doesn't mention the scope or which fields can be updated, so it stops short of the explicit sibling differentiation seen in top-tier examples.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 create_advertiser, archive_advertiser, or other advertiser operations. The sentence merely restates the basic purpose with no context, exclusions, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It does not explain whether this is a partial update or full replacement, which fields are required beyond id, whether unspecified fields are preserved, or what the response contains. This is a bare mutation statement with no 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded with the verb and object, containing no filler. While under-specified, it is structurally efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex 16-parameter mutation tool with no annotations and no output schema, yet the description provides only a five-word statement. It omits usage context, behavioral semantics, and any practical guidance, making it inadequate for successful invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides full (100%) descriptions for all 16 parameters, so the description doesn't need to explain them. However, the description adds no semantic information beyond the schema, such as which parameters are commonly updated together or how update behavior applies. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (update) and resource (demand endpoint), and the word 'existing' distinguishes it from creation. It doesn't elaborate on updatable fields or differentiate from sibling update tools, but the core 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/5Does 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 get_demand_endpoint, create_demand_endpoint, or delete_demand_endpoint. The description only states the action, leaving the agent to infer usage context 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?
With no annotations, the description carries the full burden of behavioral disclosure, but it only restates the tool's name (a tautology). It fails to mention side effects, how partial updates work, permission requirements, or error handling for a mutation tool, which 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no filler language. While it lacks richness, it is appropriately concise and front-loaded, containing the core action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters, nested objects, no output schema), the one-sentence description is severely inadequate. It does not explain return values, update semantics (merge vs. replace), or any constraints, leaving the agent without essential operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides complete descriptions for all 9 parameters, including types, enums, and nested object structures. The description itself adds no parameter-level information, but the schema's 100% coverage ensures parameters are sufficiently self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Update') and the resource ('existing email zone'), distinguishing it from create/delete email zone tools. It also differentiates from the generic 'update_zone' by specifying 'email', though it doesn't explicitly state that this is for email zones only.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives like update_zone or vast_update_zone. It doesn't state any prerequisites, exclusions, or scenarios where this tool is preferred, leaving the agent without clear selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'Update an existing manager' and omits critical traits such as whether it performs a partial update, requires all fields, what authentication is needed, or what response to expect. This is essentially a tautology of the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words, stating the core action directly. It is appropriately front-loaded, though it is so minimal that it provides little beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high complexity (25 parameters), absence of annotations, and no output schema, this one-sentence description is severely inadequate. It doesn't explain update semantics, permission requirements, behavior of omitted fields, or return values, making it insufficient for an AI agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 25 parameters, including types, enums, and per-field explanations. The description adds no parameter semantics, but the schema already handles this, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb 'Update' and resource 'an existing manager', distinguishing itself from sibling tools like create_manager, get_manager, list_managers, and delete_manager by conveying the specific action. It lacks detail about what aspects can be updated, 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like create_manager, nor are any prerequisites mentioned (e.g., the manager must already exist). The description gives no context for distinguishing update scenarios from create or delete scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it merely says 'Update' without explaining the extent of changes, whether it is a partial or full replacement, or any side effects (e.g., overwriting recipients). This leaves the agent with no insight into the operation's impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded with the verb, but it is under-specified rather than efficiently concise. It contains no additional useful information to justify its place, though it is not verbose or poorly structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and minimal description, the tool is not adequately contextualized. The schema lists parameters but does not convey overall behavior, preconditions, or consequences of updating a report schedule, leaving an agent without a complete picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for all four parameters (100% coverage), so the baseline is 3. The description adds no further meaning about parameter relationships or the necessity of the required identifiers beyond what the schema states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does 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 (a report schedule), making its primary purpose understandable. However, it does not differentiate from sibling tools like 'update_schedule' or provide details on which aspects of the schedule can be changed, so it is not fully 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus create or delete report schedules, or how it relates to other update operations. There are no prerequisites, context, or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden of behavioral disclosure. 'Create' implies a write operation, but no details are given about side effects, validation, required relationships, or what the response might be. This is minimal and non-transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, succinct sentence that front-loads the verb and resource. It is compact and easy to parse, though it is too sparse to convey critical contextual details, so it earns a 4 rather than 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create operation with no annotations, no output schema, and only two generic parameters, the description is severely incomplete. It does not explain what a mezzanine is, whether a parent VAST asset is required, or what the operation returns, making it inadequate for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters, both with descriptions ('Mezzanine name' and 'MIME type'). The description adds no additional meaning beyond the schema, but the baseline of 3 is appropriate because the schema is self-sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and the resource ('VAST 4.2 mezzanine'). It distinguishes this from the many other create tools by specifying the exact resource type and version, and is unambiguous about 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 Guidelines1/5Does 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, such as vast42_update_mezzanine or vast42_list_mezzanines. There is no mention of prerequisites, context, or scenarios where this operation is 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 must disclose behavioral traits. It only states 'create,' implying mutation, but omits any details about side effects, required advertisement specifics beyond the schema, return values, or authorization. This is severely inadequate 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no fluff, front-loading the verb and resource. It is concise but arguably too terse for the tool's complexity, though it does not waste words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex create operation with a nested advertisement object, 6 parameters, no output schema, and no annotations. The one-sentence description does not explain what a placement is, how the nested object should be semantically structured, or what happens on creation, leaving major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 100% of parameters, including the nested advertisement object, so the baseline is 3. The description itself adds no parameter semantics, but the schema carries the burden effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and the specific resource ('a VAST 4.2 placement'). The VAST version differentiates it from the many sibling placement-creation tools, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives like vast_create_placement, create_placement, or draft_create_placement. There is no mention of prerequisites, suitable contexts, or exclusions.
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?
The description merely restates the operation implied by the tool name ("Delete a VAST zone") and provides no additional behavioral context such as irreversibility, cascading effects on associated data, or required permissions. With no annotations provided, the description completely fails to disclose these important traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief and front-loaded, with no wasted words. However, it is under-specified for a destructive operation and misses caveats, so while concise, it is not appropriately sized for the information needed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple schema and no output schema, the description at least identifies the target entity, but it lacks essential context about the deletion's impact, the difference between deleting and archiving, and any steps required before deletion. The sibling tools show related operations, yet the description does not connect to them.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for the single parameter 'id' ("VAST zone ID"), so the baseline is 3. The description adds no extra meaning beyond the schema, but the schema already sufficiently documents the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does 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 (VAST zone), making it a specific verb+resource pairing. However, it does not differentiate from siblings like vast_delete_archived_zone or vast_archive_zone, and does not clarify scope (e.g., active vs archived zones).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 vast_archive_zone or vast_delete_archived_zone. There are no prerequisites, no warnings about required prior archiving, and no mention of conditions under which deletion is allowed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. 'Create a new catalog ad item' only restates the action and provides no information about side effects, whether the item is immediately live, or any approval requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no extraneous words, making it concise. However, it is under-specified, lacking detail that would be helpful for an agent to use the tool effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create operation with 7 parameters and no output schema, this minimal description is incomplete. It does not explain what a catalog ad item is, how it relates to a product catalog, or what the expected outcome is beyond creation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond the schema's parameter definitions, which already describe each field.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Create a new catalog ad item', which uses a specific verb and resource. However, it does not distinguish this from the sibling draft_create_catalog_ad_item or campaign_bulk_create_catalog_ad_items, so it is clear but not fully differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 draft or bulk creation alternatives. The description lacks any context about prerequisites, sequencing, or scenarios where this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. Beyond the action 'Create', it reveals nothing: no permission requirements, side effects, reversibility, relationship to other entities, or response format. The phrase 'for product/retail ad serving' is purposive, not behavioral. This is essentially a tautology of the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence with no redundant words. It is front-loaded with the action and resource, and the purpose qualifier is concise. There is no filler or repetitive content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, no output schema, no annotations), the description is too minimal. It does not explain what the response contains (e.g., created zone ID), any required prior steps, or how catalog zones relate to other entities. The schema covers parameters but not the overall operational context. The description fails to provide enough context for an agent to confidently use the tool without additional discovery.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all 10 parameters, including enums and ranges. The description adds no parameter-specific meaning, but the schema already documents each parameter sufficiently. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and the resource ('catalog zone') with the specific context ('for product/retail ad serving'). It is distinct from generic 'create_zone' or 'vast_create_zone' by naming 'catalog zone', though it does not explicitly differentiate among sibling zone creation tools. Clear and specific but not fully distinguished from 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not mention prerequisites, such as requiring an existing catalog_id, or any scenarios where this tool is preferred over other zone creation tools. The description simply states what the tool does 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.
- 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. 'Create a new contact' simply restates the tool name and provides no behavioral information such as idempotency, response format, or uniqueness requirements. It adds no transparency beyond the obvious 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. However, it is so terse that it borders on under-specification, which slightly reduces its effectiveness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create operation with no annotations and no output schema, the description is inadequate. It does not explain when to use the tool, what happens on creation, or any side effects. The schema covers parameters but cannot compensate for missing interaction context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with meaningful descriptions for all three parameters. The description itself adds no parameter details, but the schema fully compensates, making the baseline score appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'create' and names the resource 'contact', clearly identifying the operation. It does not differentiate itself from other create tools, but the resource name is unique 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. Sibling tools like update_contact, delete_contact, and get_contact suggest related operations, but the description does not mention them or provide any context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits, but it only says 'Create a new report configuration'. It does not explain whether this triggers report generation, how it relates to scheduled reports, what the persisted configuration looks like, or any side effects or permissions needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. However, for a tool with 10 parameters and nested objects, this brevity borders on under-specification rather than effective conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, nested objects, no output schema, no annotations), the one-sentence description is woefully incomplete. It fails to explain return values, execution behavior, naming conventions, or the difference between creating a report configuration versus generating a report.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all parameters, including nested fields like 'date'. The description itself adds no parameter semantics beyond what the schema already provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does 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 'report configuration', which conveys the core purpose. However, it does not distinguish this from the sibling tool 'create_vast_custom_report' or clarify whether this is for display reports versus VAST reports.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'create_report_schedule' or 'create_vast_custom_report'. The description only states the action, leaving the agent to infer usage context from the name.
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 responsibility for disclosing side effects. It only says 'Create a new media group' with no mention of permissions, uniqueness constraints, return values, or any mutability implications, leaving the agent without 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, making it very concise and front-loaded. It wastes no words, though the extreme brevity provides limited added value beyond the tool name, stopping just short of under-specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create operation with no annotations and no output schema, the description does not explain expected outcomes, response format, or any constraints beyond a single parameter. The tool is simple, but the lack of context about what happens after creation makes 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.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'name', which is described as 'Media group name'. The tool description does not add any parameter-level detail, but the schema already fully documents the only parameter, meeting the high coverage baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create) and the resource (media group), making the purpose unambiguous. However, it is essentially a restatement of the tool name and does not explicitly differentiate from sibling CRUD operations like update_media_group or delete_media_group.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, no prerequisites, and no context about media groups. The description simply states the action without any usage conditions or exclusions.
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?
The description is a tautology of the tool name, adding no behavioral details such as permanence, side effects, or required permissions. With no annotations provided, the description fails to convey anything beyond the action itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The one-sentence description is brief but redundant, essentially restating the tool name. It lacks structure and doesn't earn its place by adding information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool, the description is minimal but still missing important context like whether deletion is permanent, cascades to references, or has any restrictions. No annotations or output schema compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes the single 'id' parameter with a description, so baseline is 3. The description adds no parameter semantics or usage details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Delete' and names the resource 'audio creative', clearly distinguishing it from sibling delete tools for other creative types (e.g., delete_video_creative, delete_rich_media_creative).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 that audio creatives are a specific type, nor does it reference the generic delete_creative tool or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the only source of behavioral information. It merely states the action without disclosing whether the deletion is permanent, if it can be undone, any cascading effects, or permissions required. This is a significant gap for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence with no wasted words, but it adds little beyond the tool name, making it borderline redundant. It is concise but not informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive delete tool with no annotations and no output schema, the description is incomplete. It fails to mention the effect on related data, whether there is an undo option, or how it differs from 'archive_contract' and 'delete_archived_contract'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the single 'id' parameter with description 'Contract ID'. The tool description adds no additional meaning to the parameter, so it remains at baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a contract' clearly states the action and resource. However, it does not distinguish between deleting an active contract versus an archived one, despite the sibling existence of 'delete_archived_contract'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool over alternatives such as 'archive_contract' or 'delete_archived_contract'. The description gives no context about prerequisites, restrictions, or when deletion is 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. It only states 'Delete a contract document' and fails to mention whether deletion is permanent, reversible, cascading, or has any side effects on related records. For a destructive operation, this is a critical gap with zero added 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler words, making it concise and front-loaded. It could include more context (e.g., consequences) without losing conciseness, but it is efficiently stated and not padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description must supply complete context. It merely states the action and omits return values, error behavior, side effects, and the permanence of deletion. For a destructive tool, this is an incomplete and under-specified description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with clear descriptions (id is Document ID, contract_id is Contract ID), so the baseline is 3. The description adds no additional parameter semantics, such as the relationship between the two IDs or any constraints beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does 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 contract document'), which is a specific and distinct resource. However, it does not provide any scope or explicitly differentiate from sibling tools like update_contract_document or replace_contract_document_file, though the name and resource are sufficiently clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, no exclusions, and no mention of scenarios where deletion is appropriate or inappropriate. It is a bare statement of action with no 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 must disclose behavioral traits. It simply says 'Delete' without mentioning whether the deletion is permanent, requires special permissions, or has cascading effects, offering no extra 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, grammatically complete sentence with no unnecessary words or repetition, making it very concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation, the description is minimal and omits important context such as the distinction between draft and live ad items, the permanence of the action, or any prerequisites. It is barely sufficient for such a tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the id parameter with 'Ad item ID', and since the description adds no parameter details, it relies on the high schema coverage. This meets the baseline for acceptable parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Delete' and names the resource 'custom HTML ad item', clearly indicating the tool's function and distinguishing it from deletion tools for other item types. However, it doesn't clarify that this operates on the live (non-draft) version, leaving potential ambiguity with draft_delete_custom_html_ad_item.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 draft_delete_custom_html_ad_item or other delete_* tools. It lacks any contextual information to help the agent choose 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only restates the action from the tool name and omits any details about permanence, side effects, permissions, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler, making it appropriately concise. However, it is under-specified in content, which slightly reduces the score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal and lacks essential context for a deletion tool, such as irreversibility, prerequisites, or consequences. Given no annotations and no output schema, more detail is expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the only parameter (id) with a description, so the baseline is 3. The tool description adds no additional parameter meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Delete') and names the exact resource ('trusted redirect domain'), clearly distinguishing it from sibling CRUD tools such as create, get, update, and 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/5Does 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, no exclusions, and no mention of alternatives. It is purely declarative with no use-case 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 disclosing behavior. It only paraphrases the tool name ('Download a file revision'), offering no details about the response format (e.g., binary content), whether this is a read-only operation, or any side effects. This is insufficient for an agent to understand 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.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but essentially restates the tool name without adding new information. It fails to earn its place because it provides no elaboration or context, making it under-specified rather than concise in a valuable way.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a download operation with no output schema and no annotations, yet the description does not explain what the tool returns, how the file is delivered, or how it differs from related tools. The description is far too minimal for an agent to confidently invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides descriptions for all three parameters ('Contract ID', 'Document ID', 'File revision ID'), achieving 100% coverage. The description adds no additional parameter semantics beyond what the schema already provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Download') and the resource ('a file revision for a contract document'), using a specific verb and resource. However, it does not distinguish this tool from its sibling 'get_contract_document_file_revision', which likely serves a similar retrieval purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 'get_contract_document_file_revision' or 'list_contract_document_file_revisions'. The description lacks context about the difference between downloading a file revision and getting revision metadata.
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 responsibility for behavioral disclosure. It only states the action, omitting any details about permissions, side effects, validation, or return values for this 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words, making it concise and front-loaded. It is slightly over-terse for the information needed, but structurally adequate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a nested object parameter and no output schema, the description does not explain what fields the draft object should contain, any prerequisites (e.g., existing campaign draft), or what the tool returns. This is a significant gap for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% as both parameters (campaign_draft_id and draft) have descriptions. The description adds no further parameter meaning beyond what the schema already provides, so the baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is specific and clear: 'Create a new draft placement' names the verb (create) and the resource (draft placement), making it easily distinguishable from siblings like draft_update_placement or draft_list_placements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as create_placement or draft_update_placement. There is no mention of workflow, prerequisites, or exclusions.
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 carry the full burden of disclosing behavior, but it only restates the tool's purpose. It does not mention return format, errors, permissions, whether it is read-only (though 'get' implies it), or any draft-specific semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the core action and object with no wasteful words. It is appropriately concise for a simple get-by-ID tool, though it sacrifices depth elsewhere.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, this description is too thin to fully inform an agent about the return value, draft vs. published implications, or how to distinguish this from the many sibling draft_* tools. It is minimally adequate for a fetch operation but leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single 'id' parameter described as 'Draft ad item ID'. The description's 'specific' adds minimal interpretive value but does not add syntax, format, or context beyond what the schema already provides, matching the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get details of a specific draft native ad item' clearly states the verb (get), resource (draft native ad item), and scope (specific, implying by ID). It distinguishes from list operations and from non-draft get_native_ad_item by including 'draft', although it does not explicitly contrast with sibling draft_get_ad_item or draft_get_image_ad_item.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as draft_list_native_ad_items for listing or get_native_ad_item for published items. There are no prerequisites, exclusions, or context about draft vs. live behavior.
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 simply restates the tool's name without detailing any behavioral aspects such as whether it is read-only, what data it returns, or how the preset and timezone parameters affect the forecast. It offers no added context beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff. It is front-loaded and short, but it is also minimal, providing only the essential phrasing without any extra contextual structure. This earns it a strong but not top score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 2 parameters, no annotations, and no output schema, the description does not provide enough context. It fails to explain what the placement forecast report contains, how to use the preset/timezone, or what the response looks like, making it inadequate for an AI agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers both parameters (preset and timezone) with brief descriptions. The tool description does not add any semantic detail about the parameters, so it relies entirely on the schema. Given 100% schema coverage, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('placement forecast report'), making the core action clear. However, it does not distinguish this from sibling forecast tools like get_display_forecast or get_vast_forecast, so it lacks differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, what type of placement forecast it produces, or how it compares to other forecast/report tools. No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It merely repeats the tool's purpose and adds no information about pagination, whether archived/draft items are included, required permissions, or the nature of 'all'. The word 'all' is ambiguous given the presence of limit/offset parameters in the schema, and no side effects are mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no wasted words, achieving high conciseness. However, it is arguably under-specified for a tool with pagination and many siblings, so it is not a perfect 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only two well-documented parameters, but the description fails to provide sufficient context for an agent to understand when to choose this tool over list_ad_items or draft_list_image_ad_items. It also does not explain what an 'image ad item' is or what the response contains, leaving the description incomplete for effective selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the two parameters (limit and offset), so the baseline is 3. The description's phrase 'all' hints at unbounded listing but does not add any meaningful detail beyond the schema's own parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all image ad items' clearly specifies the action (list) and the resource (image ad items), distinguishing it from sibling tools for other ad item types. However, it adds little beyond the tool name itself and does not clarify the intended scope (e.g., all items across all advertisers or within a 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no exclusions, and no mention of related tools like draft_list_image_ad_items for draft versions. It is a bare functional statement with zero 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 the full burden of behavioral disclosure. It only says 'Replace' without explaining whether this is destructive, whether it requires specific permissions, what happens to the old file, or how the new file is supplied. Given only an 'id' parameter, the mechanism for providing the replacement file is completely undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant wording. However, its brevity borders on under-specification, especially given the lack of clarity about the file-supply mechanism, so it loses a point for not including essential context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameter, no output schema, and no annotations, so the description must explain enough for an agent to invoke it correctly. It fails to explain how the new file is passed, what constraints exist, or what the response contains. An agent would be unable to correctly use this tool without additional information from documentation or examples.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage with 'id' described as 'Creative ID', but the description adds no additional meaning. Notably, there is no parameter for the replacement file itself, which is confusing. The description should clarify how the new file is provided (e.g., via multipart upload or a URL), but it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Replace') and the target resource ('the file on a rich media creative'), which distinguishes it from sibling tools like replace_image_creative_file. However, it could be more specific about which file on the rich media creative is being replaced (e.g., the primary asset), leaving slight ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There are many similar replace_*_file tools for different creative types (image, video, audio), but the description does not mention these alternatives or any prerequisites for use.
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 available, the description carries the full burden of behavioral disclosure. It fails to mention whether the update is partial or full, what happens to omitted fields, whether specific permissions are required, or what the response contains—thus providing no transparency beyond the bare minimum.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no filler or redundant information. It is appropriately sized for the tool's simple purpose, earning full marks for brevity and efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having only 5 parameters and no output schema, the tool's behavior is underspecified. It does not clarify whether updates are partial, how required identifiers are used, or what the response looks like, leaving critical assumptions unstated for an agent invoking this mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% description coverage for all 5 parameters, so the schema already documents each parameter's meaning. The description adds no additional semantic nuance, which aligns with the baseline score of 3 for fully covered schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does 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 (product source), making the tool's purpose unambiguous. However, it does not distinguish this from sibling update tools like update_product_source_target, relying on the tool name for that 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It simply states the action without context on prerequisites, scenarios, or exclusions, leaving the agent without decision-support 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?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only states the action 'Update' without explaining consequences, constraints, or side effects. This leaves the agent completely in the dark about what the update entails.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no redundant words, which is efficient and well-structured. However, it is so minimal that it omits useful context, preventing a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description is incomplete. It does not explain what fields can be updated, the effect of the update, or any state requirements, making it insufficient for an agent to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for both parameters (id and contract_id), so the schema itself already explains the parameters. The description adds no additional semantic information, placing it at the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Update') and resource ('signature request'), making the primary purpose explicit. However, it does not explicitly differentiate from sibling tools like update_signature_request_recipient or cancel_signature_request, so it falls short of 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/5Does 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 any context about prerequisites, state requirements, or scenarios where create, cancel, or resend would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 for behavioral disclosure. It merely says 'validate' without explaining side effects, return values, error handling, or whether validation is performed locally or against a server. This leaves a significant gap 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with zero redundancy, making it highly concise and front-loaded. While extremely brief, it is not wordy and the structure is straightforward, which is appropriate for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the simple schema, the description is incomplete for a validation tool. It does not indicate what validation entails, what the output is, or any error or prerequisite conditions. With no annotations and no output schema, the description should provide more context to be considered complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the 'key' parameter as 'Beacon signing key to validate' with 100% coverage. The tool description adds no additional semantic value beyond this; it simply names the action. Baseline 3 is appropriate when schema covers all parameters without needing further description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('validate') and resource ('beacon signing key'), which clearly distinguishes it from sibling CRUD operations like get_beacon_signing_key and create_beacon_signing_key. However, it does not specify what 'validate' means (e.g., format check, server-side verification), so it is clear but not fully precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 any context for validation or differentiate it from get_beacon_signing_key, list_beacon_signing_keys, or other related tools, leaving the agent without explicit 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 disclosing behavioral traits. It only says 'Create,' which implies mutation, but it does not mention side effects, required permissions, whether the creative is immediately active, or what the response contains. This is a significant transparency gap for a state-changing operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is front-loaded and has no waste, but it is under-specified to the point of being a tautology of the tool name. It does not add meaningful information beyond restating what the name implies, so it is not appropriately sized for the task.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should explain what the creation returns and any contextual details. It fails to do so. For a simple create tool with only two optional parameters, the description is somewhat usable but leaves critical context (e.g., return value, parent relationships) unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, with both 'name' and 'description' parameters having basic descriptions. The tool description adds no additional parameter context, but the baseline of 3 is appropriate since the schema already documents the parameters adequately, albeit minimally.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does 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 ('a VAST 4.2 creative'), making the basic purpose clear. However, it does not differentiate this tool from the many sibling create operations (e.g., vast42_create_ad, vast42_create_linear, create_video_creative), so it lacks the specificity needed to distinguish it from 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/5Does 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 is no mention of prerequisites, typical use cases, or exclusions. Given the large sibling list, this absence leaves the agent without context for choosing this tool over other create operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of explaining behavioral traits. It simply says 'Update' with no details on partial versus full replacement, idempotency, response behavior, or side effects. This is a critical gap for a mutation operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary filler. It is appropriately front-loaded with the action and resource, achieving maximum efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter update tool with no output schema and no annotations, this description is incomplete. It lacks critical information such as update semantics (partial vs full), the meaning of leaving fields unset, and what response the agent can expect. The schema provides parameter names but not operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The tool description adds no extra meaning to the parameters beyond what the schema already provides (e.g., active, ad_item, campaign). It doesn't clarify update semantics for which fields are optional or how they interact.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Update' and the resource 'VAST 4.2 campaign assignment', making it easy to identify what the tool does. It is distinct from sibling operations like create/get/delete based on the verb, though it doesn't explicitly contrast with 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/5Does 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 create/get/delete, or any prerequisites such as requiring an existing assignment. The description offers no context for when an update is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It merely restates the tool name with no information about partial update semantics, side effects, permissions, or error behavior, which is especially 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no redundant words and is front-loaded with the action and resource. It is appropriately concise for a simple update operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description leaves important context unaddressed, such as whether omitted fields are preserved, whether the id is required for lookup, and what the effect of the update is. The schema covers field meanings, but the description fails to provide operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, documenting all four parameters with descriptions. The description itself adds no parameter-level meaning beyond the schema, so it meets the baseline but does not enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does 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 ('VAST 4.2 icon'), which distinguishes it from sibling tools like vast42_create_icon or vast42_delete_icon. However, it doesn't enumerate which fields can be updated or any additional scope 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/5Does 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 vast42_create_icon or vast42_update_placement. The only implicit signal is the verb 'update,' with no explicit prerequisites, conditions, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the sole source of behavioral disclosure, but it only restates the action 'Delete' without any detail about permanence, cascading effects, permissions, or error behavior. This adds no value beyond the tool name itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words. It is appropriately sized for a simple delete operation, though it is terse and lacks broader context. It does not waste space, earning a high score on conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It does not explain whether the deletion is permanent, what happens on errors, or any dependencies or side effects. The low complexity and single parameter limit the need for extensive context, but the description is still too minimal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the parameter 'id' described as 'VAST linear media ID'. The tool description adds no additional parameter meaning, so the baseline score of 3 is appropriate since the schema already documents the parameter sufficiently.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and the specific resource ('VAST linear media'), which distinguishes it from sibling tools like vast_delete_non_linear_media. However, it lacks additional context such as the scope or implications of deletion, making it slightly below a top 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention that this is for linear media specifically, nor does it explain when to prefer this over vast42_delete_linear or other related delete operations. There is no exclusions or context about 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 behavioral burden. It only says 'get details', implying a read operation, but does not disclose any side effects, permission requirements, or error behavior (e.g., if the ID does not exist). No meaningful behavioral context is added beyond what the tool name already implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundancy or filler. It communicates the core operation efficiently, making it concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID tool, the description is adequate in some respects, but it critically lacks disambiguation between the vast_ and vast42_ tool families. This omission could lead an agent to invoke the wrong endpoint. While no output schema exists, the description should still clarify the VAST version and relationship to siblings, which it does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for the single 'id' parameter, which is documented as 'VAST companion ID'. The description adds no further explanation of the parameter or its format, but with full schema coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool gets details of a VAST companion, which is a clear verb+resource. However, it fails to distinguish from the similarly named sibling tool vast42_get_companion; 'VAST companion' could refer to either the VAST or VAST42 resource family. This ambiguity makes it less effective for agent selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 vast42_get_companion or vast_list_companions. It does not mention that the 'id' parameter is required, nor any preconditions or version-specific 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, but it only repeats the tool name. It does not mention side effects, required permissions, or consequences of creating a manager (e.g., sending an email, creating a login).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with no wasted words, but it is under-specified. It essentially restates the tool name without adding contextual structure, which limits its usefulness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 24 parameters and no output schema, the description is far too minimal to provide adequate context. It fails to clarify what a manager is in this system, when to use it, or what the result of creation implies.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all 24 parameters, so the baseline is 3. The tool description adds no parameter-specific meaning, but the schema adequately documents each field's purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Create' and a resource 'manager', clearly indicating the tool creates a manager. However, it does not differentiate from other create tools like create_user or create_bidder, 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/5Does 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. It does not mention prerequisites, exclusions, or scenarios where a different tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It merely restates the tool's name ('Delete a contract payment') without revealing side effects, irreversibility, error behavior, or permission requirements—essentially a tautology.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (four words) and front-loaded, but it is under-specified, lacking any structured context. While it has no fluff, its brevity borders on incompleteness, earning a mid-range score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the delete operation, no annotations, and no output schema, the description does not explain what a contract payment is, whether deletion is hard or soft, or any dependency on contract_id. The tool is simple, but the description fails to provide essential contextual details for an agent to invoke it safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers both parameters (id and contract_id) with descriptions, achieving 100% schema_description_coverage. The description adds no additional parameter meaning beyond what the schema already provides, but the baseline of 3 is appropriate because the schema handles the semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 contract payment'), using a specific verb+resource pattern. It distinguishes from sibling tools like create_contract_payment, get_contract_payment, and list_contract_payments by explicitly indicating the delete operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any prerequisites or conditions. The description does not mention whether contract_id is required for scoping, or any 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, the description carries the full burden of behavioral disclosure. It only states 'Delete a native ad item' without mentioning permanence, side effects on related entities (e.g., zone associations), required permissions, or whether it can be undone. This is a significant gap 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no wasted words, but it is under-specified. It is concise but not sufficiently informative for a delete operation; hence it is not as helpful as a well-rounded concise description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a delete tool with no annotations and no output schema, the description is incomplete. It does not clarify the scope of deletion (e.g., whether related assignments are also removed), possible side effects, or any conditions. The presence of sibling tools like delete_zone_ortb_native_ad suggests potential orphaned data that the description should address.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the only parameter 'id' with a description ('Ad item ID'), so schema coverage is 100%. The description adds no extra meaning beyond the schema, meeting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Delete') and resource ('native ad item'). It is not vague and matches the tool name. However, it does not distinguish from sibling tools like delete_zone_ortb_native_ad or draft_delete_native_ad_item, 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no mentions of related draft vs. live items. There is no exclusions or alternative suggestions.
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?
There are no annotations, so the description carries the full burden of behavioral disclosure. It merely restates the tool's name ('Create a new draft rich media ad item') without revealing side effects, validation requirements, permissions, return values, or how drafts relate to the broader campaign lifecycle.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no wasted words, but it is under-specified rather than truly informative. It is concise but lacks substance, earning a middle score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, no output schema, and a loosely-defined nested 'draft' object, the description is insufficient for a create operation. It does not explain the rich media ad item field structure, how to save/commit the draft, or how the draft differs from a live ad item.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters with 100% coverage, so the baseline is 3. The tool description adds no parameter-level detail, and the nested 'draft' object is only loosely described as containing rich media ad item fields with name required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 ('new draft rich media ad item'), making the tool's purpose unambiguous. It also distinguishes from sibling draft tools for other ad item types (e.g., draft_create_image_ad_item) and from the non-draft create_rich_media_ad_item.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 over alternatives, such as draft_create_image_ad_item or create_rich_media_ad_item. It doesn't explain the draft workflow, prerequisites, or whether this is for a draft campaign vs. a published campaign.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 of behavioral disclosure. It only says 'Get', implying a read operation, but does not describe what the report contains, whether it requires special permissions, or any output format. This is insufficient for a tool with no other safety indicators.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is structurally concise, but it is under-specified to the point of being unhelpful. It lacks the detail needed to earn its place, though it is not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations, output schema, and the presence of many related sibling tools, this description is far too minimal. It does not explain what a VAST forecast report is, how the parameters affect the report, or what the response looks like, 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.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% because both parameters have descriptions ('Date preset' and 'Timezone'), but these are minimal and add little meaning. The tool description itself adds no extra parameter context, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get VAST forecast report' clearly identifies the action (Get) and resource (VAST forecast report), making the basic purpose understandable. However, it does not distinguish this from siblings like get_vast_report or get_vast_channel_forecast, lacking scope 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as get_display_forecast or get_vast_channel_forecast. No context or exclusion criteria are provided, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only says 'List all native ad items' without mentioning read-only nature, pagination behavior, response format, or any side effects. The read-only nature is implied but not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff, but it adds little beyond the tool name. It is not a genuinely helpful elaboration, though it is not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description should explain return values and key behaviors. It does not mention response structure, default sorting, or the distinction between live and draft items—information that is relevant for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides descriptions for both limit and offset, covering 100% of parameters. Per the rubric, the baseline is 3 when schema coverage is high, and the description adds no additional parameter context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('native ad items'), clearly stating the tool's purpose. However, it doesn't differentiate this from sibling tools like list_ad_items or draft_list_native_ad_items, so it loses a point for missing 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/5Does 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 is essentially a restatement of the tool name and offers no context on selecting this tool over similar list 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, the description carries the full burden of behavioral disclosure. 'Replace' implies a destructive/overwriting operation, but no details are given about whether the old file is retained, if a new revision is created, whether the operation is permanent, or if any confirmation is needed. The description adds no context beyond what the name already implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and to the point, with no wasted words. However, it is a single sentence that could be considered terse, lacking any additional structure (e.g., usage notes, caveats) that would make it more helpful without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutation tool with no annotations, no output schema, and a description that only restates the action. It fails to explain how the file content is provided (the schema only has IDs, so there must be a separate upload mechanism), what happens to the existing file, or any side effects. The description is inadequate for an agent to correctly invoke this tool beyond knowing the basic intent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: both 'contract_id' and 'document_id' have descriptions in the schema. The tool's description does not add any parameter-specific meaning, but the schema already documents them adequately. Baseline is 3 and no additional value is provided by the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'replace' and the resource 'the file on a contract document', making the primary action evident. It could further distinguish itself from the sibling 'replace_contract_document_file_from_template', but still conveys the core intent unambiguously.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage context is provided. The description does not mention when to use this tool over alternatives, what type of file is expected, whether it is meant for updating an existing document versus creating a new one, or any prerequisites. It only restates the action without guiding the agent on appropriate invocation scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavior, but it only says 'Search for items.' It does not describe return format, pagination, query semantics, or whether it returns a list of items. This is a significant transparency gap for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, concise and front-loaded, but it lacks structure or additional helpful details. It is minimally worded but under-specified, so it doesn't earn above a 3.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description should explain what the search returns and any behavior like filters or limitations. It does neither. For a 3-parameter tool with no annotations, this is incomplete and would require the agent to probe the API to understand the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter having a description (query: 'Search query string', catalog_id, publisher_id). The description adds no extra meaning beyond restating 'search,' but the schema already documents parameters adequately, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Search') and the resource ('items in a product catalog'), distinguishing it from related get/list tools like get_product_catalog_item or list_product_catalogs. However, it is somewhat generic and does not explicitly note that this is a filtered search supporting a query string, so it falls short of 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/5Does 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. No mention of using get_product_catalog_item for single-item retrieval or list_product_catalogs for catalog listing, and no mention of conditions like 'use when you need to search by query.' This leaves 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 bears the full burden of disclosing behavioral traits. While 'Update' implies a mutation, the description does not state whether it is a partial or full update, what happens if the campaign does not exist, or any side effects. It adds almost no value beyond the tool name itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. It is front-loaded with the action. However, given the complexity of the tool, it could afford more detail without jeopardizing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has 10 parameters, nested objects, and no output schema, yet the description provides almost no contextual information. It does not explain what 'standard campaign' means, what fields are typically updated, or how this relates to other campaign operations. The description is grossly insufficient for an agent to make an informed invocation decision.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all 10 parameters. The description does not add any additional semantic meaning beyond what is in the schema. Per the rubric, the baseline is 3, and the description neither enhances nor detracts from it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does 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 standard campaign'). It distinguishes from create/get operations, but the term 'standard' is ambiguous and there is no explicit differentiation from sibling tools like vast_update_campaign or draft_update_campaign, which could also be relevant.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as draft_update_campaign or vast_update_campaign. The description does not mention any prerequisites, exclusions, or scenarios that would favor this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 only states an update operation without disclosing partial update semantics, side effects, permission requirements, or behavior for omitted fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no superfluous words. It is concise, though it lacks detail that would be useful for a complex tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex tool with 11 parameters, nested objects, enums, and no annotations or output schema. A one-sentence description is grossly insufficient to help an agent understand update semantics, relationship to draft workflows, or the effect of omitting fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage for all 11 parameters, so the baseline is 3. The description adds no additional parameter context, but the schema already documents each field.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'Update' and the resource 'rich media ad item', clearly indicating a mutation operation. However, it does not distinguish between this and sibling tools like draft_update_rich_media_ad_item, nor does it mention any scope or specific fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 draft versions, required 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 the full burden of behavioral disclosure. It only states 'Update an existing schedule', implying mutation but not explaining whether partial updates are supported, if the schedule must already exist, what side effects occur, or what the response contains. For a tool with 16 parameters, 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at three words and contains no fluff. However, for a tool with 16 parameters, this brevity borders on under-specification rather than effective conciseness. It reads more as a label than a meaningful description, though it is not bloated or disorganized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 16 parameters, no annotations, and no output schema, yet the description only provides a generic action. It does not mention return values, the meaning of the required 'id' parameter, or which schedule domain it applies to (ad serving, VAST, draft, report). This is inadequate for a complex tool and leaves the agent with significant ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with detailed descriptions (e.g., 'End date/time in ISO-8601 format', 'Delivery pacing: "default" (ASAP) or "smooth" (evenly distributed)'). The description adds no parameter-level information beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Update') and resource ('existing schedule'), making the basic purpose understandable. However, it does not differentiate this tool from sibling tools like 'vast_update_schedule' or 'draft_update_schedule', which also update schedules in different 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the many alternative schedule-related tools. There are siblings such as 'vast_update_schedule', 'draft_update_schedule', and 'update_report_schedule', but the description offers no selection criteria or context for choosing this one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only says 'Create', which is the basic action. It does not mention side effects, return behavior, required parent entities, auth needs, or any consequences of invocation. This is no more informative than the tool name itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that is perfectly front-loaded and contains no fluff. It is concise and easy to scan, earning a high score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (3 params, no output schema), but the description is too sparse. It does not explain what a 'VAST 4.2 ad item' is, does not differentiate this tool from the similar vast_create_ad_item or draft_create_ad_item, and does not indicate what the response contains. This leaves an agent without sufficient context to invoke it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter description coverage, with each parameter (name, active, location) clearly explained. The description adds no parameter-level detail, but the baseline for full schema coverage is met, so a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description precisely states the action ('Create') and the resource ('VAST 4.2 ad item'), making it clear this tool creates a specific entity. This distinguishes it from sibling tools like vast42_get_ad, vast42_update_ad, and vast42_delete_ad, which handle other CRUD operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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 vast_create_ad_item, draft_create_ad_item, or even vast42_create_placement. The description does not mention prerequisites, ordering, or any condition that would help an agent choose this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only indicates a creation action but does not disclose side effects, required parent entities, return behavior, or error conditions. An agent would not know what happens on success or what constraints apply, making this minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise and front-loaded with the action. However, it is under-specified, lacking essential context that would make the sentence fully useful. It is not a tautology but is too sparse to be considered well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters and no output schema or annotations, so the description must compensate for the lack of context. It does not explain how the media file relates to other VAST entities, what the expected response is, or any operational constraints. The description is inadequate for an agent to use the tool correctly in a realistic workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage for all five parameters, so the baseline is 3. The description does not add any parameter semantics beyond what the schema already provides, but the schema descriptions are clear enough for the agent to understand the parameter meanings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a VAST 4.2 media file' clearly states a specific action (create) and resource (VAST 4.2 media file), which distinguishes it from sibling update/delete/list operations. However, it is minimal and does not elaborate on what constitutes a media file, leaving some ambiguity for an agent unfamiliar with 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/5Does 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., an existing linear ad), context, or when alternative tools like vast42_create_linear or vast42_create_mezzanine might be more appropriate. There is no usage context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the sole source of behavioral information. It discloses no behavioral traits: whether the update is partial or full, whether the companion must exist, what happens on failure, or any permission requirements. The text is merely a restatement of the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, making it concise and front-loaded. However, it is under-specified and essentially repeats the tool name ('Update a VAST 4.2 companion' → vast42_update_companion), adding no additional value. It is not 'appropriately sized' because it omits critical context for a useful description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description should describe return values, error behavior, or prerequisites. It does none of these, leaving the agent with minimal context beyond 'update companion'. This is insufficient for confident invocation in diverse scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% description coverage for all parameters (id, name, width, height), so the description does not need to add parameter details. It adds no extra semantic meaning beyond the schema, which is acceptable per the baseline for fully documented schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Update') and resource ('a VAST 4.2 companion'), with '4.2' clearly distinguishing it from the sibling tool 'vast_update_companion' (without 4.2). This makes the tool's function immediately clear and differentiates it from create/delete companion variants.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not mention when to use this tool versus alternatives such as vast42_create_companion or vast42_delete_companion, nor does it state prerequisites or exclusions. The agent must infer usage solely from the name and sibling 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?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only restates the action ('Create a new VAST linear media') without revealing side effects, idempotency, permission requirements, response contents, or any constraints. This adds zero behavioral information beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence). However, it is essentially a restatement of the tool name and does not add structural or contextual value. It is not verbose, but it also does not earn its place by contributing new information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no output schema, and sits in a complex ecosystem of VAST CRUD tools, the description is insufficient. It does not explain what linear media represents in the VAST hierarchy, how it differs from non-linear media, or what the result of creation is. The schema covers parameters but not operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter clearly documented (name, bitrate, duration, mime_type). The description itself adds no parameter-level details, but the schema already handles this, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and identifies the exact resource ('new VAST linear media'). It clearly distinguishes from sibling tools like vast_update_linear_media, vast_delete_linear_media, and vast_create_non_linear_media by explicitly stating 'linear'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites (e.g., existing campaign/placement), relationships to other objects, or situations favoring non-linear media. The usage is only implied 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?
With no annotations, the description must disclose behavioral details, but it only states the action. It doesn't mention return values, required fields, or side effects, leaving the agent without context about what creating a zone entails.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is minimal but not verbose; however, its brevity sacrifices useful context. It is front-loaded but under-specified, earning a middle score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, and the tool's six parameters including nested objects and mutual exclusivity, the one-line description is insufficient to fully understand the operation. It doesn't cover success/failure behavior, defaults, or constraints beyond the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% description coverage for all six parameters, so the description doesn't need to restate them. However, it also doesn't add any additional context, aligning with the baseline score of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new VAST zone' clearly identifies the action (create) and the resource (VAST zone), distinguishing it from sibling tools like vast_create_placement or vast_create_campaign. It is succinct and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No information is provided about when to use this tool, prerequisites, or alternatives. It lacks any guidance that would help an agent choose it over other zone-creation tools like create_zone or vast_create_placement.
Agents often have multiple tools that could apply. Explicit usage guidance like "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. 'Archive an email zone' only states the action; it does not disclose whether the operation is reversible, whether special permissions are required, what side effects occur, or what the response will be. This is insufficient for a mutation tool without annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, complete sentence with no redundant words. It is front-loaded with the verb and object, and every word contributes meaning. It is maximally concise without being nonsensical, unlike a tautological single word.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there are no annotations and no output schema, the description should explain more about the tool's behavior and return value. It only states the operation, leaving the agent without information about the post-archive state, whether an archived email zone can be unarchived, or what a successful response looks like. This is inadequate for a mutation tool with no supplementary context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the single parameter 'id' with a description 'Email zone ID' (100% schema description coverage). The tool description does not add any further semantic detail, but since the schema fully documents the parameter, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Archive an email zone' clearly specifies the verb (archive) and resource (email zone), making the tool's purpose immediately understandable. It distinguishes itself from the general 'archive_zone' and 'vast_archive_zone' by including 'email', but does not explicitly call out this differentiation in the description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 'archive_zone', 'unarchive_email_zone', or 'vast_archive_zone'. The description does not mention prerequisites, effects, or any context that would help an agent decide to invoke this specific tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It only states the intent to 'bulk add entries' but does not disclose whether entries are appended to existing data, what happens if duplicates exist, or any rate limits or error behavior. The description is essentially tautological with the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It is structurally concise and easy to parse, though the extreme brevity leaves out important details. Still, it earns its place as a minimal statement of the tool's basic function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a bulk mutation tool with no annotations and no output schema, so the description is the only source of context. It fails to mention the CSV format, whether the operation is additive, or that sibling upload tools (remove/replace) exist. The tool is incomplete for an agent to safely invoke it without additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides complete descriptions for both parameters: 'id' as 'Data list ID' and 'data' as 'CSV data to add'. The description adds no further meaning to these parameters, but with 100% schema coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Bulk add entries to a data list' uses a specific verb ('add') and resource ('data list'), clearly indicating the action. It distinguishes from sibling tools like bulk_upload_remove_data_list and bulk_upload_replace_data_list via the verb, but the term 'entries' is vague and the description does not explicitly compare with those 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not say when to use this tool versus bulk_upload_replace_data_list or bulk_upload_remove_data_list, nor does it mention prerequisites, whether the upload is append-only, or how the CSV data should be structured. The agent is left without context to choose this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 merely states the action without mentioning whether the upload is asynchronous, destructive, permission-restricted, or what the response looks like. This is a significant gap for a bulk 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant words, making it concise and front-loaded. However, it is so brief that it omits useful details that could be added without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a bulk upload tool with no annotations, no output schema, and a generic description, the context is severely lacking. It does not explain what 'items' are, how they are supplied, whether the operation is synchronous, or what the outcome is. Sibling tools like bulk_upload_add_data_list suggest more detailed descriptions are possible.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both catalog_id and publisher_id having descriptions. The tool description adds no additional meaning beyond the schema, but since the schema already documents the parameters, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Bulk upload') and resource ('items to a product catalog'), clearly distinguishing it from single-item creation tools like create_product_catalog_item. However, it does not specify what 'items' means (e.g., product catalog items) or what 'upload' involves (e.g., file format, batch size), 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as create_product_catalog_item or bulk_create_product_sources. It does not mention prerequisites, file formats, or any conditions under which bulk upload 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, the description carries the full burden for disclosing behavior, but it only states the action 'cancel' without explaining effects, reversibility, permissions, or whether it is distinct from deletion. This is a significant transparency gap for a state-changing 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words, making it very concise. However, it is so minimal that it sacrifices valuable context, so it does not reach the level of exemplary conciseness that also informs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of sibling tools like delete_signature_request and resend_signature_request, and the absence of annotations or output schema, the description is too sparse to be complete. An agent cannot understand the full implications of canceling versus deleting a signature request.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and each parameter (contract_id, request_id) has a description in the schema. The tool description adds no additional parameter meaning, so it meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb+resource ('Cancel a signature request') that communicates the basic action. However, it does not distinguish this from the sibling tool delete_signature_request, so it lacks the specificity needed for an agent to know which one to pick.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 delete_signature_request or update_signature_request. There is no mention of prerequisites, exclusions, or preferred contexts, leaving the agent without 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, the description carries the full burden of behavioral disclosure, but it only states that a new assignment is created. It does not mention side effects, required campaign/advertisement state, authorization needs, whether the operation is reversible, or what the response contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with a clarifying parenthetical. Every word contributes to understanding the tool's purpose, and there is no redundant or fluff content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a create operation with 11 parameters, nested objects, conditional dependencies (e.g., schedule only if campaign scheduling_source is AD_ITEM), and no output schema or annotations. The one-sentence description does not provide enough context for correct invocation, edge cases, or expected behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents each of the 11 parameters thoroughly. The description adds only minimal relational context ('assign an ad item to a campaign'), which slightly reinforces the required parameters but does not add meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and resource ('campaign assignment') and clarifies the action with the parenthetical 'assign an ad item to a campaign,' which defines the core relationship. However, it does not differentiate this tool from sibling tools like draft_create_campaign_assignment, vast_create_campaign_assignment, or vast42_create_campaign_assignment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as draft_create_campaign_assignment or the vast/vast42 variants. There are no exclusions, prerequisites, or context cues to help an agent choose among the many similar create/update/list/delete siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it is purely a restatement of the action. It does not mention any side effects, required permissions, uniqueness constraints, or what happens upon creation, providing little beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with zero wasted words, making it easy to parse. However, it borders on under-specification, lacking context that could be valuable without significant bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no annotations, and no output schema, the description is quite incomplete. It does not explain what a 'channel' is in this context, how it differs from vast channels, or what a successful creation returns. The sibling list shows many channel-related operations, and this description does nothing to orient the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all three parameters, each with descriptive text. Per the baseline rule, with high schema coverage, the description needs no additional parameter info. The description itself adds no parameter semantics but is adequately supported by the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' and resource 'channel', providing a clear basic purpose. However, it does not differentiate among the many sibling channel tools (e.g., vast_create_channel, update_channel, archive_channel) or specify what type of channel is 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or typical scenarios, leaving the agent to infer usage solely from 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?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the core action but does not mention whether the operation is idempotent, whether it overwrites existing assignments, what happens on conflicts, or any required permissions. The behavior beyond the action itself is 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently conveys the essential purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given moderate complexity (nested object, optional zone type) and no annotations or output schema, the description is too sparse. It omits information about the operation's effect, return value, potential errors, and how it relates to the vast_* variant. This leaves significant gaps for an agent deciding when and how to invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema fully documents both parameters (channel, zone) and the nested zone object with id and type. The description adds no extra meaning beyond what the schema already provides, warranting the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Assign a zone to a channel' uses a specific verb and clearly identifies the two involved resources (zone and channel). It distinguishes this tool from list/get/delete siblings for the same object pair, though it doesn't explicitly differentiate from the similarly named vast_create_channel_zone_assignment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or the existence of related create/update/delete operations. The description gives no contextual direction for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('Create') but does not mention side effects, required permissions, return behavior, or whether existing documents are affected. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no fluff or redundant information. It efficiently conveys the core purpose, earning every word.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, and the description is minimal. It does not explain what a 'contract document from a template' entails, the optionality of template_id, or how this differs from similar tools like create_contract_document. The description is insufficient for an agent to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both contract_id and template_id, so the schema already documents the parameters. The description adds no additional parameter semantics, such as the relationship between the IDs or why template_id is optional, staying at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and resource ('contract document') and explicitly mentions 'from a template', clearly indicating the tool's core function. However, it does not explicitly distinguish it from sibling tools like create_contract_document or replace_contract_document_file_from_template, though the name provides some 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/5Does 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, leaving the agent to infer usage solely from the tool name and the minimal 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Create a new data key target,' which implies a mutating operation but does not explain whether existing targets can be overwritten, whether the target must reference an existing data key, what the response will be, or any error conditions. This is a significant gap 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the verb and noun. It avoids unnecessary detail, but it is arguably too sparse—omitting useful context that could fit without harming conciseness. Still, it is appropriately sized for a simple CRUD operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple with only two fully documented parameters and no nested objects. However, there is no output schema, no annotations, and the description does not explain what a 'data key target' is, how it relates to data keys, or what the API returns upon creation. For a straightforward create operation, this is minimally viable but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for both parameters ('name' and 'target'), including a concrete JSON example for the target logic. The description adds only the phrase 'targeting rule,' which offers marginal additional context beyond the schema. The baseline of 3 applies because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and the resource ('data key target'), with a parenthetical clarification that it is a 'targeting rule.' It does not explicitly differentiate from sibling tools like update_data_key_target, but the verb 'create' and the resource name make the core purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 update_data_key_target, list_data_key_targets, or delete_data_key_target. There is no mention of prerequisites, contexts, or exclusions, 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.
- 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. It only states the creation action but does not disclose side effects, required permissions, reversibility, or what happens on success. It adds no behavioral context beyond the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear, and front-loaded sentence with no unnecessary words. However, it is under-specifying in substance, which prevents a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create tool with no annotations and no output schema, the description is very thin. It does not explain what a data asset is in ORTB native context, how template_id is used, or what the result of the operation looks like, making it incomplete for an agent to fully understand the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters (len, type, template_id). The description adds no parameter-level meaning, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Create') and resource ('new data asset for an ORTB native template'), clearly distinguishing it from sibling tools that create other asset types like image or title assets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as create_ortb_native_image_asset or create_ortb_native_title_asset. It also fails to mention prerequisites like the need for an existing template_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, the description carries the full burden of behavioral disclosure. It only states 'create,' implying a write operation, but gives no information about side effects, required permissions, idempotency, or what happens on success/failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no redundant words. It is appropriately minimal and front-loaded with the key action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a creation tool with no annotations, no output schema, and a minimal description. The description does not explain the return value, required fields (despite schema marking none as required), or any post-creation behavior. An agent would lack critical information about the outcome of the call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters clearly described (name and html_template with an example). The description adds no extra parameter detail, but the schema already provides sufficient semantics, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create) and the resource (OpenRTB native template) with specific domain context. However, it does not differentiate from the sibling tool create_native_template, leaving ambiguity about what makes this template OpenRTB-specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage context is provided. The description does not explain when to use this tool over create_native_template, whether there are prerequisites, or what scenarios call for an OpenRTB native template.
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 present, so the description carries the full burden of behavioral disclosure. It only repeats the mutation implied by the tool name and provides no information about idempotency, validation rules, required permissions, or side effects. This adds zero value beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with the key verb 'Create' front-loaded. It is appropriately sized and contains no waste, though it could add more contextual value within the same brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description should clarify the intended use of a postal code target (e.g., geo-targeting by postal code) and what the create operation returns or requires. The current one-liner is insufficient for an agent to understand the tool's role in the broader system.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters (label, inclusive, locations) already have descriptive text in the schema. The description itself adds no parameter details, but per the rubric the baseline is 3 when coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new postal code target' clearly identifies the action (create) and the resource (postal code target). It distinguishes itself from sibling CRUD tools such as update_postal_code_target, get_postal_code_target, and list_postal_code_targets through the Create prefix.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like update_postal_code_target for existing targets. There is no mention of prerequisites, such as whether a target should already exist for updates, or any context about target creation workflows.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 of behavioral disclosure. It only says 'create,' which implies mutation, but does not mention permissions, idempotency, return values, side effects, or any operational nuances. No contradiction with annotations exists since none are provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action and resource, with zero waste. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal and does not explain what a product source target is, what a successful creation returns, or how it relates to publishers and product sources. With no output schema and no annotations, the agent lacks important contextual information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage of parameter descriptions, so the baseline is 3. The description adds no additional meaning to the parameters beyond what the schema already documents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'Create a new product source target for a publisher.' It distinguishes itself from siblings like create_product_source by naming the specific resource type, though it doesn't explicitly call out the 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/5Does 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 update_product_source_target, list_product_source_targets, or create_product_source. The description is a bare definition 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.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only says the tool creates a schedule. It does not mention required prior configuration, whether the operation is idempotent, what side effects occur, or what the response looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundancy. It is concise, though it lacks substantive content that would make it more useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three parameters, no annotations, and no output schema, the description is too sparse to provide complete context. It fails to explain what a report schedule is, when scheduling is appropriate, how recipients and frequency should be specified, or what the resulting schedule does.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3 even though the tool description adds no parameter details. The schema descriptions are somewhat sparse (e.g., 'Schedule frequency' and 'Array of recipient objects'), but the description itself does not clarify formats, defaults, or allowed values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and the resource ('report schedule'), and the verb distinguishes it from sibling tools like update_report_schedule and delete_report_schedule. However, it does not add any scope or nuance beyond the tool name, so it stops short of a top 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives such as update_report_schedule, delete_report_schedule, or list_report_schedules. The description only restates the action and provides no context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It does mention the multipart file upload requirement, but lacks information about permissions, reversibility, or side effects expected from a create 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with two sentences. The first states the purpose, and the second provides a relevant implementation detail. No wasted words and well front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters, no output schema, and no annotations, the description is minimal and lacks usage guidance, behavioral context, and return value expectations. It is not complete enough for a create operation in a rich API context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds a small detail that the upload is a ZIP for HTML5, which relates to 'index_file_path', but does not significantly enhance understanding of other parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a new rich media creative') with a specific verb and resource. It distinguishes from generic 'create_creative' by specifying 'rich media' but doesn't explicitly differentiate from similar operations like 'create_rich_media_ad_item'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'create_creative' or 'update_rich_media_creative'. The only additional sentence describes the upload mechanism, not usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 'create a new role' and doesn't mention side effects, required permissions, duplicate name handling, or response behavior—significant gaps for a mutating 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the verb and resource. It contains no redundant or extraneous wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 20 parameters and no output schema or annotations, the description provides no context about parameter relationships, default behavior, or success criteria. It 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.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each parameter has a clear description, so the description's generic 'permission settings' adds no meaning beyond the schema. Baseline 3 is appropriate since the schema already documents all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Create a new role'. It clearly indicates the tool's function and distinguishes it from sibling update/get/delete role tools through the 'create' action, 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives, no prerequisites, and no exclusions. The intended use is only implied by the word 'create', which is insufficient for a 20-parameter administrative tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only says 'Create a new user' but doesn't describe any side effects, permission requirements, idempotency, or what happens if the user already 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler words, which is efficient. However, it is so brief that it lacks important context, though that is a matter of content rather than conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with three parameters and no output schema, the description is insufficiently informative. It fails to mention the return value, the role of required user_db_id, or how to handle errors, and does not help differentiate from sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions cover all parameters (user_id, attributes, user_db_id), so the baseline is 3. The description adds no additional semantics beyond the schema, such as relationships between parameters or default behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Create') and the target resource ('a new user') plus scope ('in a user database'), which distinguishes it from create_user_db. However, it doesn't explicitly differentiate it from other user-related operations like get_user or create_user_attribute, though those are 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives or any prerequisites. It simply states what it does without mentioning the required user_db_id or how it relates to create_user_db.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 'Create a new user database' without mentioning side effects, permissions, idempotency, error behavior, or the relationship to user attributes or lists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no filler or redundant phrasing. It is front-loaded and efficient, though extremely sparse; this still meets a high standard for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with no annotations and no output schema, the description should explain the purpose of the database, the role of 'id_field_name', and what a successful creation returns. It provides none of this, leaving the agent uncertain about expected results and side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: both 'name' and 'id_field_name' have inline descriptions, so the schema already explains the parameters. The description adds no parameter-level detail, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and a clear resource ('user database'), so the agent can tell this tool creates a user database rather than a user or an advertiser. It distinguishes from siblings like 'get_user_db' and 'create_user' by naming the database resource, though it does not elaborate on the database's role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as 'list_user_dbs', 'get_user_db', or 'create_user'. There are no prerequisites, exclusions, or contextual hints, so the agent must infer usage entirely from 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, and the description offers no insight into what a VAST report configuration is, whether it is persisted, what response to expect, or any side effects. The sentence is purely a statement of the operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the operation. It is appropriately short with no unnecessary wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the large number of report-related sibling tools (create_custom_report, create_report_schedule, update_custom_report, etc.), the description lacks context on what a VAST report configuration specifically involves, or how it relates to other report tools. No output schema exists, so the description should explain the outcome or return value, but it doesn't.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the 'name' parameter with type string and description 'Report name'. The description does not add any additional semantics about how 'name' is used or what constitutes a valid configuration.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Create' with the resource 'VAST report configuration', clearly indicating the action. It does not explicitly distinguish from the sibling 'create_custom_report', but the 'VAST' qualifier gives some 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no mention of when to use this tool or alternatives. No exclusions, prerequisites, or guidance on selecting between create_vast_custom_report, create_custom_report, and create_report_schedule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must communicate behavioral details, but it only says 'Delete a campaign assignment'. It does not disclose whether the deletion is permanent, whether there are side effects (e.g., removing related records), permission requirements, or any 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, containing a single sentence with no unnecessary filler. It could be more informative, but for a one-parameter delete operation, this brevity is acceptable and not wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one required parameter, no output schema, no annotations), so a minimal description is somewhat viable. However, the description lacks context about the deletion's effects, return values, or how it differs from the several similarly named sibling tools, making it only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the single 'id' parameter with 100% coverage as 'Campaign assignment ID'. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and resource ('campaign assignment'), making the primary purpose obvious. However, it does not distinguish this tool from similarly named siblings like 'vast_delete_campaign_assignment' or 'vast42_delete_campaign_assignment'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 'update_campaign_assignment', 'list_campaign_assignments', or the namespaced delete variants. The description simply states the action without explaining preferred use cases 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 must carry the full burden of behavioral disclosure. It only says 'Delete' and gives no indication whether the operation is permanent, reversible, or cascades to related entities. This is a significant gap for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with zero wasted words, making it efficient. However, it lacks any structural elements like context or examples, which limits its usefulness beyond being a tautological phrase.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema, but the description omits essential operational context such as whether deletion is permanent, how it differs from draft deletion, and what happens to associated data. This is incomplete for a destructive tool in a complex domain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides a description for the only parameter 'id' ('Ad item ID'), and coverage is 100%. The tool description adds no additional parameter semantics, so the baseline score of 3 is appropriate per the rubric.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (delete) and object (catalog ad item), which is a specific verb+resource combination. However, it does not distinguish between deleting a live vs. draft catalog ad item, especially given the sibling tool draft_delete_catalog_ad_item.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not explain when to use this tool versus the draft deletion variant, nor does it mention any prerequisites or consequences that would inform the user's decision.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 of behavioral disclosure. It only states 'Delete a channel' without revealing whether this is a hard/soft delete, whether it is reversible, what cascading effects occur (e.g., on zones or assignments), or any required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, making it concise and front-loaded. However, it is so minimal that it lacks any structured context or nuance, so it is slightly below a perfect conciseness score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the destructive nature of the operation, the absence of annotations, no output schema, and the large number of related sibling tools, the description is incomplete. It fails to clarify the type of channel, permanence of deletion, or impact on related entities, 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.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the 'id' parameter already has a clear description ('Channel ID'). The description adds no further meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb+resource: 'Delete a channel'. However, it does not distinguish between the many delete-related sibling tools such as vast_delete_channel, delete_archived_channel, and archive_channel, so it is clear but lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 scenarios, prerequisites, or exclusions, 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, the description carries full burden but discloses only the basic delete action. It does not state whether deletion is irreversible, whether it affects associated targets, or any permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler or redundancy. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the simple schema, the description lacks essential behavioral context for a destructive operation. No annotations or output schema exist, so the description should at least disclose irreversibility or side effects, but it does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully documents the single 'id' parameter with a brief description, giving 100% schema coverage. The tool description adds no further semantic meaning about how to obtain the ID or any constraints beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action (delete) and resource (data list), clearly indicating the tool's function. It differentiates from sibling tools like get_data_list and create_data_list by its verb, though it lacks additional context about what a data list is or any special conditions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided regarding when to use this tool, prerequisites, or alternatives. The description simply states the action without explaining whether deletion is permanent or has dependencies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits. It simply says 'Delete' without indicating whether deletion is permanent/reversible, what happens to dependent rules, or any permission requirements. 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant text. It is appropriately minimal, although it lacks any additional useful context; still, it is efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description provides only the bare action. It omits behavior disclosures and usage guidance, making it incomplete for an agent to understand side effects. The simplicity of the parameter does not compensate for missing context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the only parameter (id) with a clear description ('Day parting ID'), achieving 100% coverage. The description adds no additional parameter context, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies a delete operation on a 'day parting rule' with a specific verb and resource. It distinguishes from siblings like create_day_parting/update_day_parting, though it doesn't add extra scope or edge-case clarification like the highest-scoring examples.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, prerequisites, or exclusions. The description merely states the action without any 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 simply states 'Delete' without mentioning permanence, cascading effects, or failure conditions. 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at one sentence, front-loading the core purpose. It is not verbose or redundant, but it is so minimal that it approaches under-specification; however, for a simple delete operation, this length is acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description is minimally complete: it states the operation and the resource. However, it lacks context about deletion consequences, reversibility, or related usages, which would be expected for a destructive action. This is a clear gap for a tool operating within a complex domain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single 'id' parameter, which has a clear description ('List target ID'). The tool description adds no additional parameter semantics, but the schema already fully documents the input, aligning with the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a list target' clearly identifies the action (delete) and the resource (list target), which is specific enough to distinguish from sibling operations like get, create, or update. However, it adds no detail beyond the tool's name, so it does not fully capitalize on the opportunity to clarify scope or nuance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as remove_list_target_usages or update_list_target. It does not state any prerequisites, warnings, or scenarios where deletion is appropriate, leaving the agent to infer usage from the operation 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 the full burden of behavioral disclosure. It only conveys the destructive verb 'Delete' but does not state whether deletion is permanent, reversible, cascading, or requires special permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise phrase with no filler words or redundant structure. It is front-loaded and efficiently conveys the core action, though it could benefit from a bit more context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations and no output schema, the description omits important context such as permanence, existence requirements, or side effects. While the parameter is fully documented, the deletion behavior is under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the single 'id' parameter as a required number with description 'Manager ID', providing 100% coverage. The description adds no additional parameter meaning, so the baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Delete) and resource (manager), distinguishing it from sibling operations like create_manager, update_manager, and get_manager. However, it lacks scope details such as 'by ID' or 'permanently', 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool instead of create_manager, update_manager, or other delete operations. The description neither states prerequisites nor excludes alternative scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'Delete', which implies destruction, but does not state whether deletion is permanent, whether it cascades to dependent sources, what happens if the source is in use, or any authorization requirements. This is a significant gap 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately conveys the operation. It contains no filler or redundant wording, and every word contributes to clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a deletion tool with no annotations or output schema, the description is incomplete. It omits side effects, return behavior, error conditions, and whether the action is reversible. The two required parameters are documented in the schema, but the tool's operational context is not sufficiently covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both source_id and publisher_id described as 'Source ID' and 'Publisher ID'. The description adds no additional parameter meaning beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Delete a product source'. It distinguishes itself from related product source tools (create/update/get/list) and from the sibling delete_product_source_target, though it does not elaborate on what a product source is or how it differs beyond the noun.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, prerequisites, or context (e.g., whether a source must be unused before deletion). The description is purely a single phrase with no usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure, but it only says 'delete' without revealing whether the action is permanent, cascading, restricted by permissions, or what the response will be. This lacks the transparency needed for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words, perfectly concise for a simple delete operation. It lacks supplementary detail, but that is not a conciseness issue.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter delete with a fully documented schema, the description is minimally viable. However, it omits behavioral details like irreversibility and return values, and with no output schema or annotations the agent has to infer these.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters described as IDs, so the baseline is 3. The description adds no additional parameter context, such as the relationship between publisher_id and source_target_id, but the schema already provides the basic meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (delete) and the specific resource (product source target), making it distinct from sibling tools like get_product_source_target or delete_product_source. However, it provides no additional scope or context beyond restating the tool's name, so it doesn't reach the level of a fully differentiated 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as create/update/get_product_source_target. The description implicitly suggests deleting, but it does not mention prerequisites, exclusions, or related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only says 'Delete a publisher' and does not mention that deletion is destructive, irreversible, or may have side effects. This leaves the agent without critical 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at three words, with no redundancy or filler. It is front-loaded and every word adds meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no annotations and no output schema, the description is under-specified. It does not clarify whether deletion is hard or soft, whether there are dependencies, or what response to expect. The presence of 'archive_publisher' among siblings creates ambiguity that is unresolved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the single 'id' parameter as 'Publisher ID' (100% coverage). The description adds no additional parameter semantics, so the schema carries the load. A baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Delete') and resource ('publisher'), which is specific and unambiguous. However, it does not differentiate from the sibling 'archive_publisher' or explain whether this is a hard or soft delete, so it stops short of fully distinguishing the 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/5Does 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 like 'archive_publisher' or 'unarchive_publisher'. No context is given about prerequisites, permanence, or scenarios where deletion 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 the full burden of behavioral disclosure. It does not mention irreversibility, side effects on related records, required permissions, or any other behavioral traits beyond the obvious 'delete' action. For a deletion tool, this is a significant omission.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. While it lacks detail, it is appropriately concise for the surface-level purpose it communicates.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of closely related sibling tools such as 'cancel_signature_request' and the absence of an output schema, the description is incomplete. It does not explain the distinction between deletion and cancellation, or the impact on associated data, which is essential for correct tool selection in this context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with descriptions for both required parameters ('Signature request ID' and 'Contract ID'). The description adds no additional parameter meaning, but the schema is sufficient, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (delete) and resource (signature request), making the primary purpose unambiguous. However, it does not distinguish this from the sibling tool 'cancel_signature_request', so the purpose is clear but the differentiation is weak.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 'cancel_signature_request' or 'delete_signature_request_recipient'. There are no prerequisites, exclusions, or recommended usage contexts, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits. It only says 'Delete', which implies destruction, but doesn't state whether the deletion is permanent, cascades to associated entities, requires specific permissions, or how it differs from archiving. The existence of sibling tools like archive_zone and delete_archived_zone suggests important nuances that are not mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that is free of fluff. It is concise and structurally sound, though it trades completeness for brevity. This is appropriately minimal given the single parameter, 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.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is destructive, has no annotations, no output schema, and only one parameter. The description is too sparse to be complete; it doesn't mention effects on related zones, whether deletion is reversible, or what happens to associated ad items. This is a clear gap for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with a description for 'id' as 'Zone ID', so the schema already provides necessary semantics. The description adds no extra parameter context, but the high schema coverage justifies a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a standard zone' clearly states the action (delete) and the resource (standard zone), distinguishing it from sibling tools like delete_email_zone or delete_catalog_zone. However, it doesn't explicitly name alternatives or elaborate on what a 'standard zone' encompasses, so it's slightly below the highest tier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 the many related delete/archive/zone tools. The description doesn't mention exclusions (e.g., archived zones, email zones, VAST zones) or alternatives, 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?
No annotations are provided, so the description carries the full burden. It simply states 'Create' without disclosing that this creates a draft (non-live) assignment, that campaign and advertisement are auto-resolved, or any side effects. The 'draft' qualifier is in the name but not explained behaviorally.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action. It contains no fluff, though it is minimal. For a simple CRUD operation, this length is acceptable, but it lacks explanatory context that would make it more useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is incomplete given the surrounding draft_* tool ecosystem. It does not explain what a draft campaign assignment is, how it relates to draft campaigns and ad items, or how it fits into the draft workflow (e.g., draft_save_campaign). The schema provides param definitions but not domain context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, and each parameter has a clear description. The tool description adds no parameter info beyond the schema, so with high schema coverage, the baseline of 3 is appropriate. The 'draft' object's auto-resolution is noted in the schema, not the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new draft campaign assignment', specifying the verb and resource. It is slightly more than the name itself, but it does not explain what a 'draft' assignment is or how it differs from the non-draft create_campaign_assignment sibling, 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/5Does 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. It does not mention that it is for draft workflows, nor does it contrast with create_campaign_assignment or draft_update_campaign_assignment. The description provides no usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 but only repeats the action 'Create a new draft custom HTML ad item'. It does not disclose side effects, requirements, draft semantics, or any behavioral traits beyond the name itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant words. It is appropriately front-loaded with the action, though it could have included more operational detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity of two parameters and a nested object, the one-line description is insufficient. It lacks context about the draft lifecycle, the distinction from live ad items, and the expected outcome, making it incomplete for an agent to confidently invoke.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides complete descriptions for both parameters (campaign_draft_id and draft), with 100% schema_description_coverage. The description adds no extra parameter context, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Create a new draft custom HTML ad item' with a specific verb (Create) and resource (draft custom HTML ad item). It clearly differentiates from siblings like draft_create_image_ad_item and create_custom_html_ad_item by including both 'draft' and 'custom HTML'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool vs alternatives. It does not mention that this is for draft campaigns, that it should be used instead of create_custom_html_ad_item for non-draft items, or any 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 the full burden of behavioral disclosure. It only says 'Create a new draft image ad item', which implies a mutation but does not explain whether this is a safe draft operation, what validation occurs, whether the ad item is persisted immediately, or what the response looks like. Critical behavior for a draft workflow is completely undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence with zero filler or redundant wording. It front-loads the main action and object, making it easy to parse. While it is terse, conciseness is about the absence of waste, and this description has no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool creates a draft image ad item with a nested open-ended 'draft' object, but the description provides no context about the draft workflow, required fields beyond 'name', or how the ad item relates to the campaign draft. No output schema exists and no annotations are present, so the agent must rely on the description alone—making it inadequate for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema descriptions cover both parameters: campaign_draft_id is 'Draft campaign ID this ad item belongs to' and draft is 'Object containing image ad item fields (name required)'. Since schema description coverage is 100%, the description does not need to add parameter details. It provides no additional semantics beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and the resource ('new draft image ad item'). It is more specific than a bare tautology and the resource type distinguishes it from sibling tools like draft_create_catalog_ad_item or draft_create_native_ad_item. However, it does not elaborate on what 'draft' means or how this differs from the regular create_image_ad_item, so it gets 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 Guidelines2/5Does 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 that this is for creating draft ad items before publishing, nor does it reference the non-draft create_image_ad_item or the draft update/delete counterparts. An agent is left without context about which tool to pick in a draft workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Create a new draft schedule' without explaining side effects, required permissions, whether the draft is persisted, or what the return value is. This is a significant gap for a create 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It is concise and immediately communicates the core purpose, making it easy for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should explain what the created draft schedule looks like or whether it returns an ID. Additionally, the draft parameter is an open object (additionalProperties: {}), and the description does not clarify required schedule fields or how this integrates with draft lifecycle tools. Overall, the description is too sparse to be complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters (campaign_draft_id and draft), each with a basic description. The tool description adds no additional meaning beyond the schema, so the baseline of 3 applies. The draft object description is vague ('Object containing schedule fields'), but the schema already provides some context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new draft schedule' clearly states the action (create) and the resource (draft schedule), making the purpose explicit. It distinguishes from sibling tools like create_schedule and vast_create_schedule through the 'draft' qualifier, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as create_schedule or draft_update_schedule. It does not state that this is for draft workflows or that the draft must be saved before becoming live, leaving the agent without context for selecting this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it only states the action without disclosing irreversibility, cascade effects, or error behavior. For a delete operation, the description is minimal and does not explain consequences or state requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the action and resource. Every word earns its place, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool, the description is too sparse. It does not explain return values, whether deletion is reversible, or any draft-specific behavior, leaving the agent without crucial context despite a straightforward operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% as the only parameter 'id' is documented in the schema. The description adds no additional meaning beyond the schema's provided parameter description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (delete) and resource (draft schedule) with a specific verb. However, it doesn't explicitly differentiate from sibling tools like delete_schedule or vast_delete_schedule, relying on the 'draft' prefix for distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 regular schedule deletion, nor any prerequisites or constraints. The description gives no context about draft workflow or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only repeats the name, without explaining pagination, ordering, return structure, or that it is a read-only operation. This is minimal and lacks meaningful 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single succinct sentence that wastes no words and immediately states the core function. It is front-loaded and 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.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is too sparse to be contextually complete. It does not explain the draft scope, distinguish from similar sibling tools, or describe the return value and pagination behavior, leaving the agent under-informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% because both limit and offset have descriptions. The description adds no additional parameter detail, which is acceptable as the schema already documents them fully. Baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all draft placements with a specific verb and resource. However, it does not explicitly distinguish from sibling list operations like list_placements or vast_list_placements, leaving the 'draft' scope as the only implicit differentiator.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not mention when to use this tool versus the many sibling placement listing tools, nor does it offer any exclusions or context for choosing it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure, but only says 'Update...' – a bare statement of mutation. It does not disclose whether this saves/publishes the draft, requires existing campaign, what fields are affected, or any side effects, so it fails to add meaningful transparency beyond the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Eight words in one sentence, front-loaded with the verb and resource. No filler or redundant phrasing – it's maximally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having a nested object parameter and no output schema, the description provides only a minimal statement. It doesn't explain the 'draft' workflow, what a 'standard campaign' is, or the effect of updating a draft, leaving critical context missing for a mutation tool in a large API with many draft variants.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters have descriptions in the schema. The description itself adds no parameter information beyond what the schema already provides, so it meets the baseline without adding value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'Update' and noun 'existing draft standard campaign' indicate the operation and resource. However, it doesn't distinguish from sibling tools like draft_save_campaign or the non-draft update_campaign, leaving some ambiguity about when this specific variant is preferred.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as draft_create_campaign, draft_save_campaign, or update_campaign. The one-sentence description provides no context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only states 'Update'. It does not mention whether this is a partial or full update, what happens if the draft is already published, what fields are updatable, or whether the changes are reversible. This is insufficient for a mutation tool lacking annotation 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the core purpose with no wasted words. It is concise and easily scannable, earning full credit for structure and brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only two parameters but no output schema and no annotations, so the description needs to provide more behavioral and usage context. The one-line description leaves out return value format, side effects, and the specific meaning of the 'draft' object. This is inadequate for an agent to invoke the tool correctly in all circumstances.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the baseline is 3. The description adds no parameter-specific meaning beyond the schema, but the schema itself clearly documents 'id' as the draft campaign assignment ID and 'draft' as an object containing fields to update. The description is consistent with this and does not need to compensate for schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an existing draft campaign assignment' uses the specific verb 'Update' with the resource 'draft campaign assignment', clearly distinguishing it from create/delete variants. It could be more explicit about which assignments it applies to, but 'draft' in the name and description provides enough differentiation from sibling tools like update_campaign_assignment and vast_update_campaign_assignment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 draft_create_campaign_assignment or vast_update_campaign_assignment. It neither states prerequisites, nor does it explain what 'draft' means in this context, leaving the agent to infer intended use 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 for behavioral disclosure. It only says 'update' without detailing whether it is a partial update, whether validation occurs, what the return value looks like, or any side effects. This is a significant transparency gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words and is front-loaded. However, it is quite terse, bordering on under-specification, though that is more a completeness concern than a conciseness one.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It does not mention the draft workflow context, how it differs from live catalog ad item updates, or what behaviors to expect, leaving the agent under-informed for tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters (id and draft) with 100% coverage, so the baseline is 3. The description adds no additional parameter semantics beyond what the schema provides, but it also does not need to because the schema is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Update' and the resource 'existing draft catalog ad item', distinguishing it from creation or deletion. However, it closely mirrors the tool name and does not explicitly differentiate from non-draft update tools like update_catalog_ad_item, so it 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/5Does 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 update_catalog_ad_item or draft_create_catalog_ad_item. The draft-specific context is implied by the name but not explained, leaving the agent without clear usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It merely restates the mutation without adding any details about side effects, partial vs. full update semantics, permissions, or response behavior. There is no additional context beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wordiness. It is efficient but lacks any structured formatting or additional helpful sections. It earns its place but is minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool updates a complex entity, has a free-form 'draft' object parameter with no defined schema, no output schema, and no annotations. The description gives no information about which fields can be updated, how the draft object should be structured, or what the return value is. This is inadequate for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the two parameters, so the baseline is 3. The description does not add any elaboration on the 'draft' object's fields or the meaning of 'id'. The schema already provides the minimal descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update'), resource ('rich media ad item'), and scope ('draft'). It distinguishes itself from create/list/get/delete siblings and from the non-draft update_rich_media_ad_item by including 'draft'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs. alternatives. It does not mention prerequisites, whether the draft must already exist, or when one might prefer the live version update. The only implied usage is literal reading of the verb 'update'.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 restates the tool name in sentence form and adds no information about read-only nature, output format, pagination, or side effects. The agent is left to infer everything from the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence with no filler or redundant wording. It is well-structured and front-loaded, though it may be too terse to be genuinely informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and minimal parameter descriptions, the tool requires more context than this description provides. It doesn't explain what statistics are included, how preset/timezone affect the report, or what the response looks like. Given the many sibling report tools, this lack of context makes it hard for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes both parameters (preset and timezone) at 100% coverage, so the baseline is 3. The description itself adds no extra meaning about these parameters, such as allowed values or format, but per the rubric the schema coverage keeps this at a passing level.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb 'Get' and identifies the resource as an auction placement statistics report, making the basic purpose understandable. However, it doesn't distinguish this tool from the similarly named sibling 'get_vast_auction_placements_report' or clarify what 'auction placements' entails, so it falls short of full 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus the many report tools in the sibling list, such as get_vast_auction_placements_report or get_display_report. There are no context cues, prerequisites, or exclusions, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only operation with 'Get', but there are no annotations to confirm safety, and it does not disclose what the conversion tag output contains, any permissions needed, or potential side effects. It adds no behavioral detail beyond what the name implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. It is front-loaded with the key verb and object, though it is minimal to the point of under-specification. Conciseness itself is strong, but it sacrifices informative detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is very sparse: no output format, no explanation of what a conversion tag is, and no context on when this tag is used. With no output schema and no annotations, the agent lacks critical information to understand the tool's full behavior and use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the id parameter as 'Campaign ID' (100% coverage), so the description does not need to add much. The description's mention of 'campaign' aligns with the schema, but it adds no additional context about the parameter's format or usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does 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 'conversion tag' for a 'campaign', which is specific and distinguishes it from sibling tools that target zones or placements. However, it does not explain what a conversion tag is or the return format, 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not mention when to use this tool over alternatives like get_zone_conversion_tag or get_placement_conversion_tag, nor does it state any prerequisites such as the campaign needing to 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, the description carries the full burden of behavioral disclosure. It only states what the tool does, not what the returned tag looks like, whether it requires specific permissions, or whether it is a safe read-only operation. The absence of any side-effect or return-format details leaves the agent without important 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no wasted words. It is appropriately concise for a simple getter, though it could have included slightly more detail without harming brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description alone must convey sufficient context. It fails to explain what an 'ad serving tag' is, what format the response takes, or how this relates to the many sibling tag-related tools. For a getter with only one parameter, this level of detail is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully covers the single parameter 'id' with the description 'Catalog zone ID', so the schema already provides the parameter meaning. The tool description adds no additional insight beyond what the schema states, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('ad serving tag for a catalog zone'), which distinguishes it from related tag-fetching tools like get_zone_tag or get_email_zone_tag. It is specific enough to understand the tool's function, though it could be even clearer by mentioning that it fetches a single tag for a single catalog zone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as get_zone_tag or get_vast_zone_tags. It does not mention any prerequisites, context, or exclusion criteria, leaving the agent to infer the correct 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 the full burden of behavioral disclosure. It only states 'Get details of a specific channel,' which implies a safe read but does not explain what 'details' includes, whether authentication is required, what happens on not-found, or the response structure. This is minimal and leaves most behavior opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no wasted words. It is front-loaded with the action and resource. It is concise, though it could have included more contextual guidance without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, no annotations, and a single parameter. The description does not specify what 'details' are returned, nor does it clarify whether this is for regular channels as opposed to VAST or archived variants. Given the large number of channel-related sibling tools, this description is insufficient for an agent to confidently select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the single parameter 'id', described as 'Channel ID'. The description adds no additional semantic value beyond the schema, which is the baseline expectation when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get details of a specific channel' clearly states the verb ('Get') and the resource ('a specific channel'). It is unambiguous about the primary action, but it does not differentiate from sibling tools like 'vast_get_channel' or 'get_archived_channel', which are also channel detail retrievers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention exclusions (e.g., archived channels) or direct the agent to related tools such as 'vast_get_channel' or 'get_channel_zone_assignment'. The intended context is left 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states 'Get' (implying a read operation) but does not clarify whether archived contracts are included, pagination behavior, rate limits, authentication requirements, or the response structure. This minimal disclosure is inadequate given the absence of annotation 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler or redundancy. It is front-loaded and efficient, though it sacrifices explanatory depth for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple getter with one parameter, no output schema, and no annotations. The description provides minimal context about return values, filtering, or edge cases. An agent would not know what the response looks like or what assumptions to make about the data returned, making this incomplete for a tool in a large API surface.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the single parameter 'id' as 'Contract ID', giving 100% schema coverage. The description adds no additional meaning beyond the schema, but since the schema already provides the necessary semantics, the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('campaigns assigned to a contract'), which distinguishes it from generic campaign getters like get_campaign or list_campaigns. However, it does not explicitly differentiate from similar assignment-related tools such as list_campaign_assignments or vast_list_campaign_assignments, which could cause confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 its many siblings, such as list_campaign_assignments, vast_list_campaign_assignments, or get_contract. The description provides no context about prerequisites, alternatives, or when 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 present, so the description carries the full burden of behavioral disclosure. It only states 'Get' and provides no details about return format, whether this returns metadata vs. file content, permissions required, or error behavior. This is an under-disclosed read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the essential operation without wasted words. It is appropriately concise for a simple get operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is not complete enough given the lack of annotations, output schema, and the presence of a closely related sibling tool 'download_contract_document_file_revision'. It does not clarify whether this returns revision metadata or file content, nor does it reference the sibling for comparison, leaving an important gap for correct tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter having a concise description (Contract ID, Document ID, File revision ID). The tool description adds minimal semantic value beyond the schema, which already documents all three parameters clearly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('a specific file revision for a contract document'). It is specific enough to distinguish from broader operations like listing revisions, though it does not explicitly differentiate from the sibling download_contract_document_file_revision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 list_contract_document_file_revisions or download_contract_document_file_revision. The intended use is only implied by the action 'Get', with no exclusions or 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 only indicates a read operation ('Get details') without explaining what fields are returned, whether permissions are needed, or other behavioral traits. This 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the core purpose without wasted words. It could have been more informative, but it is not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 1-parameter read tool with full schema coverage, the description is minimally viable. However, it lacks usage context and any behavioral notes, making it incomplete for disambiguating from similar report tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage by describing the id as 'Report configuration ID.' The description adds no extra parameter context beyond that, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does 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 'details of a specific report configuration,' which aligns with the tool name and differentiates from list-type siblings. However, it doesn't explicitly distinguish from get_vast_custom_report or mention 'custom' 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like list_custom_reports or get_vast_custom_report. The context is only implied by the word 'specific'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavior. It only implies a read-only operation via 'get', but does not state what the report contains, whether it returns aggregated data, how presets/timezone affect results, or any performance implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero wasted words. It is efficiently structured, though the brevity leaves it under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and the presence of many sibling report tools, the description should clarify what the report includes, what preset options exist, and how this differs from other reports. It provides none of that context, making it incomplete for reliable selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters: 'Date preset' and 'Timezone'. The description adds no additional context beyond these terse labels, so baseline 3 applies since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get demand source statistics report' identifies the action (get) and resource (demand source statistics report). It is clear enough to differentiate from sibling report tools like get_display_report or get_geo_summary_report by specifying 'demand source', but it does not elaborate on what statistics are included.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus other report tools or get_demand_source. There is no mention of prerequisites, alternative tools, or specific scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. 'Get' implies a read-only operation, but it does not explicitly state whether this is a safe, non-mutating call, what data is returned, or whether any authentication or rate limits apply. No additional behavioral context beyond the action itself is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, grammatically correct sentence with no redundant words. It is front-loaded with the verb and object, making it easy to scan. However, it is arguably too terse given the vague nature of 'estimate statistics', but it remains appropriately concise in structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a read-style reporting tool with no output schema, so the description must explain what information is returned. It fails to mention the type of statistics, how preset/timezone affect results, or any filtering behavior. Given the large API surface and the existence of similar forecasting tools, this description leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for both parameters (preset and timezone), covering 100% of the schema. The description adds no extra meaning beyond this, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and a specific resource ('display platform estimate statistics'), which clearly indicates the tool retrieves statistics for display platform estimates. It distinguishes from sibling tools like get_vast_platform_estimate via the 'display' qualifier, but the phrase 'estimate statistics' is somewhat vague about what exactly is measured.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_display_forecast or get_vast_platform_estimate. The description does not mention any prerequisites, parameter combinations, or scenarios where this tool is preferred, 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, the description carries the full burden of behavioral disclosure. It only mentions output metrics (impressions, clicks, CTR) and does not disclose required parameters (type, period), whether filters are needed, pagination behavior, or any side effects. This leaves significant behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that directly states the tool's purpose. It is front-loaded with the verb and resource, and there is zero wasted wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 16 parameters and no annotations or output schema, yet the description provides only a one-line summary. It fails to explain what report types are available (e.g., overview, advertiser, publisher), how filters like zones/campaigns interact, or what the response structure looks like. The absence of these details makes it insufficient for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no parameter-specific meaning beyond the output metrics, but the schema already fully documents all 16 parameters with clear descriptions. Thus, the description neither compensates nor detracts.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a display advertising report with impressions, clicks, and CTR, which identifies the resource and key metrics. However, it doesn't distinguish this from other report tools like get_click_details_report or get_geo_summary_report, though 'display advertising' provides some 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/5Does 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 report-related sibling tools, and this description gives no exclusions or context about what makes this report different or when it should be 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?
There are no annotations, so the description must disclose behavioral traits. 'Get details' implies a read operation, but the description does not explicitly state that it is read-only, what data is returned, how errors are handled (e.g., non-existent ID), or any permission requirements. This leaves the agent without essential expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no redundant phrasing. Every word contributes to the core message, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's simplicity, the absence of an output schema and annotations means the description should clarify what 'details' entails and any constraints (e.g., active vs. archived zones). It fails to do so, leaving the agent with an incomplete understanding of the tool's behavior and scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the only parameter ('id' as 'Email zone ID'), achieving 100% schema_description_coverage. The description adds no additional semantic context beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('details of a specific email zone'), making the core purpose apparent. However, it does not distinguish this tool from its sibling 'get_archived_email_zone', which also gets details of an email zone by ID, likely for a different (archived) 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/5Does 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 instead of alternatives such as 'list_email_zones' for enumerating zones or 'get_archived_email_zone' for archived zones. The description offers no context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavioral traits. It only says 'Get live website preview URL' without mentioning side effects, return format, authentication requirements, or any limitations. This lack of detail leaves the agent without insight into what the tool actually does 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short, focused sentence with zero wasted words. All essential information is front-loaded and clearly stated, making it highly concise and properly structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description needs to explain the return value and any constraints. It merely states 'Get live website preview URL' without clarifying the return format, any prerequisites, or how the parameters interact. This is under-specified for a tool that appears to return a URL, especially given the wide variety of sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the two parameters ('Website URL to preview' and 'Zone ID to preview'), so the schema already documents the parameters. The description adds no additional meaning beyond the schema, which is the baseline expected when coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get live website preview URL' uses a specific verb ('Get') and resource ('live website preview URL'), making the tool's function clear. It does not explicitly distinguish from sibling tools, but no other sibling appears to offer preview functionality, so it is reasonably distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no exclusions, and no context about typical use cases. It simply states the function without any usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It only says 'Generate', implying a non-mutating creation of links, but does not clarify side effects, whether anything is stored, return format, or what 'manual' means in practice. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It is appropriately front-loaded, though it lacks structural richness (e.g., sections or examples) that might be expected for a more complex tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is under-specified. It does not explain what manual tracking links are, what the generated output looks like, or any constraints on parameters. This is comparable to a minimal mutation tool description and leaves substantial gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the two parameters (type and ad_item_id), so baseline is 3. The description adds no extra meaning beyond the schema's field names and descriptions; it does not explain how the parameters relate to link generation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Generate'), the resource ('manual tracking links'), and the target ('an ad item'). It is specific enough to convey the core function, though it does not explicitly distinguish itself from related tracking/conversion tag tools among the siblings beyond the 'manual' qualifier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the many other tracking-related tools in the sibling list. There are no context cues, prerequisites, or alternative tool mentions.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 says 'Get details' which implies a read-only operation, but it doesn't disclose what details are returned, error conditions, or access requirements. The description is too minimal to provide meaningful behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded and free of waste. It efficiently states the tool's purpose, though it adds little beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description is too vague. It doesn't explain what 'details' include, what the response looks like, or any edge cases. This leaves a significant gap for such a small tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the 'id' parameter as 'Native template ID', and schema description coverage is 100%. The description doesn't add extra meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get details') and the resource ('a specific native template'), which is specific and unambiguous. However, it doesn't differentiate from the sibling 'get_ortb_native_template', so it lacks 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/5Does 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 compared to alternatives like 'list_native_templates' or 'get_ortb_native_template'. No context, prerequisites, or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. The verb 'get' implies a read-only operation, but the description does not disclose what 'details' are returned, whether special permissions are needed, or any error behavior. No behavioral traits beyond the basic read implication are shared.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the action and resource. Every word earns its place, and there is no unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple with one parameter and no output schema, the description is not complete. It fails to specify what details are included in the response and does not clarify how this differs from the many sibling placement-getter tools. The lack of return-value information and domain context makes it insufficient for an agent to confidently select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema documents the single 'id' parameter with a clear description, and the schema coverage is 100%. The description's 'specific placement' aligns with the parameter but adds no additional meaning about parameter formatting or constraints beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does 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 'placement', with 'specific' implying lookup by ID. However, it does not distinguish from sibling tools like vast_get_placement, vast42_get_placement, or draft_get_placement, making it ambiguous which placement entity it refers to.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as list_placements or vast_get_placement. It simply states what it does without contextual 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 responsibility for behavioral disclosure. It only implies a read operation via the verb 'Get' but does not describe the returned tag format, permissions required, or any side effects. This is a minimal behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundancy. It is front-loaded and efficient, though it forgoes opportunities to add valuable context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), a longer description is not strictly required. However, the large number of similar conversion tag tools and the absence of return value details make the description incomplete for reliable tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage for the single parameter 'id' with the description 'Placement ID'. The tool description adds no additional parameter semantics, but the schema already sufficiently documents the parameter, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific verb ('Get'), resource ('conversion tracking tag'), and scope ('for a placement'). It clearly conveys the core functionality, though it does not explicitly distinguish from sibling tools like get_vast_placement_conversion_tag.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the many similar conversion tag getters (e.g., get_zone_conversion_tag, get_campaign_conversion_tag). There is no mention of alternatives 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 must carry the behavioral disclosure burden. It only says 'Get details' without indicating whether archived publishers are included, what fields are returned, or how errors are handled. This 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no wasted words. It is front-loaded with the action and resource, which is appropriate for a simple get operation. However, it is slightly under-specified but still concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of related tools (get_archived_publisher, list_publishers), the description does not clarify its scope (e.g., active vs. archived) and with no output schema it does not hint at the return payload. For a tool with such simple parameters, it is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the only parameter (`id` as 'Publisher ID'), and schema description coverage is 100%. The description adds no extra semantic meaning beyond what the schema already provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get details of a specific publisher' clearly states the action (get) and resource (publisher), and 'specific' implies retrieval by ID, which aligns with the single `id` parameter. However, it does not distinguish between active and archived publishers (get_archived_publisher exists), so it misses the sibling differentiation needed for 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like list_publishers or get_archived_publisher. There are no mentions of active vs. archived publishers, nor any exclusions or prerequisites, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states 'Get details,' which implies a read operation but does not explain error handling, authentication requirements, or response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is appropriately concise for a simple get operation, though it could include slightly more context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema or annotations, the description should provide more context about return values or edge cases. The one parameter is documented in the schema, but the description offers no additional information about what 'details' includes, making it incomplete for a tool with no other structured context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the single parameter 'id' with a description ('Creative ID'), achieving 100% schema description coverage. The description adds no extra semantic detail beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get details') and the specific resource ('rich media creative'), which distinguishes it from generic get_creative and list_rich_media_creatives. However, it does not explicitly name alternative tools for differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus get_creative or get_rich_media_ad_item. There is no mention of prerequisites, exclusions, or alternative selection, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Get a single user' without mentioning what is returned, what happens if the user is not found, permissions required, or any side effects. This is minimal and insufficient for transparent 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence of 8 words, front-loaded with the verb 'Get' and the resource 'single user'. Every word earns its place; there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description must explain what the tool returns and any important behavior. It only says 'Get a single user', which does not specify the return format, error conditions, or that both IDs are required. This is insufficient for an agent to fully understand the tool's capabilities for a simple getter with no structured output metadata.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the parameter descriptions ('User ID', 'User database ID') are tautological. The tool description adds a bit of context by saying 'from a user database', which implies the relationship between user_db_id and user_id. This provides marginal added meaning beyond the schema, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a single user from a user database' clearly states the verb (get), resource (user), and scope (from a user database). It distinguishes from sibling tools like get_user_db (which retrieves a database) and other get_* tools by specifying the source context. However, it does not explicitly name alternatives or contrast with them, so it falls short of 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as get_user_db, get_user_attribute, or list_user_attributes. The description does not mention any prerequisites, exclusions, or alternative tools, leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Get' implies a read operation, but it does not explain what is returned, whether the report is a custom report definition or generated output, or how errors like a non-existent ID are handled.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence with no filler, making it highly concise and front-loaded. The word 'specific' is somewhat redundant given the singular parameter, and 'VAST report' could be more precise as 'custom VAST report', but overall it is compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter GET tool, the description is minimal but lacks critical context: it does not mention that this tool retrieves custom reports (despite the tool name), how it differs from other report-related tools, or what the response contains. Without an output schema, more description is needed to make the tool safely usable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes the single 'id' parameter as 'VAST report ID' (100% schema description coverage). The description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Get') and the resource ('a specific VAST report'), and the singular wording implies retrieval by ID. However, it does not differentiate from sibling tools like get_vast_report or get_custom_report, and the word 'custom' from the tool name is omitted, creating potential 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_vast_report, list_vast_custom_reports, or get_report_generated. The description only states what it does, not when it should be chosen.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must convey behavioral context. It only states the list operation without disclosing pagination behavior, response format, or that only archived email zones are returned (implied by the name). This adds minimal value beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The single-sentence description is very concise with no wasted words. It is front-loaded with the primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description is too sparse to fully guide an agent. It lacks context about when to choose this tool over similar list tools, and there is no mention of how the list is ordered or whether the offset/limit are required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents both parameters with descriptions (limit and offset). The description adds no parameter-specific semantics, so the schema carries the full burden. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does 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 (archived email zones), making the tool's purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like list_archived_zones or list_email_zones, though the resource name is specific enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 exclusions, prerequisites, or suggest alternative tools for other scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description adds no behavioral context beyond what the name implies. It does not disclose whether the operation is read-only (though 'list' suggests it), whether 'all' implies no filtering, or any pagination or response characteristics beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundant wording. Every word is necessary to convey the basic action and resource, making it appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description is too minimal to be complete. It fails to clarify what catalog ad items are, how this relates to the many sibling ad-item listers, or what the response format looks like, leaving the agent with significant ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the two parameters (limit and offset), so the schema fully documents them. The description itself adds no additional parameter meaning, meeting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does 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 ('catalog ad items'), making the basic purpose evident. However, it does not differentiate this from sibling tools like draft_list_catalog_ad_items or list_ad_items, so it 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as draft_list_catalog_ad_items or list_ad_items. No context, exclusions, or alternative tool mentions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It states 'List all' but does not disclose pagination behavior, default limits, or that results are paged despite the presence of limit/offset parameters. The word 'all' could mislead an agent into expecting a single complete list.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, which is appropriately sized for a simple list operation. However, the word 'all' is slightly ambiguous and could have been qualified to avoid confusion with pagination.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description should provide more context. It fails to explain what a channel zone assignment is, what fields are returned, or how pagination works, leaving the agent with insufficient information for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides full descriptions for the limit and offset parameters, so the description does not need to add much. The description adds no extra meaning about how these parameters affect results, but this is acceptable given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and identifies the resource 'channel zone assignments', making the basic purpose clear. However, it does not distinguish itself from the sibling tool 'vast_list_channel_zone_assignments', which appears to serve a similar function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as get_channel_zone_assignment or the vast_ variant. No context or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It implies a read-only operation but provides no context on pagination, response format, filtering, or whether archived contracts are included.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded and captures the core purpose. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description is too terse to be complete. It misses expected return values, pagination behavior, and the distinction from archived contracts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents both parameters (limit and offset) with descriptions and defaults, so the description adds no additional meaning. Baseline of 3 is appropriate due to high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does 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 ('contracts'). However, it does not differentiate from sibling tools like 'list_archived_contracts' or 'get_contract', and 'all' is ambiguous regarding whether archived contracts are included.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention whether it is appropriate for listing all contracts, only active contracts, or how it relates to list_archived_contracts.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 of behavioral disclosure, but it only states 'List all contract templates' without mentioning pagination, default limit, return format, or whether archived templates are included. The word 'all' somewhat conflicts with the limit/offset parameters, though not explicitly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, front-loaded with the action and resource. It is appropriately concise and easy to parse, though extremely brief.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is incomplete. It fails to explain when to use this tool over similar list operations, what the response contains, or how pagination behaves beyond the parameter descriptions. The agent would need to infer too much.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides full descriptions for both limit and offset (100% schema coverage), so the baseline is 3. The description adds no additional meaning beyond the schema, but neither does it need to given the schema's completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all contract templates' clearly specifies the verb (list) and resource (contract templates), making its purpose unambiguous. It distinguishes itself from related tools like get_contract_template and list_contracts by naming the exact resource, though it doesn't explicitly mention 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/5Does 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 such as list_contracts or list_contract_documents. There are no exclusions, prerequisites, or contextual hints provided, leaving the agent without direction for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations provided, so the description must fully disclose behavior. It only states 'List all custom HTML ad items' with no information about filtering, pagination behavior, whether archived or draft items are included, or any read-only guarantees. The response format is also not mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, extremely concise with no wasted words. It effectively communicates the core purpose without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description carries the full burden. It only states the basic purpose and relies on the schema for pagination, but fails to describe the return structure, any default behavior (e.g., including all items vs. paginated), or scope (e.g., all in the account vs. specific campaign). For a simple list tool, this is minimal but lacks useful context like whether it returns archived or draft items.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters (limit and offset) with descriptions, giving 100% schema coverage. The description adds no additional parameter context, but the schema provides sufficient meaning, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all custom HTML ad items' clearly identifies the action (list) and the resource type (custom HTML ad items), which distinguishes it from list tools for other ad item types like list_image_ad_items. However, it does not explicitly state whether this is the non-draft/live version, which is a minor ambiguity given the existence of draft_list_custom_html_ad_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/5Does 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 such as list_ad_items (which may include all types) or draft_list_custom_html_ad_items. The description lacks any comparison or context to help the agent choose the correct list tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavioral traits. It states 'List all' but does not mention pagination via limit/offset, which is slightly misleading. It also omits any mention of read-only safety, permissions, or return format. The description adds minimal value beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with a useful parenthetical, containing zero filler. It is appropriately front-loaded and easy to parse. However, it sacrifices some informational value for brevity, so it doesn't earn a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation, the description provides enough to understand the core purpose. However, the lack of output schema and annotations means the description should clarify return behavior and usage context, which it does not. The mention of 'all' contradicts the pagination parameters, leaving gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters (limit and offset) with clear descriptions, achieving 100% coverage, so the baseline is 3. The description does not add any parameter-specific meaning, but none is required given the schema's completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a list operation on 'data key targets' and adds a parenthetical explaining what they are ('targeting rules using data key values'), which disambiguates from other target types. However, it does not explicitly differentiate from similar sibling tools like list_data_targets, which also list targets, so it falls short of 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/5Does 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. Given the large number of sibling list tools (e.g., list_data_targets, list_geo_targets), the description offers no context on selection criteria or exclusions, leaving the agent to infer usage purely from the 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 the full burden of behavioral disclosure. It simply says 'List all data targets' with no mention of pagination, default limit, read-only nature, or what a 'data target' is. For a list operation, it implies a safe read, but fails to provide details on behavior 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant words. It is front-loaded and easy to scan. However, it is so minimal that it underspecifies, but under-specification is not the same as verbosity; conciseness itself is high.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with two optional pagination parameters, the description is minimally adequate. However, without annotations or an output schema, it does not explain what constitutes a 'data target' nor confirm the return format, which is a modest gap for a tool among many similar listing tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage: 'limit' and 'offset' are both self-explanatory with descriptions. The tool description adds no parameter information, but the schema already provides clear semantics. Baseline score of 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb 'List' and a specific resource 'data targets' with scope 'all', clearly indicating the operation. However, it does not explicitly differentiate from many similar list_* sibling tools (e.g., list_data_key_targets, list_product_source_targets), relying on the resource name to distinguish. It is clear but not fully distinguished from 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/5Does 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 is no mention of prerequisites, exclusions, or relationship to similar listing tools. It only states what it does, not when or why to choose 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 the full burden, but it only states the core action. It does not disclose whether this is a read-only operation, whether archived placements are included, how results are ordered, or any other behavioral characteristics. This is a significant gap for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states purpose with no filler or repetition. It earns its place efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple, the description lacks crucial context such as the distinction from other placement-list tools, filtering capabilities, ordering, and whether archived items are included. The presence of multiple sibling list variants makes this ambiguity more problematic, leaving the description incomplete for reliable selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents both parameters (limit and offset) with descriptions and 100% coverage. The description adds no parameter-level detail beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists placements and defines what a placement is (assignments of ad items to zones). It conveys the verb, resource, and scope ('all'). However, it does not differentiate this from similarly named sibling tools like vast_list_placements or draft_list_placements, so it's not fully distinguishing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus siblings such as vast_list_placements or draft_list_placements. There is no mention of exclusions, prerequisites, or preferred contexts, leaving the agent without selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry full behavioral disclosure, but it only says 'List all schedules.' It does not clarify the scope (e.g., account-wide vs global), pagination behavior, or read-only nature beyond the verb's implication. This minimal disclosure 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence of seven words, containing zero fluff. It is appropriately concise for a simple list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the large number of sibling schedule tools (vast_list_schedules, draft_list_schedules, list_report_schedules, etc.), the description lacks crucial contextual differentiation. It does not explain when to use this tool over alternatives or indicate what the response contains, making it incomplete for an agent to select the correct list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with clear descriptions for both 'limit' and 'offset,' so the baseline is 3. The description adds no additional parameter semantics beyond what the schema already offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all schedules and defines them as time-based delivery rules for ad items. It uses a specific verb+resource, but it does not explicitly differentiate from sibling tools like vast_list_schedules or draft_list_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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided for when to use this tool versus the many sibling schedule tools, such as vast_list_schedules or draft_list_schedules. There is no mention of context, prerequisites, or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention pagination, response limits, scope (e.g., whether it lists creatives across all advertisers or a specific context), or any other behavioral traits beyond the bare act of listing. The word 'all' is vague and unexplained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence with no unnecessary words, making it concise and front-loaded. It is not verbose, but its brevity also means it omits potentially useful context, keeping it from a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the simple schema, the description leaves out important context: it does not explain what 'video creatives' refers to in this system, how pagination works (though it is implied by the schema), what the response contains, or how this tool relates to other creative listing tools. The absence of an output schema increases the need for description, which is unmet.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for both parameters (limit and offset), covering 100% of the parameter space. The description adds no additional parameter semantics, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the operation ('List') and the resource ('video creatives'), making the basic purpose understandable. However, it does not differentiate this tool from closely related siblings such as 'list_creatives' or 'list_all_creatives', so it stops short of 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives like 'list_creatives' or 'get_video_creative'. The description only states the function without any contextual hints, exclusions, or alternative suggestions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of disclosing behavioral traits. It implies a destructive operation ('Remove all usages') but does not state whether this is reversible, what specific usages are affected, or what consequences occur (e.g., whether the list target itself is retained). This is a significant transparency 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words or repetition. It is concise and front-loaded, communicating the core action immediately. Given the simple tool signature, this brevity is appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given 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 and no output schema, the description is incomplete. It does not explain what a 'list target' is, what 'usages' refers to, or what happens after removal. The single parameter is covered, but missing behavioral context leaves the description insufficient for an agent to safely and confidently invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the single 'id' parameter with a clear description ('List target ID'), achieving 100% schema coverage. The tool description adds no additional parameter semantics beyond the schema, but this meets the baseline for adequate parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove') and the resource ('all usages of a list target'), which distinguishes it from the sibling 'delete_list_target' tool. However, 'usages' is a somewhat vague term that isn't elaborated, leaving some ambiguity about what exactly is removed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that this is for cleaning up references to a list target as opposed to deleting the target itself, nor does it reference any sibling tools like 'delete_list_target' or 'update_list_target'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description is the sole source of behavioral info. It only says 'Replace' without disclosing how the file is supplied (no file parameter in schema), whether the operation is reversible, what happens to the old file, or any permission requirements. This is a significant transparency gap for a mutating 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant phrases. It is front-loaded and efficient, containing only the essential verb and resource. This is ideal conciseness for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It does not explain how the file replacement is executed (given only an id), what response to expect, or any side effects/prerequisites. Significant contextual information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the only parameter 'id' as 'Creative ID', covering 100% of parameters. The description adds no additional parameter meaning, but since schema coverage is high, the baseline of 3 is appropriate; the description doesn't need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Replace') and resource ('audio creative'), which clearly distinguishes it from sibling replacement tools (e.g., replace_video_creative_file, replace_image_creative_file). However, 'the file' is slightly vague—it could specify 'audio file' for complete 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/5Does 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 replace_video_creative_file or update_audio_creative. The description does not mention any prerequisites, exclusions, or comparison to other tools, leaving the agent to infer 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 present, so the description carries full responsibility for disclosing behavioral traits. It only says 'Replace', which implies mutation but does not clarify whether the original file is overwritten, whether a new revision is created, what template is used, or any permission requirements. This is a significant gap for a destructive-sounding 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence. It is appropriately sized and front-loaded, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations and no output schema, so the description must fully explain its behavior. It does not, leaving key questions unanswered (e.g., how the template is selected, what 'replace' does to the existing file, whether it is reversible, what the response contains). For a mutation tool with minimal schema, this is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the two parameters (contract_id, document_id), but the descriptions are trivial ('Contract ID', 'Document ID'). The tool description adds no semantic meaning beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Replace), the object (contract document file), and the source (from a template). It differentiates from siblings like create_contract_document_from_template and replace_contract_document_file by combining both concepts, though it does not elaborate on what 'from a template' precisely 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/5Does 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 conditions, prerequisites, or exclusions. Sibling tools exist (e.g., replace_contract_document_file, create_contract_document_from_template) but no differentiation is offered.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 updates a key, but does not mention side effects, whether the operation is idempotent, required fields, permissions, or what happens if the key does not exist. This is minimal 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence with no wasted words. It is front-loaded and easy to parse, though it provides minimal information. It is appropriately concise, but not a model of thorough description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is too sparse. It does not clarify whether the update is partial or full, does not indicate that 'id' is required, and gives no sense of the response or side effects. The simplicity of the schema partially compensates, but the description leaves key usage questions unanswered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and both 'id' and 'key_name' have clear descriptions in the schema. The tool description adds no additional parameter semantics, so it stays at the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an existing beacon signing key' gives a specific verb (update) and resource (beacon signing key), clearly distinguishing it from create/delete/get/list operations. However, it does not differentiate it from sibling tools beyond the verb itself, so it falls short of 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/5Does 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 vs alternatives. The description merely states what it does, with no mention of prerequisites, exclusions, or pointers to create/delete/validate tools. The usage context is only implied by the tool's name and verb.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 of behavioral disclosure, but it only says 'Update an existing bidder.' It does not reveal whether the update is partial (PATCH) or full replacement, what happens if the bidder does not exist, authentication/permission requirements, or any side effects. The only implicit behavioral trait is that the bidder must already 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no filler words or repetition. It is appropriately short, though it under-specifies. Given its brevity, it earns a high score for conciseness, but the structure is minimal with no additional context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It fails to mention that the id parameter is required to identify which bidder to update, that other fields are optional updates, or what the response/return behavior will be. This is a significant gap for a tool that can modify an existing resource.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with descriptions for all four parameters (id, name, status, bid_url). The description adds no additional meaning beyond the schema, so it meets the baseline for high schema coverage but does not enhance understanding of parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an existing bidder' clearly identifies the verb (update) and resource (bidder), and the word 'existing' distinguishes it from create_bidder. However, it does not specify which fields can be updated, relying entirely on the schema to convey 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of create_bidder for new bidders, delete_bidder for removal, or any conditions under which updating might be inappropriate. The description simply restates the tool's function without contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 of behavioral disclosure. It only states 'update' without explaining whether this is a partial update (PATCH) or full replacement (PUT), what happens to unspecified fields, or any side effects. This is a significant gap for a mutating 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded and wastes no words. It clearly states the primary purpose, though it may be under-specified for a tool with 10 parameters. Still, as a concise statement of purpose, it earns a high score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations, no output schema, and 10 parameters, but the description gives only a minimal one-liner. It lacks context about return values, partial update behavior, required permissions, or any limitations. This is inadequate for an update operation in a complex API.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, with descriptions for all 10 parameters, so the schema already provides comprehensive parameter semantics. The description adds no additional parameter-level context, but the baseline of 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (update) and resource (campaign assignment), and specifies 'existing' to indicate this is not for creating. However, it does not differentiate from sibling tools like vast_update_campaign_assignment, but the name itself provides some disambiguation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as create_campaign_assignment or the vast/draft variants. The description offers no context about common use cases, prerequisites, or scenarios where this should be 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 must disclose behavioral traits. It only says 'Update an existing catalog ad item' but does not mention whether the update is partial, if the item must exist, side effects, or the response format. For a mutation 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no extraneous words. It is efficient but extremely brief, bordering on under-specification. Still, it earns a 4 because it is genuinely concise without being a tautology.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 7 parameters and a sibling draft workflow, the description could have provided more context (e.g., live vs draft updates, whether all fields are optional). The schema covers parameter details, but the description misses key behavioral and workflow context, making it adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, meaning all 7 parameters (id, name, location, metadata, etc.) are already documented. The description adds no extra semantic value beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does 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 catalog ad item'), making the tool's function obvious. However, it does not distinguish this from the sibling 'draft_update_catalog_ad_item' tool, so it is not fully differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 'draft_update_catalog_ad_item' or other update tools. It lacks any context about workflows, prerequisites, or conditions that would help an agent choose this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states that an update occurs, but does not mention partial vs. full replacement, whether missing optional fields are cleared, error behavior for non-existent IDs, return values, or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence is appropriately sized for a simple update operation. It is front-loaded with the verb and resource, containing no unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having a simple schema with full parameter coverage, the tool has no annotations, no output schema, and a minimal description. Missing details about update semantics (e.g., idempotency, partial update behavior, response format) leave the description incomplete for an agent to use confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all 4 parameters with descriptions, providing 100% coverage. The tool description adds no parameter-level detail, but the baseline of 3 applies because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an existing contact' uses a specific verb and resource, clearly indicating the operation. It differentiates from sibling tools like delete_contact and create_contact, though it doesn't elaborate on which fields can be updated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. The word 'existing' implies it's not for creating new contacts, but there is no explicit context, prerequisites, or exclusions 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, and the description only repeats the verb 'update' without detailing behavior such as which fields can be modified, partial update semantics, error handling, or authentication requirements. This leaves the agent without crucial behavioral context for a mutating 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and is concise without filler. It is efficient and front-loaded, but it is so minimal that it sacrifices informative content, which justifies a 4 rather than a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a crowded domain with similar tools, the description is incomplete. It fails to clarify the specific update behavior (e.g., only 'name' is updatable) or differentiate it from replace_contract_document_file.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters have descriptions in the schema (100% coverage), so the schema itself provides semantics. The description adds no additional parameter context, but the baseline of 3 applies because the schema is sufficiently descriptive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that this tool updates an existing contract document, using a specific verb and resource. However, it does not differentiate from sibling tools like replace_contract_document_file or update_contract, so it 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/5Does 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 is no mention of use cases, prerequisites, or exclusions, leaving the agent to infer when to select this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states 'Update an existing custom HTML ad item' without explaining partial vs full update semantics, return values, required permissions, or any side effects. This is insufficient for an update 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that is concise and front-loaded. It avoids unnecessary words, though it could be slightly more informative without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the high parameter count (13) and no output schema, the description provides no context about update behavior, return format, or relationship to other tools. It leaves important operational details unspecified, making it incomplete for an agent to use effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage for all 13 parameters, so the baseline is 3. The tool description adds no additional parameter information beyond the schema, which is acceptable but does not enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does 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 ('existing custom HTML ad item'), which distinguishes it from create/delete tools. However, it does not differentiate from the sibling tool 'draft_update_custom_html_ad_item', leaving ambiguity about live vs draft 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, whether this affects live or draft items, or how it differs from the draft update sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 for behavioral disclosure. It only states that it updates an existing report, but does not clarify partial vs full update semantics, whether unspecified fields are preserved or reset, or what the response contains. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, directly front-loaded with the action and object. Every word is necessary and no filler is present, 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite a detailed schema, the description lacks critical behavioral context for an update operation. It does not explain whether the update is partial (only provided fields) or full replacement, what happens to omitted fields, or whether the updated configuration is returned. The absence of annotations and output schema makes the description insufficient for a tool with 11 parameters and nested objects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all 11 parameters, so the schema already provides parameter meaning. The description adds no additional parameter semantics beyond what the schema offers, warranting the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does 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 ('existing report configuration'). It distinguishes from create/delete/list siblings through the verb and 'existing', but does not explicitly differentiate from update_report_schedule, which is a separate resource. The name 'custom_report' helps disambiguate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not specify when to use this tool vs alternatives like create_custom_report or update_report_schedule, nor does it mention prerequisites or exclusions. Usage must be inferred solely from the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description should disclose mutation behavior. It merely states 'update' without explaining partial update semantics, idempotency, permission requirements, or return values. The optional label parameter suggests partial update, but this is not stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no wasted words. However, the brevity sacrifices critical context, so it earns a 4 rather than 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter CRUD tool, the description is minimally adequate, but it lacks information about return values and update behavior. Given no output schema or annotations, it should disclose more about the operation's outcome.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters (id and label) with 100% coverage. The description adds no parameter semantics, but the baseline of 3 is appropriate since the schema handles the definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates an existing data list, using a specific verb and resource. It distinguishes from create/delete/bulk operations by the verb 'update', though it does not elaborate on which attributes can be updated, relying on the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like create_data_list, delete_data_list, or bulk_upload_replace_data_list. The description does not specify prerequisites or whether this is for single-record updates only.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 that an update occurs, but does not clarify whether missing fields are left unchanged or reset, whether the operation is a partial or full replacement, or what happens if the id does not exist. This lack of detail could lead an agent to assume unsafe 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that avoids fluff. It is not tautological like 'Process', but it is so minimal that it skips useful scope information. It could have been slightly more informative without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the schema (6 params, nested 'areas' object) and no annotations or output schema, the description is under-specified. It does not mention that only 'id' is required, how to clear optional fields, or any constraints (e.g., whether 'range' must be provided if 'unit' is set). An agent would need to infer update semantics from the schema alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter described (e.g., 'inclusive' explains true/false semantics). The description itself adds no parameter-level meaning, so the baseline of 3 is appropriate. The schema makes the parameters self-explanatory, but the description could have highlighted relationships like the dependence of 'range' on 'unit'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an existing geo target' clearly identifies the action (update) and resource (geo target), distinguishing it from create/delete/get/list siblings. However, it omits any specifics about the scope of updates (e.g., which fields are modifiable), relying on the schema to fill in that detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternative targeting tools such as update_postal_code_target or update_list_target. It also does not mention any prerequisites, such as requiring the geo target to exist, or that this tool should be used for modifying geographical targeting rules rather than other targeting types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of explaining behavior. It merely says 'Update an existing list target' without disclosing whether it performs a partial or full update, what happens if the ID doesn't exist, or any side effects. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and to the point, with no wasted words. It is front-loaded with the verb and resource. However, it is so terse that it omits useful context, though conciseness itself is well-handled.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is too minimal. It doesn't mention which fields can be modified (label, data_list, inclusive), whether the update is partial or full, or any behavioral outcomes. The schema helps, but the description fails to provide operational context needed for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all 4 parameters, and coverage is 100%, so the schema already documents them well. The description adds no extra semantic meaning about parameters, but since the schema is complete, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and resource ('list target'), and the word 'existing' distinguishes it from creation tools like create_list_target. However, it lacks specifics about what aspects of the list target can be updated, so it doesn't fully differentiate from other update_* 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as create_list_target or delete_list_target. There is no mention of prerequisites, typical scenarios, 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?
With no annotations, the description carries the full burden of behavioral disclosure. It only states that the template must be 'existing', but does not explain whether updates are partial or full, what happens to unspecified fields, required permissions, or side effects. No additional behavioral context is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately conveys the core action. Every word is purposeful, and there is no redundant or filler content, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (mutation operation, no annotations, no output schema, and multiple sibling tools with similar names), the description is under-specified. It fails to explain update semantics, response behavior, or how it differs from 'update_native_template', leaving the agent with insufficient contextual information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for all 3 parameters, each with descriptions. The description itself does not reference parameters, but the schema already provides the necessary semantics, so the baseline of 3 applies without any added value from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Update' and the resource 'existing OpenRTB native template', making the action unambiguous. However, it does not explicitly distinguish from the sibling tool 'update_native_template', which could create confusion despite the 'OpenRTB' qualifier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'update_native_template' or 'create_ortb_native_template'. It only implies usage by saying 'existing', but doesn't state when to prefer this over other update tools or mention any 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 present, so the description carries full responsibility for behavioral disclosure. It reveals that the operation modifies an existing placement, but does not discuss partial-update semantics, authorization requirements, effects on active delivery, or reversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no fluff. It is concise and clearly states the core function, though it is somewhat terse and could benefit from additional context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (19 parameters, nested objects, enums, multiple update variants) and the absence of annotations and output schema, the description is far too sparse. It fails to clarify which fields are mutually exclusive (e.g., zone vs. channel) or what the update behavior is, leaving the agent under-informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with every parameter having a meaningful description. The tool description itself adds no parameter-level detail, but the schema already provides rich semantics, meeting the baseline for this dimension.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does 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 ('existing placement'), making it obvious the tool modifies a placement. However, it does not distinguish between the several placement update variants in the sibling list (e.g., vast_update_placement, draft_update_placement), so differentiation is lacking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 only implies 'use when updating a placement,' but offers no exclusions, prerequisites, or comparisons to sibling update 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. It only states that an update occurs, without revealing whether the update is partial or full replacement, whether it is destructive, what permissions are needed, or what response is returned. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence, 'Update an existing product catalog', with no superfluous words. It is appropriately front-loaded and every word earns its place. This is an efficient, if minimal, structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 parameters, no output schema, and no annotations. The description is too brief to be complete: it does not explain what fields can be changed, the role of publisher_id in identification, or any behavior after the update. For a mutation tool, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter already has a basic description (Catalog name, Catalog ID, Publisher ID). The description adds no additional parameter semantics beyond what the schema provides. The baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb+resource construction: 'Update an existing product catalog'. It distinguishes the tool from create and read operations, and from update_product_catalog_item which targets catalog items. However, it does not mention specific updatable fields (like name) or that catalog_id and publisher_id identify the target.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like create_product_catalog or update_product_catalog_item. It does not state prerequisites (e.g., needing an existing catalog) or any exclusions. No contextual usage hints are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'update' but does not explain whether it performs a partial or full update, what happens if the item does not exist, or any permission requirements. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler or redundant information. It is front-loaded and 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is too sparse to be fully complete. It does not explain update behavior, response format, or error scenarios, and it does not differentiate from related catalog tools, leaving the agent with gaps in understanding how to correctly use this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all 9 parameters, so the schema already documents each field. The description adds no additional parameter semantics beyond the generic 'product catalog item' context, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'update' and the resource 'product catalog item', which accurately conveys the tool's function. However, it does not distinguish itself from sibling tools like create_product_catalog_item or get_product_catalog_item, so it 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or context. It only states what the tool does, leaving the agent to infer usage 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?
No annotations are provided, so the description carries the full burden. It only states that the tool updates an existing resource, with no disclosure of partial update semantics, permission requirements, or behavior on nonexistent IDs, which is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no extraneous words, earning efficiency points. It lacks structure or additional context, but it is not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter mutation tool with no annotations and no output schema, the description is under-specified. It fails to explain whether the update is partial or full, what the response looks like, or any side effects, making it minimally adequate for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all four parameters, giving 100% coverage, so the baseline is 3. The description adds no extra parameter meaning, but the schema already explains each field adequately, though tersely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does 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 'product source target', with the word 'existing' distinguishing it from creation. However, it does not explicitly differentiate from other product-related update tools, though the sibling list suggests a CRUD family.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites, when to prefer update over create or delete, or what identifiers are necessary beyond the required parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It merely says 'update an existing role' without mentioning whether fields are partially updated or reset, what permissions are required, what the response contains, or any side effects. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. It is front-loaded and easy to parse. While it is minimal, it earns its place by stating the core action clearly without filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (21 parameters, no output schema, no annotations), the description is far too incomplete. It does not explain update behavior, return values, prerequisites, or how this tool relates to role management workflows. The schema covers parameter names but not operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of the 21 parameters with descriptions, so the baseline is 3. The description adds no additional parameter meaning beyond the schema, such as update semantics or how omitted fields are treated. It does not compensate for or enhance the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an existing role' clearly states the action (update) and resource (role), and the word 'existing' distinguishes it from create_role. However, it is a minimal restatement of the tool name and adds no scope or detail beyond the action, so it falls short of a fully informative purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as get_role, create_role, or delete_role. It only implies that the role must already exist, but it does not mention prerequisites, related tools, or situations where this tool should or should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It does not state whether the update is partial or full, what happens to unmentioned fields, authentication/permission requirements, or error behavior. 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no extraneous words. It is concise and efficient, though it also under-specifies the operation's scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 7-parameter mutation tool, no annotations, and no output schema, the description is too sparse. It does not explain update semantics (e.g., whether omitted fields are preserved), error handling, or response format, leaving critical context missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all 7 parameters, so the schema already documents each field. The description adds no parameter-level detail, so the baseline of 3 applies. The optionality of fields is derivable from the schema's required list.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does 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 ('SFTP connection'), indicating it modifies an existing connection. It implies the distinction from creation via 'existing', but does not explicitly differentiate it from sibling tools like create_sftp_connection or delete_sftp_connection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as create_sftp_connection, delete_sftp_connection, or test_sftp_connection. There is no mention of prerequisites, workflows, or cases where an update would be 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action ('Update') without explaining side effects, permission requirements, whether the update is partial or full replacement, or what the response format looks like. 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that is easy to parse and avoids unnecessary fluff. It is appropriately concise for a straightforward CRUD operation, though it could be slightly more informative without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations or output schema, so the description needs to provide context. It does not explain update semantics (partial vs full), the required fields (beyond id in schema), or what the response contains. The description is minimal and leaves the agent with limited guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents all three parameters with descriptions (100% coverage). The tool description adds no parameter-specific meaning beyond the schema, so the base score of 3 is appropriate given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the verb ('Update') and resource ('existing video creative'), which is specific to the video creative type. However, it does not differentiate from the generic update_creative sibling or list the updatable fields, so it is clear but not fully distinguishing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the generic update_creative, update_audio_creative, or other siblings. It does not mention prerequisites, idempotency, or scenarios where this should be preferred, and no alternatives or exclusions are noted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only states 'Update an existing standard zone.' It does not reveal whether the update is partial (PATCH-like) or full replacement, what happens to unspecified fields, permission requirements, or effects on dependent entities. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero wasted words. It states the core purpose immediately, which is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a high-complexity mutation tool with 27 parameters, nested objects, no annotations, and no output schema. The one-line description does not cover update semantics, partial-vs-full replacement behavior, or how to select this tool among numerous zone-related siblings. The schema covers parameter definitions but not the operational context the agent needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no parameter-level meaning beyond the schema, which already documents all 27 parameters with individual descriptions. No credit loss, but no added value either.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Update') and resource ('standard zone'), clearly stating the tool's function. The qualifier 'standard' hints at differentiation from sibling zone tools (vast_update_zone, update_email_zone, update_catalog_zone), though it does not explicitly name them or explain what 'standard' excludes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers essentially no guidance on when to use this tool versus alternatives. It lacks any mention of prerequisites, exclusions, or sibling tools like vast_update_zone or create_zone. The word 'standard' weakly implies a category but does not provide clear decision 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 only indicates 'Create' (a mutation) but does not mention whether existing campaign/ad_item references are validated, what response format to expect, or whether the operation has side effects. This leaves significant behavioral context undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or repetition. It efficiently conveys the core action and resource, earning full marks for conciseness and structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 optional parameters, no output schema, and no annotations, the description is too sparse. It lacks context about the meaning of a 'campaign assignment', how it relates to VAST 4.2 specifics, and when to use this over the sibling 'draft_create_campaign_assignment' or non-versioned 'create_campaign_assignment'. The minimal detail under-serves the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes all three parameters (active, ad_item, campaign) with 100% coverage, so the baseline is 3. The description adds no additional meaning to the parameters, but the schema already provides adequate semantic context for each field.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Create') applied to a specific resource ('VAST 4.2 campaign assignment'), which distinguishes it from read/update/delete siblings. However, it does not explicitly differentiate from the non-versioned 'create_campaign_assignment' or the 'draft_create_campaign_assignment' tools, relying on the name prefix.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the many related sibling tools (e.g., draft_create_campaign_assignment, create_campaign_assignment, vast42_update_campaign_assignment). The description merely restates the purpose without any contextual hints about prerequisites or workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral information beyond the name itself. It does not disclose potential side effects, required permissions, uniqueness constraints, or return values. Since there are no annotations, this leaves agents without critical execution 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler. It is highly concise and front-loaded with the essential verb and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, this minimal description is insufficient. It does not explain what a VAST 4.2 closed caption file is, what language codes are accepted, whether names must be unique, or what the response will contain. For a create operation, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not elaborate on the parameters. However, the input schema already provides descriptions for both 'name' and 'language' (100% coverage), so the description adds no additional semantic value. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create) and the resource (VAST 4.2 closed caption file). It is specific enough to distinguish from sibling list/get/update/delete tools, though it does not explicitly reference 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/5Does 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 alternative operations, nor any prerequisites or contextual conditions. The description is a single sentence 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?
There are no annotations, so the description must disclose behavior. It only states 'Create', implying a mutation, but provides no information about side effects, required parent objects, return values, or permissions. This is minimal disclosure about the operation'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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no wasted words. It is front-loaded and readable, though it sacrifices informative content for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create tool with 3 parameters and no output schema, the description is under-specified. It fails to explain what a VAST 4.2 icon is, whether it is tied to an ad or companion, or the implications of creating one. The schema covers parameter formats but not the broader operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides complete descriptions for all three parameters (name, width, height), so the description adds no additional parameter semantics. The baseline of 3 is appropriate since the schema covers all details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and resource ('VAST 4.2 icon'), clearly identifying the operation. It is distinguishable from sibling tools like vast42_update_icon and vast42_delete_icon, though it lacks additional scope details such as the icon's role within VAST.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 vast42_update_icon or vast42_create_icon_click_fallback_image. There are no stated prerequisites, context for icon creation, 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 behavioral burden. It only says 'Create' and does not mention side effects, required permissions, duplicate handling, or what the response contains. This is a significant gap for a mutating operation, comparable to the update_drive example.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that immediately states the verb and resource. It contains zero filler words or repetition, making it exceptionally concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having only two parameters and a simple schema, the lack of output schema and behavioral detail leaves the description incomplete. The agent is not told what happens after creation, what the return value is, or how this file fits into the broader VAST 4.2 creative structure, which is important given the large sibling toolset.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters (`name` and `mime_type`), so the description does not need to add parameter-level detail. The description itself adds no semantic depth beyond the schema, which is acceptable given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a VAST 4.2 interactive creative file, identifying the specific resource type and distinguishing it from generic creative tools like vast42_create_creative. However, it reads as a direct expansion of the tool name and does not elaborate on the file's role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 vast42_update_interactive_creative_file or vast42_create_creative. There are no preconditions, context, or exclusion criteria, leaving the agent without direction for choosing between related create/update 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 disclosing behavior. It only states the action 'Create', which implies a mutation, but does not describe side effects, authorization requirements, idempotency, or what happens on success/failure. For a write operation, this is a significant gap; the agent cannot anticipate the outcome beyond a generic creation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant words. It directly conveys the action and resource without filler. It earns its place by being efficient and easily parsed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple CRUD creation endpoint with 4 parameters, no output schema, and no annotations. The description is minimal and lacks context about the resulting object, required parent entities, or how this fits into the VAST 4.2 workflow. The schema covers parameters, but the agent has no information about return values or operational 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.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, as each parameter has a description (e.g., 'Name', 'Width in pixels'). The tool description adds no parameter information, but the schema handles the heavy lifting. The baseline for high coverage is 3, and the description does not improve or detract from the schema's clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and the resource ('VAST 4.2 non-linear media'). It distinguishes from siblings like 'vast42_create_linear' by specifying 'non-linear media', and the version 'VAST 4.2' avoids confusion with non-prefixed tools. However, it does not elaborate on what a non-linear media represents in the VAST context, leaving slight ambiguity for an agent unfamiliar with 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/5Does 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 'vast42_create_linear' or 'vast_create_non_linear_media'. There is no mention of prerequisites, required relationships to ads/creatives, or scenarios where this tool should be selected. The agent must infer the use case solely 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, the description carries the full burden of behavioral disclosure. 'Delete' implies destructiveness, but the description does not disclose whether the deletion is irreversible, whether it cascades to related entities, or what permissions are required. This is a significant gap 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no redundant or extraneous words. It communicates the essential purpose in a scannable manner.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema) and the schema covers the parameter, but the description lacks essential contextual information for a delete operation. There is no mention of side effects, reversibility, or any cautionary notes. With no annotations available, the description is insufficient to fully understand the consequences of this action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the only parameter `id` with a clear description ('VAST 4.2 companion ID'), achieving 100% schema coverage. The tool description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and the target resource ('VAST 4.2 companion'), making it distinct from sibling CRUD operations like create, update, and get. The version qualifier '4.2' also differentiates it from the non-versioned `vast_delete_companion`. However, the description is minimal and does not add nuance beyond the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not mention when to use this tool versus alternatives, prerequisites (e.g., the companion must exist), or whether deletion is permanent. Given the large number of sibling tools, this lack of context is a clear deficiency.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 of behavioral disclosure. It only states the action ('Delete') without revealing whether the deletion is permanent, if there are side effects on associated entities, or if special permissions are required. This lack of transparency is significant for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently conveys the tool's purpose without any redundancy or irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a delete operation with no annotations and no output schema, the description is incomplete. It fails to mention whether the action is reversible, what happens to creative references, or any prerequisites. The simple schema and single parameter are fully documented, but the behavioral context is missing, making it less than fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage for the single 'id' parameter, including a clear description ('VAST 4.2 creative ID'). The tool description adds no additional parameter semantics, but since the schema already documents the parameter adequately, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Delete') and the resource ('VAST 4.2 creative'), making the core action unambiguous. It does not explicitly distinguish itself from sibling delete tools like 'delete_creative' or other vast42_delete_* tools, but the resource specification provides sufficient 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/5Does 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 updating, archiving, or using the generic 'delete_creative' tool. The description only implies the use case through the verb 'Delete' without any contextual or exclusionary details.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 'Delete' without mentioning permanence, cascading effects, required existence of the media, or any state change consequences. This is insufficient for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that states the core purpose. It is front-loaded and free of filler, though it is terse and lacks richer context that could fit in a sentence or two.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a destructive operation with no annotations or output schema, the description is incomplete. It does not explain the impact of deletion, whether it is reversible, or any error conditions. For a simple one-parameter tool it is minimally viable but lacks critical operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description fully covers the single parameter 'id' as 'VAST 4.2 linear media ID', so the description adds no additional meaning. Since schema coverage is 100%, the baseline of 3 applies; the description does not compensate with extra parameter-related context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and the target resource ('a VAST 4.2 linear media'), matching the tool name. However, it does not distinguish this from the similar sibling 'vast_delete_linear_media' or other delete operations, so it lacks differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusion criteria. Sibling tools with similar delete operations exist, 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?
With no annotations, the description must disclose behavioral traits, but it only says 'Delete a VAST 4.2 resource'. It does not mention whether deletion is permanent, irreversible, requires specific permissions, or affects related entities. The destructive nature is implied by 'Delete' but not elaborated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately conveys the action and target. It is well-structured and front-loaded, though very sparse; it earns its place but does not expand on important considerations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple delete operation with a single parameter, so the description is minimal but not fully complete. It lacks information about return values, error conditions, irreversibility, or any impact on associated resources, making it insufficient for an agent to anticipate the full effect of the call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of the parameter documentation with 'VAST 4.2 resource ID', and the description does not add any additional parameter detail. With high schema coverage, the baseline of 3 is appropriate; the description offers no extra semantic contribution.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Delete') with a specific resource type ('VAST 4.2 resource'), which matches the tool name and distinguishes it from other VAST 4.2 delete tools via the 'resource' object. However, it does not elaborate on what exactly constitutes a 'resource' in this context, 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/5Does 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, no prerequisites, and no mention of related operations. The description simply states what it does without any 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 only says 'Get a single VAST 4.2 resource,' which implies a read operation but doesn't disclose return format, error handling, permissions, or side effects. This is a minimal, low-transparency description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no filler or redundant content. It efficiently conveys the core purpose, earning top marks for conciseness and structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description should compensate by explaining what a VAST 4.2 resource is and what the response contains. It does neither, leaving the description essentially a restatement of the tool name and lacking sufficient context for full operational understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage for the single parameter 'id', describing it as 'VAST 4.2 resource ID'. The description adds no further semantic detail beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation ('Get') and the target resource ('VAST 4.2 resource'), distinguishing it from list/create/update/delete sibling tools. However, it doesn't elaborate on what a 'resource' is or contrast with other get_* tools, so it's clear but not fully differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 vast42_list_resources. There is no mention of prerequisites, use cases, or exclusions, leaving the agent to infer usage solely from the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It says 'list all', implying a read-only operation, but does not disclose pagination behavior, default limits, response format, or any potential side effects. The input schema shows limit and offset, but the description itself does not clarify that 'all' is subject to pagination, which could be misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is direct and front-loaded. Every word contributes to conveying the core purpose. There is no redundant or filler content, making it a model of conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description does not explain what the response contains or how the list is structured. It also lacks any contextual information about what a VAST 4.2 closed caption file is, how to navigate pagination, or how this tool fits into the broader workflow. The overall context is under-specified for an agent to use it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters (limit and offset), so the schema already documents their meanings. The description adds no additional parameter-level information beyond what is in the schema, which aligns with the baseline score of 3 for fully covered schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all VAST 4.2 closed caption files' clearly identifies the action (list) and the resource (VAST 4.2 closed caption files). It distinguishes itself from sibling tools like vast42_get_closed_caption_file, vast42_create_closed_caption_file, etc., by being the list operation. However, it does not explicitly state scope limitations such as whether it lists across all advertisers or only within a 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/5Does 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 when to prefer this over vast42_get_closed_caption_file for retrieving a single file, or how it relates to other list tools. There is no mention of exclusions, prerequisites, or common 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?
The description says 'List all' but the input schema includes a default limit of 100 and a max of 100, implying the tool is paginated and may not return all records in a single call. This pagination behavior is not disclosed, and with no annotations, the description carries full responsibility for behavioral transparency but falls short.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundancy or fluff. It is appropriately sized for a simple list operation and every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description should at least mention pagination behavior, clarify what 'all' means given the limit parameter, and indicate that it returns a list of companion resources. The current one-liner is too terse to give an agent a complete understanding of the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for limit and offset ('Max results to return (default 100, max 100)' and 'Pagination offset'). The description adds no additional parameter meaning, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all VAST 4.2 companions' clearly states the action (list), the resource (VAST 4.2 companions), and the scope (all). The version qualifier '4.2' helps differentiate it from the sibling tool vast_list_companions, though it does not explicitly name the alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 vast_list_companions or other listing tools. There is no mention of use cases, exclusions, or contexts 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 present, and the description only states 'List all VAST 4.2 creatives' without clarifying pagination limits, return structure, or whether the list includes archived items. The word 'all' may mislead an agent into thinking the response is unbounded, when the schema clearly limits results to 100. There is no mention of the read-only behavior, though 'list' implies it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, which is appropriate for a straightforward list operation. However, it is so brief that it under-specifies key behavioral aspects, balancing conciseness at a 4.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool lacks an output schema and annotations, and the description gives no information about response format or pagination behavior. The presence of limit/offset parameters is not explained in the description, making it incomplete for an agent to understand how to properly iterate over results. Sibling tools like vast42_list_ads also have richer context (if they had descriptions) but here the tool is relatively simple.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides complete descriptions for both parameters (limit and offset), so the description adds no additional parameter semantics. With 100% schema coverage, the baseline of 3 is applied.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'List' and specifies 'VAST 4.2 creatives' as the resource, making the operation unmistakable. It distinguishes itself from sibling vast42 list tools (e.g., vast42_list_ads, vast42_list_linears) by the entity type, but does not differentiate from the generic list_creatives tool despite the VAST 4.2 qualifier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to prefer this tool over alternatives like vast42_get_creative for single items or list_creatives for non-VAST creatives. It also doesn't explain pagination usage despite the presence of limit/offset parameters. The context is only implied 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention pagination behavior, default limit, maximum 100, offset semantics, or that the result is a list (not 'all' at once). The term 'List all' could wrongly imply a single complete response, while the actual behavior is paged. No details about response format or ordering are given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately states the action and resource. It is front-loaded and contains no filler. However, it is so terse that it omits potentially important details (e.g., pagination), though for a simple list operation this level of brevity is acceptable. It earns a high score for conciseness but not a perfect 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema and the absence of annotations, the description should provide more context about what the tool returns and how to use it. There is no mention of pagination, defaults, or what a 'linear media' resource comprises. The presence of many sibling tools with similar names further increases the need for clarification, but the description is minimal and leaves the agent uncertain about the exact behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for both parameters, describing 'limit' (default 100, max 100) and 'offset' (pagination offset). The description itself adds no additional semantic meaning beyond the schema, so the baseline score of 3 is appropriate. The word 'all' in the description does slightly conflict with the pagination semantics, but the schema compensates for this.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does 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 ('all VAST 4.2 linear media'), making the tool's purpose obvious. It distinguishes itself from similar tools like 'vast_list_linear_media' by specifying the VAST 4.2 version. However, the word 'all' is slightly misleading because pagination is enforced via limit/offset, which could confuse agents expecting a single unfiltered response.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. Sibling tools like 'vast42_get_linear' (single item retrieval) and 'vast_list_linear_media' (non-4.2 version) exist, but the description does not differentiate use cases. No prerequisites, exclusions, or context are provided, leaving the agent to infer when this listing is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description offers no behavioral context beyond the act of listing. It does not disclose pagination behavior (despite limit/offset parameters), response format, whether the list is flat or hierarchical, or any side effects. The description carries no transparency value beyond the bare 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler words. It is appropriately brief for a simple list operation, though the extreme brevity leaves some gaps in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is part of a large family of similar list tools (vast42_list_ads, vast42_list_creatives, vast_list_media, etc.), the description is too minimal. It does not clarify what 'media files' encompasses (e.g., linear vs. non-linear, associated entities) or mention the two pagination parameters. The output schema is absent, so more descriptive context would be expected for a list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides complete descriptions for both parameters (limit and offset) with 100% coverage. The description itself adds no additional parameter semantics, so the baseline score of 3 is appropriate since the schema handles the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all VAST 4.2 media files' uses a specific verb ('List') and resource ('VAST 4.2 media files'), clearly distinguishing it from siblings like vast_list_media or vast42_list_linears. It accurately captures the tool's core function without 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/5Does 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 vast42_get_media_file, vast42_list_linears, or vast_list_media. It does not mention scenarios, exclusions, or prerequisites, leaving the agent to infer usage solely from the 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 the full burden of behavioral disclosure. It only states the operation without mentioning pagination behavior, result structure, ordering, or whether this includes all nested resources. This lack of disclosure leaves the agent uncertain about the tool's exact 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, straightforward sentence with no wasted words. It immediately communicates the core purpose, which is optimal for a simple list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the huge number of sibling tools and the lack of an output schema, the description is incomplete. It fails to clarify what constitutes a 'VAST 4.2 resource' (e.g., whether it lists all resource types or a specific endpoint), and it does not explain the return shape or pagination semantics beyond the parameter names. This ambiguity could lead to incorrect tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents both parameters (limit and offset) with descriptions and default/max constraints. The description adds no additional parameter meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does 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 ('all VAST 4.2 resources'). This distinguishes it from sibling tools that list specific types (e.g., vast42_list_ads, vast42_list_creatives) by implying a broader, aggregate listing. However, 'resources' is somewhat ambiguous—it could mean all resource types or a single collection—so it lacks full 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/5Does 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 the many sibling list tools (e.g., vast42_list_ads, vast42_list_placements). No alternatives, exclusions, or context are provided, so 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?
With no annotations provided, the description is the sole source of behavioral disclosure, but it only states the basic action ('Update'). It does not explain whether the update is partial or full, what side effects occur, whether special permissions are needed, or what errors might arise. 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (7 words) and front-loaded with the core action. However, it omits information that could be included without bloat, such as the list of updatable fields, making it efficient but slightly under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and only four parameters, the description is incomplete. It does not clarify whether only provided fields are updated, what the return value is, or any operational context like whether the ad item must exist. This leaves the agent without crucial information for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 100% of parameters, so the schema already documents id, name, active, and location. The tool description adds no extra semantic meaning beyond what is in the schema, which aligns with the baseline score of 3 given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update a VAST 4.2 ad item' uses a specific verb ('Update') and names the resource ('VAST 4.2 ad item'), clearly distinguishing it from siblings like vast42_create_ad, vast42_delete_ad, and vast42_update_creative. The version qualifier '4.2' also differentiates it from generic update tools like vast_update_ad_item.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 vast42_create_ad or vast_update_ad_item. There is no mention of prerequisites, exclusions, or a preferred context for 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?
No annotations are provided, so the description carries the full burden. It only states 'Update a VAST 4.2 interactive creative file'—which essentially restates the tool name—offering no details on side effects, partial vs. full updates, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence with no fluff, making it concise and front-loaded. However, its extreme brevity leaves no room for additional context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple update with 3 fields, no output schema, and no annotations. The description adds no context about update semantics, optionality of fields, or failure behavior, leaving the agent with uncertainty about standard update behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with id, name, and mime_type already described. The description adds no parameter-specific meaning beyond the schema, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update a VAST 4.2 interactive creative file' uses a specific verb (Update) and resource (VAST 4.2 interactive creative file), clearly distinguishing it from sibling create/delete/get tools. It lacks detail about what an update entails but is not a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 vast42_create_interactive_creative_file or vast42_delete_interactive_creative_file. No prerequisites, exclusions, or context about the update process 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, the description carries the full burden of behavioral disclosure, but it only says 'Update' without explaining whether updates are partial or full replacements, whether unspecified fields are reset, or if permissions are required. It also does not indicate if the operation is destructive or safe.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It is appropriately concise, though it borders on under-specification by essentially restating the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there are no annotations and no output schema, the description is too sparse to fully contextualize the tool. It does not explain update semantics, how media files relate to other VAST entities like linears or companions, or what happens after the update.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for all 6 parameters (id, name, width, height, bitrate, mime_type), so the description adds no additional parameter meaning. Since schema coverage is 100%, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Update') on a specific resource ('a VAST 4.2 media file'), which clearly conveys the tool's function. It distinguishes from create/get/delete media file tools by verb, though it adds little beyond the tool name and doesn't describe the media file's role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 vast42_create_media_file, vast42_delete_media_file, or vast_update_linear_media. There is no mention of prerequisites (e.g., the media file must already exist) 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 available, the description carries the full burden of behavioral disclosure. It only says 'Update a VAST 4.2 resource' and provides no information about side effects, required fields beyond id (which is in schema), reversibility, permissions, or error behavior. For a mutation tool, this lack of context is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It efficiently states the core purpose but is minimal to the point of omitting potentially useful context. It is concise and well-structured, though not overly informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and only a three-word description, the context is inadequate. It does not explain what a 'resource' is, what fields can be updated, or any behavioral implications. The sibling list includes many similar tools, and this description does not help an agent understand the tool's role within that ecosystem.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides complete descriptions for all three parameters (id, name, type), with 100% schema description coverage. The tool description adds no additional parameter semantics, such as constraints, whether fields are optional, or how partial updates behave. Since the schema already covers the parameters, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and the target ('a VAST 4.2 resource'), which distinguishes it from create/delete/get operations. However, 'resource' is a generic term and does not differentiate among the many VAST 4.2 update siblings (e.g., vast42_update_ad, vast42_update_placement), so it 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/5Does 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. It does not mention that this is for modifying an existing resource, nor does it reference any related tools like vast42_create_resource or vast42_delete_resource. The description is purely a statement of action with no 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?
With no annotations, the description carries the full burden of behavioral disclosure. It only states a create operation, with no information about side effects, permissions, idempotency, or what the response contains. 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no fluff or repetition. It is front-loaded and easy to read, though it offers minimal content. It earns a score of 4 for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create operation with no annotations and no output schema, the description is too sparse. It lacks information about return values, required permissions, or operational context (e.g., whether 'location' is a URL or file). While the schema covers parameters, the overall description is insufficient to fully understand the tool's behavior in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% description coverage for all three parameters (name, active, location), so the schema already documents the fields. The description adds no additional semantic meaning beyond what is in the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create) and resource (VAST ad item), making the purpose unambiguous. However, it essentially restates the tool name without adding additional specificity, such as the required fields or typical use case. Therefore, it is clear but not differentiating beyond 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the many other vast_* siblings (e.g., vast_update_ad_item, vast_create_placement). There is no mention of prerequisites, compatibility, or alternative approaches, so the agent is left without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the core creation behavior and adds no context about side effects, idempotency, validation, active default (though the schema does), or response format. This is a minimal disclosure for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 14 words, front-loaded with the core action 'Create a VAST campaign assignment'. It has no redundant information or repetition of schema fields, making it efficient for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create tool with 3 parameters and no output schema, the description gives the core purpose but omits any mention of return value, prerequisites, or validation behavior. Given the existence of several sibling create tools, more context would help distinguish this specific version, but the schema covers parameter descriptions adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The phrase 'assign an ad item to a campaign' adds some context by mapping ad_item and campaign to entities, but this is already evident from the schema's parameter names and descriptions. No additional syntax, constraints, or relationships are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the verb 'Create' and the resource 'VAST campaign assignment', with the parenthetical 'assign an ad item to a campaign' clarifying the entity. It differentiates from read/update/delete siblings, but not from similar create variants like vast42_create_campaign_assignment or draft_create_campaign_assignment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 the draft or vast42 variants, nor any context about prerequisites such as requiring existing ad items and campaigns. The description is purely declarative with no exclusions, alternatives, or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the burden of behavioral disclosure. It only says 'Create a new VAST channel', which adds no behavioral details such as required preconditions, permissions, return value, or side effects. This is minimal and leaves the agent guessing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no wasted words. It is front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create operation with no output schema and no annotations, the description should at least mention what the response contains or any operational context. It is too sparse to fully inform an agent about the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes both parameters (name and description) with 100% coverage, so the description adds no additional parameter semantics. The baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (create) and resource (VAST channel), and the 'VAST' qualifier helps distinguish from the sibling create_channel. However, it doesn't explicitly contrast with other vast_* create 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to prefer this tool over alternatives like vast_update_channel, vast_create_zone, or the non-VAST create_channel. It simply states the action without 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 disclosing behavior. It only states the intended action without mentioning idempotency, failure modes, permissions, or effects on existing assignments. 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that efficiently communicates the core purpose without redundant wording. It is appropriately sized for a tool with only two parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations or output schema, the description is incomplete for a mutation tool. It does not explain assignment semantics (e.g., idempotency, duplicate handling) or differentiate from the update tool. This leaves the agent without enough context to handle edge cases confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters with clear descriptions ('VAST zone ID', 'VAST channel ID') at 100% coverage. The description adds no additional meaning beyond what the schema already provides, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('assign') and the resources ('VAST zone', 'VAST channel'), making the purpose obvious. However, it does not explicitly distinguish this create operation from the sibling update_channel_zone_assignment, relying on the tool name's 'create' prefix for that 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the update or delete variants, nor does it mention any prerequisites or conditions (e.g., whether channel and zone must already exist). There is no explicit when-to-use or alternative 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'Create', which implies a write operation, but fails to mention permissions, idempotency, whether the companion is associated with an ad or creative, or any return values. This is insufficient for a create 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is not tautological and conveys the core purpose. However, it is perhaps too spare, missing valuable context that could be added without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a create operation, the description is minimally complete. It fails to explain what a VAST companion is, how it relates to other entities (e.g., linear creatives or ads), or what the response will contain. This leaves significant gaps for an agent deciding whether and how to invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the parameter descriptions are clear ('Companion name', 'Companion width in pixels'). The tool description itself adds no extra meaning beyond the schema, which is acceptable given the baseline of 3 for full coverage, but it does not compensate for any ambiguity about units or required fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and resource ('VAST companion'), making the basic action clear. However, it does not distinguish itself from the similarly named sibling tool 'vast42_create_companion', so the agent cannot tell which API variant to use from this description alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as vast42_create_companion, nor any context about prerequisites or relationships to other VAST entities like ads or creatives. The agent is left to infer usage solely from the tool name.
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 no behavioral disclosure—nothing about required permissions, default behaviors, quota handling, or effects on existing schedules. It only states the creation intent without any side-effect information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no filler. It is appropriately front-loaded with the action verb, though it could use more structure for such a parameterized tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has seven parameters and no output schema or annotations, this one-line description provides insufficient high-level context. It does not explain the schedule creation workflow, dependencies, or when creation succeeds.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all seven parameters. The description adds no preferential meaning beyond 'time-based ad delivery', so a score of 3 is appropriate as a baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Create'), the resource ('a new VAST schedule'), and the domain ('time-based ad delivery'), distinguishing it from related tools like vast_update_schedule or vast_delete_schedule. The inclusion of 'VAST' also differentiates it from non-VAST schedule 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to choose this tool over alternatives like create_schedule (non-VAST) or vast_update_schedule. The phrase 'time-based ad delivery' gives some context, but there are no explicit when/when-not or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only states the creation action. It does not mention side effects, return values, required fields, permissions, or idempotency, leaving significant ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded, containing zero redundant words. It efficiently communicates the core action without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple CRUD create operation with a fully described schema, but the description does not explain what happens on success (e.g., return value) or how it fits into the VAST tracking workflow. This is a minimal viable description but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all three parameters (url, name, event) with descriptions, so the baseline is 3. The description adds no extra parameter information, leaving the schema to do the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Create') and resource ('VAST tracking entry'), making the tool's purpose unambiguous. It is distinct from sibling CRUD tools through the verb, though it does not add further scoping or 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/5Does 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 vast_update_tracking or vast_delete_tracking. It lacks any description of prerequisites, typical use cases, or when to prefer this over other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides only the verb 'Delete' and gives no information about permanence, side effects, required permissions, or whether the ad item must be in a particular state. This leaves the agent without behavioral transparency beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the core operation with no wasted words. It is appropriately sized for a one-parameter delete operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter delete tool without output schema, the description is minimal but lacks important contextual details such as whether deletion is permanent, whether related objects are removed, or any usage caveats. The simple schema partially compensates, but the absence of behavioral and usage context makes it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the single required `id` parameter with a description 'VAST ad item ID'. The tool description adds nothing about how the id is used, so it meets the schema-coverage baseline but provides no additional semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a VAST ad item' clearly identifies the action (delete) and the resource (VAST ad item). It distinguishes from sibling tools that create, update, list, or get ad items, though it provides no additional context about scope or effect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not state when to use this tool versus other VAST delete or ad-item tools, nor any prerequisites or alternatives.
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 merely restates the operation 'Delete' without disclosing irreversibility, potential cascading effects, permission requirements, or post-conditions. For a destructive 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It communicates the core action and target resource efficiently, which is appropriate for a tool with one parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema, but given the many similar deletion tools in the sibling list, the description should clarify scope and side effects. It provides minimal viable information but omits return behavior and potential impacts, leaving gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage with the parameter 'id' described as 'VAST campaign assignment ID'. The description adds no extra meaning beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Delete' and identifies the resource as 'VAST campaign assignment', which clearly states the operation. It does not explicitly distinguish it from sibling tools like delete_campaign_assignment or vast42_delete_campaign_assignment, so no sibling differentiation is provided.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 sibling list contains several similar deletion tools (e.g., delete_campaign_assignment, vast42_delete_campaign_assignment, draft_delete_campaign_assignment), but the description offers no selection criteria 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. 'Get details' implies a read-only operation, but it does not disclose return format, error behavior, permissions, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no filler words. It is front-loaded and concise, though it could include slightly more detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but with no output schema and no annotations, the description should at least clarify what kind of 'details' are returned. The vague wording leaves the agent uncertain about the response structure and scope of information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter (id), with the description 'VAST channel ID'. The tool description adds no additional meaning beyond what the schema already provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb (Get) and resource (VAST channel), clearly indicating a read operation targeting one specific channel. It distinguishes from list tools like vast_list_channels by the word 'specific', 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/5Does 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 vast_list_channels or vast_get_archived_channel. The description gives no context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It merely states 'List all VAST channels' and does not reveal pagination behavior, default limits, ordering, or any side effects. This adds minimal value beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core purpose. Every word is useful, and there is no redundant filler. It is 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.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of two parameters in the schema, the description is incomplete. It does not mention return format, pagination behavior, or how this list tool relates to the many sibling list tools. The agent is left without critical context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of the parameters (limit, offset) with descriptions, so the baseline is 3. The description does not add any parameter details beyond the schema, but it does not need to since the schema is already thorough.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all VAST channels' clearly specifies the verb 'List' and the resource 'VAST channels', distinguishing it from get/create/update siblings. However, it does not differentiate from the similar 'list_channels' sibling, so it falls short of 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/5Does 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 vast_get_channel or list_channels. There is no mention of appropriate use cases, filtering options, or pagination context, leaving the agent without directional 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?
The description gives no behavioral details beyond the bare action. It doesn't mention pagination (despite limit/offset params), result ordering, or any read-only guarantees. With no annotations provided, the description carries the full burden and fails to disclose useful 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is concise and immediately conveys the core action, though it may be too terse to be fully helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with two pagination parameters and no output schema, one sentence might be minimally adequate. However, the description lacks mention of pagination behavior or what the returned items represent, leaving some ambiguity for an agent deciding whether this is the right call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both 'limit' and 'offset' having clear descriptions. The tool description adds no extra meaning to the parameters, so the schema does the heavy lifting, matching the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('VAST channel zone assignments'), clearly indicating the operation. It distinguishes itself from singular 'get' variants, though it doesn't explicitly contrast with the non-prefixed 'list_channel_zone_assignments' sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 'vast_get_channel_zone_assignment' or the non-prefixed list. There are no exclusions, prerequisites, or contextual cues beyond the generic verb.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description is the sole source of behavioral disclosure. It only says 'List all VAST companions' without confirming read-only behavior, pagination behavior, scoping, or any potential side effects. This is a significant gap for a tool with no annotation safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that directly states the purpose. It is front-loaded and contains no fluff, though it is minimal. It could be slightly more informative without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotations. The description does not explain what companions are, what data is returned, whether 'all' means account-wide or is scoped to a parent resource, or anything about the response structure. This is incomplete for an agent to use confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for both parameters (limit and offset) with default and max values, giving 100% schema coverage. The description itself adds no parameter details, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all VAST companions' clearly states the action (list) and the resource (VAST companions). It distinguishes from many other tools by focusing on companions, but it does not differentiate from the sibling vast42_list_companions, which likely serves a different VAST 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/5Does 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 like vast42_list_companions, nor any mention of prerequisites or context. The description only states the basic function, leaving the agent to infer usage on its own.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 says 'List all VAST schedules' without mentioning pagination behavior, whether it returns archived schedules, read-only implications, or any required permissions. The description provides minimal transparency beyond the implied read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that effectively communicates the core purpose. It is not needlessly verbose, and every word serves a purpose. It could be expanded with context, but for a simple listing tool it is appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the large sibling set and the lack of an output schema, the description is incomplete. It doesn't clarify the scope of 'all VAST schedules' (e.g., all schedules in the account, all schedules across campaigns?), nor does it differentiate itself from similar list tools. The description fails to provide enough context for a heteronymous environment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters (limit, offset) with descriptions, achieving 100% schema description coverage. The description adds no parameter semantics, but since the schema already explains them, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does 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 VAST schedules'), which distinguishes it from tools that fetch a single schedule or operate on draft schedules. However, it doesn't explain what qualifies as a 'VAST schedule' or differentiate it from the related 'list_schedules' and 'draft_list_schedules' tools, so it's clear but not fully distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 like 'vast_get_schedule', 'list_schedules', or 'draft_list_schedules'. The description lacks any mention of use cases, prerequisites, or context that would help an agent choose this tool 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?
With no annotations, the description must fully disclose behavior, but it only states that it lists all zones. It does not mention pagination characteristics, default/max limits, whether archived zones are included, or any side effects. The word 'all' is ambiguous given the limit/offset parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no redundant words. It is front-loaded and easy to parse, though it is too sparse to provide complete context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple list tool, but the description is incomplete. With no output schema, it does not explain the return format, whether archived zones are included, or how pagination should be handled to obtain the full list. Sibling tools suggest a taxonomy that is not addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema descriptions cover 100% of parameters (limit and offset) with clear explanations. The description adds little beyond the schema, merely implying a full list without elaborating on how pagination interacts with 'all'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all VAST zones' has a clear verb (list) and resource (VAST zones), and the word 'all' conveys scope. However, it does not distinguish this tool from siblings like 'list_zones' or 'list_all_zones', which likely overlap in purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 is no mention of exclusions, prerequisites, or relationships to related tools like 'vast_list_archived_zones' or 'list_all_zones'.
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. It only restates the verb 'update' without explaining side effects, partial update semantics, whether omitted fields are cleared, required permissions, or return behavior. This is a minimal mutation tool description with zero 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It is appropriately concise for a simple update operation, though it could include a brief usage note without losing efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (4 params, 1 required) and the schema covers parameters, but the description lacks context about update semantics, return values, or when to use it. With no annotations and many sibling update tools, an agent would have difficulty distinguishing behavior and consequences without external knowledge. This falls below the minimum viable bar for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all four parameters (id, name, active, location). The description adds no parameter-level meaning beyond the resource name, but the schema does the heavy lifting, warranting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Update') and resource ('existing VAST ad item'), clearly distinguishing it from sibling tools like 'vast_create_ad_item', 'vast_delete_ad_item', and 'vast_get_ad_item'. It clearly states the operation and object.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as 'vast_create_ad_item' or 'vast_update_linear_media'. The description gives no context on prerequisites, typical use cases, or exclusions, so an agent receives no decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 responsibility for behavioral disclosure. It merely states 'Update' without mentioning side effects, required parameters beyond schema, whether it's a partial or full update, permissions needed, or impact on ad serving. The description adds no behavioral context beyond the bare 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words. It is front-loaded and to the point, though it might be too terse for full transparency. It earns its place but leaves out important details, which is a trade-off between conciseness and completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's context (4 parameters, no annotations, no output schema, and many sibling update tools), the description is incomplete. It does not explain return values, prerequisites, or how this tool fits into the workflow. The schema covers parameters, but the overall operational context is missing, making this a minimally viable but incomplete description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter (id, active, ad_item, campaign) having a clear description. The tool description itself adds no parameter-specific meaning beyond the resource name, so the baseline of 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update a VAST campaign assignment' uses a specific verb ('Update') and resource ('VAST campaign assignment'), clearly indicating the action. However, it does not differentiate from sibling tools like 'vast42_update_campaign_assignment' or other update operations, so it lacks some context for distinguishing among 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as create/delete campaign assignment tools or the vast42 variant. No prerequisites, exclusions, or contextual cues are provided; the usage is only implied by the verb 'Update'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must convey behavioral traits. It states the mutation ('Update') but does not disclose partial vs. full update semantics, required fields, or potential side effects. 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—one short sentence. It is front-loaded and wastes no words. However, the brevity comes at the cost of missing important details, so it doesn't earn a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is too minimal. It fails to explain return values, error conditions, or how it relates to similar update tools. The schema covers parameters but not behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% description coverage for all parameters (id, name, description). The description adds no additional parameter-level semantics, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does 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 ('VAST channel'), making its primary purpose evident. However, it does not differentiate from sibling tools like vast_update_channel_zone_assignment or the generic update_channel, so it lacks the specificity needed for a top 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor are any prerequisites or exclusions mentioned. The description offers no contextual hints 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?
With no annotations, the description carries the full burden of behavioral disclosure. It only states 'Update an existing VAST companion,' which implies mutation but does not disclose how updates behave (partial vs full overwrite), error handling on nonexistent IDs, permission requirements, or return values. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundancy. However, it is very minimal, bordering on under-specification, so it does not earn a 5 for effective use of brevity to convey additional useful context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is extremely terse and provides almost no context. Without annotations or an output schema, the agent has no information about the implications of updating a companion, when it should be used relative to other VAST tools, or what the side effects might be. This is incomplete for a tool with four parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no parameter information, but the schema already documents all four parameters (id, name, width, height) with descriptive text. The description does not need to compensate for schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Update an existing VAST companion,' clearly indicating the verb (update) and resource (VAST companion). It differentiates from sibling tools like create/get/delete by the update verb, though it adds no detail beyond the tool's 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, such as needing an existing companion ID, or any exclusion criteria. The description lacks context about when to use update vs create/delete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior itself. It only says 'update' without explaining whether omitted fields are preserved or reset, whether this is a partial or full update, or what the response will be. For a mutation tool with 14 parameters, 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant wording, making it concise. However, it is underspecified for a tool of this complexity; it lacks front-loaded context beyond the basic verb+resource statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex 14-parameter tool with no output schema and no annotations, this description is inadequate. It doesn't clarify whether the update is partial or full, what the return value is, or how fields like zone and channel interact (mutual exclusivity). The schema covers parameter definitions but not the operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema documents all 14 parameters with descriptions (100% coverage), so the baseline is 3. The tool description adds no parameter-level detail beyond what the schema already provides, not even confirming the update behavior (e.g., partial updates).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does 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 VAST placement'), distinguishing it from create/delete operations. However, it doesn't differentiate among sibling update tools like vast42_update_placement or draft_update_placement, 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/5Does 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 vast_create_placement, vast_get_placement, draft_update_placement, or vast42_update_placement. There are no exclusions, prerequisites, or selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only says 'update' without explaining partial vs full replacement, required permissions, idempotency, or response behavior. This is insufficient for a mutation operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single concise sentence, easy to parse, no wasted words. However, it is somewhat sparse, bordering on under-specification, but it's a complete sentence with clear subject and verb.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters, a mutation operation, no annotations, and no output schema, the description provides minimal context. It doesn't explain what happens to omitted fields, what the response contains, or any prerequisites, making it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions, so baseline is 3. The tool description adds no parameter information, but the schema already provides full semantics, so no penalty.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does 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 ('existing VAST schedule'), distinguishing it from create/delete operations. However, it adds little beyond the tool name and doesn't elaborate on scope or effects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 vast_create_schedule or vast_delete_schedule. The word 'existing' implies it applies to pre-existing schedules, but there is no explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'Create a new PMP deal' and does not mention permissions, idempotency, response format, or any side effects. 'Create' implies mutation, but no further transparency is offered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, brief sentence that is undeniably concise. However, it merely restates the tool name without adding meaningful content, so it does not fully 'earn its place.' It is not verbose but is under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with 5 parameters, no annotations, and no output schema, the description is too sparse to provide adequate context. It doesn't explain required fields, behavior on creation, or anything beyond the most obvious statement. The sparse description leaves significant gaps for an agent invoking this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no parameter information, but the schema already fully documents all 5 parameters with meaningful descriptions. The description's lack of additional param context is not penalized due to high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new PMP deal' uses a specific verb+resource structure that clearly identifies the operation. It distinguishes from siblings like update_pmp_deal, get_pmp_deal, and delete_pmp_deal by its explicit 'Create' 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. It simply states the action without any contextual direction, similar to the update_drive example scored as 2.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 simply states 'Create a new rich media ad item' with no mention of side effects, required permissions, whether the creation is draft-only, or what happens after creation. 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (one sentence) and front-loaded, but it is essentially a restatement of the tool name with 'new' added. For a tool with 12 parameters and complex nested objects, a slightly more substantive description would be more appropriate, though there is no wasted wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (12 parameters, required fields, nested objects), this minimal description is inadequate. It does not explain the creation context, return values (no output schema), or relationship to other ad item types, leaving the agent to rely heavily on parameter names and schema descriptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all 12 parameters with individual descriptions. The tool description adds no parameter-specific information, warranting the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Create') and a specific resource ('rich media ad item'), which distinguishes it from sibling tools like create_image_ad_item or create_custom_html_ad_item. It accurately conveys the tool's primary function without 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. An agent would have to infer the intended use 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It fails to mention that deletion is destructive, irreversible, or what happens to related data. The agent is left without important 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that directly communicates the tool's purpose. There is no redundant information or unnecessary detail, making it structurally efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a delete operation with no annotations and no output schema, the description is incomplete. It does not explain return values, error scenarios, side effects, or any confirmation needed. The tool is simple, but the lack of behavioral context makes it insufficient for an agent to understand the full impact.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage with a clear 'Demand source ID' parameter. The description adds no extra meaning beyond the schema, so the baseline of 3 applies. No additional context about the parameter format or constraints is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 demand source). It distinguishes this tool from siblings like create_demand_source, update_demand_source, and get_demand_source. The verb is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 consequences. It simply repeats the tool's name without offering context such as whether deletion is permanent or if any dependencies must be removed first.
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 only restates the tool name without detailing any behavioral consequences, such as whether deletion is permanent, reversible, or what happens to associated data. The description adds no transparency beyond the verb 'Delete'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no extraneous words. It is appropriately concise for a simple delete operation and is 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is inadequate for a destructive operation with no annotations. It does not explain the relationship between report_config_id and schedule_id, any prerequisites, or the effects of deletion. Given the lack of annotations and output schema, more context is needed for an agent to understand the full scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and both parameters are documented in the schema with descriptions. The description adds no additional parameter semantics beyond what the schema already provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 (report schedule), distinguishing it from other delete_* tools like delete_schedule or delete_contract. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 whether to use delete_schedule for general schedules or this tool for report-specific schedules. No prerequisites, exclusions, or context for selection are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It merely says 'Replace the file' with no mention of side effects, reversibility, permissions, or what happens to the old file. This is a mutation tool with zero 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that gets straight to the point with no filler or redundant content. It is front-loaded and appropriately sized for the simple action it describes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only one parameter (id) yet claims to 'replace the file', leaving unclear how the new file is provided. There is no output schema, no annotations, and no explanation of the replacement mechanism, making the description incomplete for an agent to invoke confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for its single parameter ('id' described as 'Creative ID'), and the description adds no extra parameter-level meaning. Baseline of 3 is appropriate since schema fully documents the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Replace') and identifies the exact resource ('the file on a video creative'), clearly distinguishing it from sibling tools like replace_image_creative_file and replace_audio_creative_file. Even without naming alternatives, the resource type 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as update_video_creative or replace_audio_creative_file. The description only states what it does, not when it 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.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden for disclosing behavioral traits. It only says 'Update an existing catalog zone' without mentioning side effects, idempotency, required permissions, error conditions, or whether it performs a partial or full update. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler words. It is front-loaded with the action and resource, and every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters, no output schema, and no annotations, the description is too sparse. It does not explain what a catalog zone is, what the update semantics are (e.g., partial vs full replace), or what the response contains. This is insufficient for an agent to use the tool correctly in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all 8 parameters (100% coverage), so the description does not need to explain them. The description adds no extra parameter meaning, but since schema coverage is high, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 catalog zone'), which is specific and distinguishes it from create/delete/get operations. The term 'catalog zone' differentiates it from other sibling zone tools like update_zone, vast_update_zone, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, when to prefer this over similar zone update tools, or any exclusions. It merely restates the tool's purpose without contextual 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?
With no annotations, the description must carry behavioral transparency, but it only restates the action. It does not disclose whether the update is partial or full, whether the 'id' parameter is required, or any side effects such as validation or downstream impacts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded, but it is under-specified for a tool with 9 parameters and complex update semantics. It does not earn its place as a helpful description because it omits key details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is incomplete for a mutation tool with no annotations, no output schema, and a rich set of sibling tools. It lacks context about required fields, behavior on partial updates, and the resource's lifecycle, making it insufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, as all 9 parameters have descriptions in the input schema. The description itself adds no parameter details, but the baseline is set to 3 due to the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an existing contract' clearly states the verb (update) and the resource (contract). It distinguishes this tool from sibling tools like create_contract, get_contract, and delete_contract, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 archive_contract, delete_contract, or update_contract_document. There are no preconditions, exclusions, or context about typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the basic action (update) and that the template must exist, but does not disclose effects, permissions, reversibility, or partial update semantics. This is nearly tautological with the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that states the purpose without any wasted words. It is front-loaded and easy to parse, fitting the standard for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (2 params, no annotations, no output schema), the description is minimal but still leaves gaps: it doesn't explain what fields can be updated (though schema lists name), any prerequisites like authentication, or what response to expect. It is barely adequate for a basic update operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters (id and name), so the schema fully documents them. The description adds no parameter information, which is acceptable per the baseline of 3 when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an existing contract template' uses a specific verb ('update') and resource ('contract template'), clearly distinguishing it from sibling tools like create_contract_template and delete_contract_template. It also specifies the target is an existing template, which adds nuance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as create_contract_template or delete_contract_template. The purpose is implied by the verb 'update', but there are no explicit usage conditions, prerequisites, or exclusions.
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 carry the full burden of behavioral disclosure. It merely restates the tool's name and gives no information about side effects, authentication needs, whether the update is partial or full, error behavior, or return values. This is essentially a tautology of the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the action. There is no superfluous wording or repetition. It earns its place even if minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutation tool with 7 parameters and no output schema, yet the description does not clarify update semantics (e.g., whether omitted fields are preserved), expected response format, or any prerequisites beyond having an ID. This is a significant gap for a tool with optional fields and no annotations or output schema to supplement it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with all seven parameters having meaningful descriptions. The tool description itself adds no additional parameter context, but the baseline of 3 is appropriate when the schema fully documents parameters. No points deducted for missing info that is already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Update') and specific resource ('demand source'), which clearly distinguishes it from sibling tools like create_demand_source, delete_demand_source, or get_demand_source. It directly states the operation and target without 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/5Does 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 exclusions, prerequisites, or related tools (e.g., use create_demand_source for new records). The only hint is the word 'existing', implying it is not for creation, but this is not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavior, but it only states the action. It does not explain whether the update is partial (PATCH) or full replacement (PUT), what side effects occur, or whether the id must belong to an existing media group. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff, making it easy to parse. However, it is minimal to the point of under-specification, but that is more a completeness issue than a conciseness issue. It is well-structured for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no output schema, no annotations), the description is minimally acceptable but lacks context about behavior and return values. The schema covers parameter meanings, but the description does not explain what happens after the update, leaving some gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents both parameters (id and name) with descriptions, and coverage is 100%. The tool description adds no additional parameter semantics, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'update' with the resource 'media group', clearly distinguishing it from sibling tools like create_media_group, delete_media_group, get_media_group, and list_media_groups. It states exactly what the tool does with no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that create_media_group should be used for new entities, nor any prerequisites like the media group must already exist. There is no implied context beyond the verb 'update'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It only says 'Update an existing data asset'—nothing about partial vs full updates, effects on unspecified fields, required permissions, or response format. No additional context is offered beyond the operation itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant wording. It earns its place by clearly stating the operation and scope, and nothing more is needed for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This mutation tool lacks annotations and an output schema, yet the description does not explain return values, partial update behavior, or when to use it. While the schema covers parameters, the overall description is minimal and leaves noticeable gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all four parameters (id, len, type, template_id). The description adds no parameter-specific information, so the baseline of 3 applies because the schema already documents parameters sufficiently.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation (Update) and resource (existing data asset) scoped to an ORTB native template. It distinguishes this from create/delete/get tools in the same family by specifying 'existing'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like create_ortb_native_data_asset or update_ortb_native_image_asset. It does not mention prerequisites, use cases, 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, the description carries the full burden of behavioral disclosure. It states the action 'Delete' but does not mention whether deletion is permanent, reversible, or has cascading effects, nor any authentication requirements or rate limits. Minimal behavioral information is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly conveys the tool's purpose with no extraneous words or repetition. It is appropriately sized for the simple operation it describes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple delete operation with one parameter, but the description lacks critical context such as permanence, side effects, or usage prerequisites. Given no annotations and no output schema, the description should provide more behavioral and contextual detail to be considered complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the only parameter 'id' with the description 'VAST 4.2 mezzanine ID'. The tool description adds no additional parameter semantics, but the schema coverage is 100%, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 VAST 4.2 mezzanine'), making the tool's purpose unambiguous. It differentiates from siblings because 'mezzanine' and 'delete' are specific, and the name reinforces the same.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives, prerequisites, or scenarios where deletion is 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.
- 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. It only says 'Delete' and does not mention whether the deletion is permanent, idempotent, or has side effects. No error behavior or return value is disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It is appropriately concise for a simple delete operation, though it lacks additional context that could make it more helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter delete tool, the description is minimally complete, but with no output schema and no annotations, it leaves out critical behavioral details such as return values, irreversibility, and error handling. It is adequate for basic selection but not fully informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the single 'id' parameter, describing it as the VAST 4.2 placement ID. The description adds no additional parameter meaning, but the schema already provides sufficient context, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 ('VAST 4.2 placement'), which distinguishes it from the generic vast_delete_placement sibling. The versioned resource is explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 vast_delete_placement or other placement deletion tools. The description simply restates the action without context or exclusions.
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 restates the get operation without any additional context such as return format, error behavior, authentication requirements, or side effects. This is a minimal disclosure that adds no behavioral transparency beyond the purpose itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that is front-loaded with the key information. Every word is meaningful and there is no redundant phrasing. It is appropriately concise for a simple get-by-ID operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description should provide some context about the return value or behavior. It only states the operation, leaving the agent unsure of what the response looks like. Additionally, the existence of a similar sibling tool (vast_get_non_linear_media) is not addressed, creating potential confusion. The description is minimal but lacks necessary context for a reliable tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameter descriptions (id is defined as 'VAST 4.2 non-linear media ID'), so the description does not need to add parameter details. The description does not conflict with the schema, but does not add extra semantic value beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the specific resource 'single VAST 4.2 non-linear media', distinguishing it from list, create, update, and delete siblings. It precisely identifies the operation and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 sibling tools like vast42_list_non_linears or vast_get_non_linear_media, nor does it provide any exclusions or prerequisites. The usage context is entirely implied 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.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It merely says 'Update' without revealing any side effects, partial-update semantics, permission requirements, or response behavior. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. It is appropriately sized for the information it conveys, though it lacks depth, which is reflected in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple schema but no output schema and no annotations. The description does not explain the update behavior (e.g., partial vs. full update), return value, or any important context. It is too minimal to be considered complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters (id, name, description). The description adds no additional meaning beyond what is present in the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update a VAST 4.2 creative' clearly states the verb and resource, and distinguishes it from sibling tools like vast42_update_ad or vast42_update_placement. It is unambiguous and specific to the creative entity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, contexts, or exclusions. The description only states the action 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.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only restates the operation ('Delete') without disclosing any behavioral traits such as permanence, impact on associated data, or requirements for deletion. The description adds no context beyond what the name already implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant wording. It is concise and front-loaded, though minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no annotations and no output schema, the description is insufficiently complete. It omits critical context such as whether deletion is permanent, what happens to associated schedules, and any constraints on when to delete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the single parameter 'id' with description 'VAST schedule ID'. The tool description does not add any additional meaning about the parameter, so the baseline of 3 applies for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Delete' and resource 'VAST schedule', clearly distinguishing this from sibling tools like vast_get_schedule, vast_create_schedule, and vast_update_schedule. The 'vast' prefix differentiates it from the generic delete_schedule 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/5Does 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, prerequisites, or alternatives. It does not mention that this should be used only for VAST schedules (vs. regular schedules) or indicate any dependency on schedule 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?
No annotations are present, so the description carries the full burden of disclosing behavior. It merely restates the operation without revealing that it is read-only, how pagination works, or what data is returned. The limit/offset parameters imply pagination, but the description does not explain default limits, result ordering, or whether archived/soft-deleted media are included. This lack of behavioral 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with a single sentence and no wasted words. For a simple list tool, this brevity is acceptable. However, it is so minimal that it borders on being a restatement of the tool name, lacking any additional structural elements like bullet points or context. It earns a 4 for efficiency but not perfection.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (2 optional parameters, no output schema), the description is minimally viable but leaves gaps. It does not clarify what 'non-linear media' refers to in the VAST context, nor does it mention pagination behavior or result scope beyond the schema. While not a complex tool, the description could be richer to aid an AI agent in understanding expected behavior and return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides full descriptions for both parameters (limit and offset), with 100% coverage. The description adds no extra meaning beyond the schema, so it meets the baseline but does not enhance understanding. It does not explain how these parameters interact or provide examples, leaving the agent to rely solely on the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'List all VAST non-linear media.' It uses a specific verb ('List') and resource ('VAST non-linear media'), which distinguishes it from sibling tools like vast_get_non_linear_media, vast_create_non_linear_media, and vast_update_non_linear_media. The inclusion of 'all' clarifies the scope, making it evident this is a listing operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not mention when to use this tool versus alternatives, nor does it state any exclusions or prerequisites. It is a bare statement with no context on when to invoke it or how it differs from similar list tools like vast_list_linear_media or vast_list_media.
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?
The description provides no behavioral context beyond the tool's name. With no annotations available, the description carries the full burden of disclosing effects, permissions, or reversibility, but it discloses none of these.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with exactly seven words. Every word is purposeful, and there is no wasted content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is too sparse to be considered complete. It does not explain what fields can be updated, whether the operation is partial or full replacement, or what the response will be.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers 100% of parameters with descriptions, so the baseline is 3. The description adds no additional parameter semantics, but the schema provides sufficient meaning for id, zone, and channel.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Update a VAST channel zone assignment.' It uses a specific verb (update) and identifies the resource (VAST channel zone assignment), which distinguishes it from sibling tools that create, delete, get, or list channel zone assignments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 verb 'update' implies modifying an existing assignment, but there is no explicit mention of prerequisites, what fields can be changed, 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 simply says 'bulk create', which implies a write operation, but does not disclose whether the operation is atomic, what happens on partial failures, whether there are rate limits, or any validation requirements. 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded with the key action. However, it is almost too terse, omitting any additional useful context that could be included without becoming verbose. It does not waste words, so it earns a slightly above-average score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there are no annotations, no output schema, and the items array parameter is loosely defined (additionalProperties: {}), the description is insufficiently complete. It does not explain what fields are expected in each item, how many items can be submitted, or the response/error format. The context of sibling tools like create_catalog_ad_item and draft_create_catalog_ad_item suggests more detail is needed to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for both parameters (campaign_id and items), so schema coverage is 100%. The description does not add any extra meaning beyond the schema, such as constraints on the items array structure or size limits. Since the schema handles the basics, a baseline of 3 is appropriate, but the description could have compensated for the vague item object definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (bulk create), the resource (catalog ad items), and the scope (in a campaign). It is specific and distinguishes itself from the singular create_catalog_ad_item tool by using the word 'bulk', making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this bulk operation versus the singular create_catalog_ad_item or other related tools. There is no mention of preferred scenarios, limitations, or alternatives. The description only states the action without contextual 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that a new key is created, but omits details such as whether keys must be unique, any authentication requirements, whether creation is idempotent, or what response to expect. For a mutation tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. It front-loads the action and object clearly, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter create operation, the description is minimally viable. However, given no annotations or output schema, more context about return values, uniqueness constraints, or error cases would improve completeness. It is adequate but lacks depth for a full agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter key_name, and the schema already documents its type and description. The tool description adds no extra meaning or usage examples for the parameter, but the baseline of 3 applies because the schema fully covers the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and the resource ('beacon signing key'), making the purpose immediately understandable. It does not explicitly contrast with sibling tools like list/get/update/delete, but the 'create' verb inherently differentiates it from read/update/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/5Does 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 verb 'create' implies use when a new signing key is needed, but there is no explicit statement about context, prerequisites, or when to prefer validate/list/get instead. The presence of validate_beacon_signing_key suggests potential distinction, but it is not 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'create' with no mention of auth requirements, idempotency, error behavior (e.g., failure if name already exists), or what happens to existing data keys. The uniqueness constraint appears only in the schema, not in the description, leaving the agent without important behavior 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the action and resource. Every word earns its place; there is no redundancy or filler. This is ideal conciseness for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter create operation with full schema coverage and no output schema, the description is minimally sufficient. However, it omits context about uniqueness enforcement, return value, or typical usage (e.g., creating targets afterwards). Given the simplicity, it's adequate but with clear gaps that prevent a higher score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters (name and type) are fully documented in the schema. The description itself adds no parameter-specific information beyond what the schema already provides. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does 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 'data key', with the purpose 'for custom targeting'. This distinguishes it from sibling tools like create_data_key_target, which creates a target rather than a key. However, it lacks additional context about the key's role or scope, so it's not a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 update_data_key or create_data_key_target. There are no exclusions, prerequisites, or context about the typical workflow (e.g., create key before creating targets). This is a clear 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 only says 'Create a new demand endpoint' and gives no information about required setup, side effects, validation rules, whether the endpoint is active immediately, or what response to expect. For a mutation with 15 parameters, 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundant content. It is concise and easy to scan. However, it offers no additional context beyond the tool name, so while it earns full marks for brevity, it lacks informative substance that would make it more valuable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (15 parameters, nested objects, no output schema, no annotations), the description is too minimal to be considered complete. It does not explain what a demand endpoint is, what the return value will be, or what consequences creation has. The schema covers parameter semantics but not the operational context, so the description should do more.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the structured schema already documents every parameter. The description itself adds no parameter-level detail, but the schema compensates fully with descriptions, enums, and required fields. Baseline 3 is appropriate because the schema does the heavy lifting and the description does not need to repeat it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and names the exact resource ('demand endpoint'), clearly distinguishing this from sibling tools like update_demand_endpoint, delete_demand_endpoint, and get_demand_endpoint. The word 'new' reinforces the creation intent. No ambiguity about 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/5Does 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., an existing demand_source), nor does it explain when a create operation is appropriate compared to update or list operations. The only implied usage is 'when you need to create a new endpoint,' which is not explicit enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 responsibility for behavioral disclosure. It only says 'create' which implies mutation, but omits side effects, required parameters, defaults, or return value. For a 13-parameter operation, 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. While under-specified for the tool's complexity, it is structurally efficient and not padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 13 parameters, no annotations, and no output schema, the description is inadequate. It fails to mention required fields, defaults, or when to use this over related tools, leaving the agent under-informed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no parameter-level meaning beyond what the schema already provides, such as defaults or mutual exclusions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a new image ad item, with 'banner' as a clarifying synonym. It distinguishes this from sibling ad-item creation tools (custom HTML, native, rich media) by explicitly naming 'image'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided for when to use this tool versus alternatives such as draft_create_image_ad_item or create_native_ad_item. The description is purely a purpose statement with no contextual hints or exclusions.
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 present, so the description carries the full burden of behavioral disclosure. It simply states 'delete' without mentioning that this is irreversible, whether it cascades to dependent resources, or any required permissions. This is a significant gap 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of four words, directly stating the action and target. It is concise and avoids any unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter delete operation, the description is minimally sufficient. However, given no annotations or output schema, it lacks important context about side effects or irreversibility, making it only barely adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a clear description for the 'id' parameter. The tool description adds no additional meaning beyond what the schema already provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a beacon signing key' uses a specific verb and resource, clearly indicating the operation. It distinguishes this tool from sibling tools like create, update, get, and list for beacon signing keys.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 implies deletion but does not state exclusions, prerequisites, or scenarios where a different action (e.g., update or validate) would be 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?
There are no annotations, so the description must disclose behavioral traits, but it only says 'Remove' without explaining permanence, reversibility, side effects, or required permissions. For a deletion/mutation tool, this leaves significant uncertainty about what happens to the zone and channel after removal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the operation with no filler. It is front-loaded with the verb and object, making it easy to parse. For a simple one-parameter delete operation, this length is appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, with one parameter and no output schema, so a short description is acceptable. However, it lacks clarification that the zone object itself is not deleted (only the assignment), and it omits any mention of whether removal is permanent or has associated effects. With no annotations to fill the gap, slightly more context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage for the single id parameter with the description 'Channel zone assignment ID'. The tool description adds little beyond that, only implying the id identifies the assignment to remove. Since the schema already carries the semantic weight, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove') and the resource ('zone from a channel'), which conveys the main purpose. However, it is slightly ambiguous whether it removes the zone object itself or just the assignment relationship, though the tool name and id parameter clarify it targets the assignment. It does not explicitly differentiate from the similar vast_delete_channel_zone_assignment sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like create_channel_zone_assignment, update_channel_zone_assignment, or vast_delete_channel_zone_assignment. The usage context is only implied by the tool name and description, with no exclusions or conditions.
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 transparency, but it merely repeats the tool name. It does not disclose whether deletion is permanent, irreversible, dependent on other resources, or subject to permission/validation checks. No behavioral context is added beyond the word 'delete.'
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that accurately and directly conveys the tool's purpose. It contains no unnecessary words or filler, earning full marks for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema, so the description is minimally viable. However, it lacks any mention of the operation's impact (e.g., whether deletion cascades, affects associated documents, or requires special permissions). For a destructive action, slightly more context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully documents the single parameter 'id' as 'Contract template ID' with 100% coverage. The description adds no further semantic detail, so the baseline score of 3 applies. No compensation is needed since the schema is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 contract template'), matching the tool name directly. This distinguishes it from sibling tools like create_contract_template, update_contract_template, and get_contract_template by explicitly indicating the destructive operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 is no mention of prerequisites, side effects, or scenarios where another operation (e.g., archive) might be more appropriate. The description only states what it does, not when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It only states the delete action but does not mention whether deletion is permanent, cascade effects, permissions required, or any side effects. The agent is left without critical 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately conveys the operation. It is efficient and front-loaded, though extremely terse. It earns a slightly below-perfect score because it omits potentially important context that could be added without significant bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's simplicity (single required parameter, no output schema), the description is incomplete for a mutation operation. It lacks any mention of permanence, reversibility, permissions, or related data impact. Without annotations, the agent has insufficient context to safely invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the sole 'id' parameter, which is already described as 'Data key target ID'. The description adds no additional parameter meaning beyond what the schema provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly uses the specific verb 'Delete' with the resource 'data key target', and it distinguishes this tool from its siblings (create/update/get/list) by the action performed. No ambiguity exists about the tool's core function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 prerequisites, idempotency, or consequences. The usage context is only implied by the verb and resource 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, the description carries the full burden, but it merely restates the operation without disclosing whether deletion is permanent, reversible, or has cascading effects. No permission or response information is provided, which is a significant gap for a delete 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no unnecessary words. It is front-loaded and easy to read, though perhaps under-specified, but it earns its place as a concise purpose statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, this description is too sparse. It fails to explain the return value, success/failure behavior, or side effects of the deletion, leaving the agent without essential context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema includes a single required parameter 'id' with a clear description, so schema coverage is 100%. The description adds no additional semantic detail beyond the schema, warranting the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Delete' and the resource 'demand endpoint,' clearly distinguishing it from sibling operations like get_demand_endpoint, create_demand_endpoint, and update_demand_endpoint. It is unambiguous and identifies exactly 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/5Does 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, prerequisites, or alternatives. It does not mention any conditions for deletion, related considerations, 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, the description must carry the full burden of behavioral disclosure. It only states that the tool deletes a video creative, but omits critical safety information such as whether deletion is irreversible, if there are cascading effects, or whether specific permissions are required. This is a meaningful gap 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no filler or redundancy. It is appropriately sized for the simplicity of the operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema, and the description accurately conveys the basic function. However, for a delete operation with no annotations, the lack of any note about permanence, failure conditions, or response format leaves a clear gap. The description is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the single 'id' parameter, which is described as 'Creative ID'. The description adds no additional semantic meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does 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 (video creative), which distinguishes it from generic delete_creative and delete_audio_creative. However, it adds no detail beyond the tool name itself, so it's specific but not enriched with scoping or conditions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 delete_creative or replace_video_creative_file. It does not mention prerequisites, possible restrictions, or effects on related entities, leaving the agent without decision-making 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, the description must carry the full burden of behavioral disclosure, but it only says 'Delete a draft image ad item.' It doesn't mention whether the deletion is reversible, whether it's a soft delete, what happens to dependent entities, or any required permissions. For a mutation tool, this is a significant transparency 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no filler. It's appropriately sized for the tool's simplicity and front-loaded with the key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter delete operation, the description is minimally viable: it states what the tool does. However, it lacks any context about the deletion's effect on drafts (e.g., whether deletion is permanent, tied to a draft workflow) or what response to expect. Given no output schema and no annotations, the description is just barely adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the single parameter fully, describing 'id' as 'Draft ad item ID.' The description adds no additional meaning beyond this. Since schema coverage is 100%, a baseline of 3 is appropriate; the description doesn't need to compensate for undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Delete') and resource ('draft image ad item'), making the tool's function clear. It distinguishes from sibling tools like 'delete_image_ad_item' by the 'draft' qualifier, though it doesn't explicitly contrast with non-draft delete variants.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. There's no mention of when to use this tool versus alternatives (e.g., 'delete_image_ad_item' or other draft delete tools), nor any prerequisites or exclusions. The description relies entirely on the name to convey its scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 the action without revealing whether deletion is permanent or reversible, what happens to related data, or any prerequisites (e.g., item must be in draft state). For a delete operation, this lack of transparency is a significant risk for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a concise single sentence with no redundant wording, effectively stating the core purpose. However, it is so terse that it omits useful behavioral or contextual details that could be added without significant bloat, so it doesn't earn a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and a single parameter, the description is minimal. It lacks critical behavioral details (permanence of deletion, draft-specific behavior, relationship to published items) that would be necessary for an agent to safely invoke this delete operation. The description is incomplete for a destructive action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage for the only parameter (id) with a description ('Draft ad item ID'), so the baseline is 3. The tool description adds no additional parameter context, but the schema already sufficiently documents the meaning of the id field.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Delete') and a precise resource ('draft native ad item'), clearly distinguishing it from sibling tools like delete_native_ad_item (which targets non-draft items) and other draft_* delete tools for different ad types. This is unambiguous and prevents confusion among similar 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/5Does 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 that this is specifically for draft (unpublished) items, nor does it reference the sibling delete_native_ad_item for finalized items. The agent must infer usage solely from the tool name, which is insufficient for confident selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral disclosure burden. It implies read-only behavior via 'Get details' but does not state whether any permissions are required, what happens if the campaign does not exist, or what exactly 'details' includes. The lack of an output schema further compounds this.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler words. It efficiently communicates the core purpose without unnecessary detail, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema, but the description is minimal. It doesn't define what 'details' means or elaborate on the draft vs live campaign relationship, which is relevant given the large sibling set. Still, for a simple get, it meets the minimum viable threshold.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the single parameter `id` as 'Draft campaign ID', so schema coverage is 100%. The description adds no extra meaning beyond the schema, which meets the baseline for high coverage. No compensation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does 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 (a specific draft standard campaign), which is distinct from list operations like draft_list_campaigns. However, it does not explicitly differentiate from the non-draft get_campaign or explain the 'standard' qualifier, though the tool name provides some 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as get_campaign or draft_list_campaigns. The description does not explain the draft workflow, prerequisites, or situations where a different campaign getter would be more appropriate. This is a clear 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, the description must carry the full burden of behavioral disclosure, but it only states 'Get details,' which is essentially the tool's core purpose. It does not disclose whether the operation is read-only (though implied), what happens for non-existent IDs, or any authentication requirements, providing no additional 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of eight words, front-loaded with the verb and resource. Every word earns its place, and there is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with one parameter, the description is minimally sufficient, but it lacks details about the return payload or any special behavior of draft items. Given no output schema and no explanation of what 'details' include, the agent must rely on assumptions about the API's standard getter behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a single 'id' parameter described as 'Draft ad item ID,' so the schema does the heavy lifting. The description adds minimal meaning by stating 'specific' and 'draft image ad item,' which reinforces the parameter's role, but it does not go beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get details') and identifies the resource ('specific draft image ad item'), clearly distinguishing it from sibling tools like draft_get_rich_media_ad_item or draft_get_custom_html_ad_item by the 'image' qualifier. It does not explicitly contrast with non-draft get_image_ad_item, but the 'draft' prefix in both the name and description conveys the 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/5Does 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 draft_get_ad_item or the non-draft get_image_ad_item. The description does not mention exclusions, prerequisites, or typical use cases, leaving the agent to infer 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 only states the obvious listing action and does not add context about pagination, default behavior, filtering, or whether it returns only draft items (though 'draft' is implied). No side effects or additional details are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler or redundant content. Every word contributes to clarity, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with two parameters and no output schema, the description is minimally adequate. However, it lacks any context about behavior beyond the basic action, such as ordering, default limit application, or differences from the broader draft_list_ad_items tool, leaving some gaps for a fully self-sufficient description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'limit' and 'offset' parameters having clear descriptions. The tool description adds no parameter-specific information, but the schema already documents syntax and defaults, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all draft custom HTML ad items' uses a specific verb (List) and resource (draft custom HTML ad items), making the primary action clear. It does not explicitly differentiate from similar sibling tools like 'draft_list_ad_items' or 'draft_list_rich_media_ad_items', but the resource type is well specified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of when to prefer this over draft_list_ad_items, draft_list_image_ad_items, or other draft list tools, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 says 'List all' without noting that results are paginated (despite limit/offset parameters), what the return format is, or that it is a read-only operation. The word 'all' may mislead an agent into expecting all results in one response.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler. It is front-loaded and immediately conveys the core action and resource, making it easy for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with only pagination parameters and no output schema, the description is minimally viable. However, it omits details about pagination behavior, the meaning of 'draft' in this context, and does not differentiate from the non-draft counterpart, leaving some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema thoroughly describes both limit and offset parameters (100% coverage). The description adds no extra meaning about the parameters, so this dimension is at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does 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 (draft image ad items), and the scope is indicated by 'all'. It distinguishes from siblings like list_image_ad_items and draft_list_ad_items by combining the draft status and image type, though it does not explicitly mention the 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as list_image_ad_items (non-draft) or draft_list_ad_items (all types). There is no mention of exclusions, prerequisites, or when other tools would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only restates the tool's purpose without adding behavioral details such as pagination behavior, result ordering, or whether the list is scoped to a specific advertiser. The statement 'List all draft native ad items' adds no information beyond the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler words. It is appropriately brief for a simple list operation, though it could include more context without becoming wordy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is very minimal and does not clarify important context such as whether 'all' means across the entire account, how pagination works, or how this tool differs from siblings like list_native_ad_items and draft_list_ad_items. Given the large sibling set, this lack of context is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for both 'limit' and 'offset', so the baseline is 3. The tool description does not add any parameter information, but the schema already fully documents the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('List') and resource ('draft native ad items'). It also includes the scope 'all' which distinguishes it from sibling tools like list_native_ad_items (likely non-draft) and draft_list_ad_items (all ad item 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention that list_native_ad_items exists for live items or draft_list_ad_items for all types, nor does it state any exclusions or preferred 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 must disclose behavioral traits. It only states 'Update an existing draft placement' without explaining what happens to the draft, whether it's a partial update, any permissions required, or the response format. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, effectively front-loading the core purpose. However, its brevity sacrifices needed operational details, so it's not perfect.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a nested object parameter, no annotations, and no output schema, this minimal description doesn't explain the structure or behavior of the 'draft' object, nor does it mention return values or prerequisites. This is a significant gap for an update tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (both 'id' and 'draft' are described). The description adds no additional parameter semantics beyond the schema, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Update') and resource ('existing draft placement'), clearly distinguishing this from sibling tools like draft_create_placement, draft_get_placement, and draft_delete_placement. It also differentiates from the non-draft 'update_placement' by including 'draft'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 draft_create_placement or update_placement. It doesn't mention the draft lifecycle or that changes may need to be saved via draft_save_campaign, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden, yet it only implies read-only behavior via 'Get details'. It does not mention prerequisites (e.g., that the zone must be archived), error behavior, auth requirements, or what the returned 'details' actually include.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence of eight words, front-loaded with the action verb and zero redundant or filler content. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an extremely simple one-parameter getter, the description is minimally viable: purpose is stated and the schema handles the only input. However, with no output schema, it omits what 'details' of the archived email zone look like, and it fails to disambiguate from similarly named siblings in a very large tool list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%—the single required 'id' parameter is documented as 'Archived email zone ID'. Since the schema fully covers the parameter, the baseline of 3 applies, and the description adds no additional parameter context, which is acceptable but earns no credit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get details of') and clearly names the resource ('a specific archived email zone'), making the action and object unambiguous. However, it does not explicitly contrast with sibling tools like get_email_zone or get_archived_zone, relying on the tool name to carry the 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to choose this tool over the many near-identical siblings such as get_archived_zone, get_email_zone, or list_archived_email_zones. There are no when-to-use statements, exclusions, or alternative tool references, so the agent must infer context purely from naming conventions.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 says 'Get details,' which implicitly conveys read-only behavior but adds no context about error handling, permissions, rate limits, or what fields are returned. This is insufficient for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that directly states the operation and resource. It is front-loaded and contains no superfluous information, earning full marks for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with one parameter and no output schema, the description is minimally adequate but incomplete. It doesn't specify what 'details' are returned, nor does it clarify read-only behavior beyond the verb. The lack of output schema and annotations leaves the agent without full information, but the simplicity of the tool mitigates the gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of the single parameter 'id' with a description 'Campaign assignment ID.' The tool description adds no additional meaning beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('campaign assignment'), indicating a read operation for a single entity. It is clear and unambiguous, though it doesn't explicitly differentiate from siblings like vast_get_campaign_assignment or draft_get_campaign_assignment, so it doesn't fully earn 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as list_campaign_assignments or vast_get_campaign_assignment. It doesn't mention exclusions, prerequisites, or why an agent would choose this over a sibling, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Get details' without confirming this is a read-only operation, what fields are returned, or whether special permissions or error cases apply. This adds minimal context beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words or filler. It clearly conveys the action and resource in the most efficient way possible, earning full marks for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with one parameter and no output schema, the description is adequate but not complete. It omits details about the return value, error handling, and the fact that this is a read-only counterpart to create/update/delete data key tools. A more complete description would mention these aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the single 'id' parameter with a description ('Data key ID'), achieving 100% schema coverage. The description adds no additional meaning beyond implying that a specific data key is identified by its ID, which is already in the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does 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 'data key', with 'specific' indicating a single entity rather than a list. This distinguishes it from list_data_keys, though it does not explicitly name sibling tools like get_data_key_target; however, the resource is clearly different.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 list_data_keys, create_data_key, or get_data_key_target. The description only states what it does, with no mention of alternatives, prerequisites, or 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?
With no annotations provided, the description carries the full burden. It only says 'Get details', which largely repeats the tool name, and doesn't disclose error handling, permissions, return format, or behavior when the ID doesn't exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is a single six-word sentence, front-loaded with the action and resource, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID tool, the description is minimally acceptable but lacks information about the response structure (no output schema) and edge-case behavior. It doesn't explain what 'details' include, leaving the agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers the single 'id' parameter with 'Day parting ID', so schema coverage is 100%. The description adds no substantial parameter semantics beyond implying the ID selects the rule.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does 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 day parting rule'), making it a get-by-ID operation. It implicitly distinguishes from list/create/update/delete siblings via 'specific', but 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus list_day_partings or other retrieval tools. The description only states what it does, not the conditions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'Get', implying a read-only operation, but provides no details about the return value (e.g., format of the tag, whether it is a script or URL), possible side effects, or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the tool's action and target. No filler or redundant information; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool—one parameter, no output schema, no annotations—the description is minimally viable but lacks contextual richness. It does not explain what a conversion tracking tag is, what it looks like, or how it differs from similar getter tools, leaving some ambiguity for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% coverage for the single parameter 'id', including its description ('Email zone ID'). The tool description adds no additional parameter context, which is acceptable given the schema's completeness, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('conversion tracking tag for an email zone'), clearly conveying the tool's function. While it does not explicitly distinguish itself from sibling tools like get_email_zone_tag, the phrase 'conversion tracking tag' narrows the purpose beyond a simple zone tag.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_zone_conversion_tag or get_email_zone_tag. There is no mention of prerequisites, context, or exclusions, leaving the agent to infer usage from isolated 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 full responsibility for behavioral disclosure. It indicates a read operation via 'Get' but does not mention return format, error behavior, permissions, or any side effects. It adds little beyond what the tool name implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the purpose without any fluff. Every word is necessary and direct.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-id tool, the description is minimally adequate: it states the action and the schema defines the parameter. However, it omits any context about how to obtain a valid geo target ID or what 'details' includes, and it doesn't help differentiate from many similar getter tools in the sibling list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the only parameter ('id' with type number and description 'Geo target ID') with 100% coverage. The description adds no additional meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get details') and the resource ('a specific geo target'), which distinguishes it from list_geo_targets and CRUD siblings like create/update/delete. However, 'details' is vague and doesn't specify what fields or structure the response contains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like list_geo_targets to find IDs or geo target management tools. Usage is only implied by the name and description, 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 exist, so the description is the only source of behavioral context. It only says 'Get details' and doesn't disclose potential errors, authentication requirements, or response format. It also doesn't explicitly confirm read-only semantics, though 'get' implies it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, directly to the point, with no unnecessary words. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple get-by-id with one parameter, but the lack of output schema and annotations means the description should provide more context about the returned details or error behavior. It's minimally acceptable but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully documents the single `id` parameter with 100% coverage, so the description adds no additional parameter semantics. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Get') and resource ('postal code target'), and uses 'specific' to indicate single-item retrieval by ID. It is distinguishable from list/create/update/delete siblings by its 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 Guidelines2/5Does 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 vs alternatives. It doesn't mention that it requires an existing target ID, nor does it contrast with list_postal_code_targets or other get_*_target tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description must carry the full burden of behavioral disclosure. The description only says 'Get details' which implies a read-only operation, but it doesn't confirm safety, permission requirements, or that no side effects occur. It also doesn't describe what 'details' includes or whether pagination or filtering applies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence with no filler, making it easy to parse. It conveys the core action and resource immediately. There is no redundant information, so every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get operation with two required IDs and no output schema, the description is minimally adequate but leaves gaps: it doesn't state that the product source is uniquely identified by the publisher_id and source_id combination, nor does it mention potential errors or read-only nature. Given the lack of annotations and output schema, more context would help, but the tool's simplicity mitigates the need.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with descriptions for both publisher_id and source_id. The description itself adds no parameter semantics beyond what the schema already states. Since schema coverage is high, this dimension meets the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' with the resource 'product source' and qualifier 'specific', clearly indicating a single-item retrieval operation. It distinguishes from sibling tools like list_product_sources, create_product_source, and delete_product_source by implying a targeted fetch. However, it doesn't explicitly mention the required publisher_id/source_id scope, though this is evident from the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 that list_product_sources enumerates sources, nor that create/update are for modifications. There is no context or exclusions, leaving the agent to infer usage from the tool 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?
No annotations are provided, so the description alone must disclose behavioral traits. It only says 'Get', adding no details about return format, authentication needs, failure modes, or whether the report is a file download or structured data. This is minimal transparency for a retrieval 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single eight-word sentence with no wasted words, making it highly concise and front-loaded. While brevity is positive, it omits potentially useful details, but this is a minor trade-off for a simple get operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With three required parameters and no output schema, the description should provide more context about what the response contains (e.g., report data, file URL) and any preconditions. It lacks this information, making it incomplete for an agent to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all three parameters with clear one-line descriptions (e.g., 'Generated report ID'). The tool description adds no additional meaning beyond restating the relationship 'from a schedule' and does not explain that all three IDs are jointly required to uniquely identify the report.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a single generated report within the context of a schedule, using the verb 'Get' and identifying the resource as 'a specific generated report'. It distinguishes itself from list operations but does not explicitly name sibling alternatives like list_report_schedule_generated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The word 'specific' implies the caller already possesses the identifiers, providing implicit guidance that this is for retrieval of one item rather than enumeration. However, there is no explicit statement of when to use this tool versus the sibling list tools, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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, but 'Get details' adds no behavioral context beyond the tool name. It does not disclose return format, permissions, or error behavior, nor does it describe what 'details' include; it simply restates the tool's purpose without enriching 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no extraneous information. It is efficiently front-loaded and every word contributes to clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-item getter with one parameter, the description is minimally adequate. However, without an output schema or annotations, it leaves gaps about the return structure and potential error conditions, making it not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters, with 'id' described as 'Ad item ID'. The tool description adds no additional meaning to the parameter beyond what the schema already provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get details') and the resource ('specific rich media ad item'), which distinguishes it from list tools like 'list_rich_media_ad_items' and other ad item getters by type. However, it does not explicitly name alternatives as seen in high-scoring examples.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the many sibling tools such as 'get_ad' or 'get_image_ad_item'. It does not mention any alternatives or exclusion criteria, offering only the basic function 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?
No annotations are provided and the description carries the full transparency burden. The phrase 'Get details' implies a read operation, but it doesn't disclose error behavior, return shape, authentication needs, or whether the schedule is draft/live.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or repetition. It states the core purpose efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter getter with no output schema, the description is minimally adequate but doesn't explain what fields/details will be returned or how errors are signaled. It doesn't distinguish the schedule domain among multiple sibling schedule tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the single parameter 'id' as 'Schedule ID', so schema coverage is 100%. The description adds no further semantics beyond the schema, matching the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves details for a single schedule, using a specific noun and scope ('specific schedule'). It distinguishes from list_schedules by implying single-item retrieval, though it doesn't name sibling getters for other schedule types (e.g., draft_get_schedule, vast_get_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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternative schedule tools such as list_schedules, create_schedule, or draft_get_schedule. The context is implied by the name and description but there are no explicit exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states 'Get details' with no mention of return format, error conditions, or the read-only nature beyond the verb. Lacks context about permissions or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of six words, front-loaded with the verb and object. It is highly concise with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with 2 params and no output schema, but the description doesn't specify what 'details' entails or the return structure. Given the absence of an output schema, the agent might need more context about what fields are returned. It is minimally adequate but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents both parameters (id and contract_id) with descriptions. The description doesn't add any additional semantic information beyond what's in the schema, so it meets the baseline for 100% coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and resource 'signature request', clearly indicating retrieval of a single entity. It distinguishes from list_signature_requests (plural listing) and get_contract_active_signature_request (active variant), though it doesn't explicitly state the ID-based lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 that list_signature_requests should be used for multiple records or that get_contract_active_signature_request is for the active one. The description provides 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.
- 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 conveying behavioral traits. It only says 'Get details', implying a read operation, but fails to disclose error behavior, required permissions, or whether the user attribute must exist. No contradiction with annotations exists, but no extra context is added.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant words or filler. It efficiently communicates the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with fully described parameters and no output schema, the description is minimally adequate. However, it leaves out information about the return format or behavior, which would be valuable given the lack of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with both parameters documented clearly in the input schema. The description adds no additional meaning beyond what the schema already provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('specific user attribute'), and includes the context ('in a user database'). The word 'specific' distinguishes it from list-type operations like list_user_attributes, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 list_user_attributes, create_user_attribute, or update_user_attribute. The description lacks context about the appropriate use case 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 the full burden for behavioral disclosure. It reveals only that the operation is a 'Get' (read), but says nothing about what the geographic summary contains, how data is aggregated, whether filters are required, or what the response looks like. This is minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single succinct sentence with no redundant words. It is appropriately concise for a getter tool, though it lacks any additional structural elements like sections or examples. It earns its place as a clear purpose statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 6 optional parameters, no output schema, and no annotations, yet the description provides only a bare phrase. It does not explain what a 'geographic summary report' is, how it relates to other VAST reports, or how the filters affect the output. This is insufficient context for correct use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all 6 parameters, so the baseline is 3. The description itself adds no parameter semantics, but the schema already provides clear descriptions for each filter (e.g., 'Filter by zone IDs'). The description does not need to repeat this.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get VAST geographic summary report' clearly states the action (Get) and the specific resource (VAST geographic summary report), distinguishing it from sibling tools like get_geo_summary_report and get_vast_report. The verb and resource are 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool vs. alternatives such as get_geo_summary_report or get_vast_report. There is no mention of when to choose this over others, no prerequisites, and no 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, and the description only states the listing scope. It does not mention whether archived or draft campaigns are included, pagination behavior beyond the schema parameters, or any side effects (though listing is implicitly 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no filler. It front-loads the verb and resource and is appropriately sized for a simple listing tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose and the schema handles parameters, but with no annotations and a large set of sibling listing tools, the description leaves ambiguity about what 'all types' includes and when to choose this over list_campaigns. Given the tool's simplicity, this is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, documenting limit and offset with defaults. The description adds no extra semantics about these parameters, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with resource 'all campaigns' and adds scope 'across all types'. It clearly communicates a broad listing operation and implicitly distinguishes from sibling tools like list_campaigns that may be type-specific, though it doesn't name alternatives explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the many sibling listing tools (e.g., list_campaigns, vast_list_campaigns, draft_list_campaigns). It does not mention filtering, exclusions, or alternative tools, leaving the selection decision entirely to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only repeats the tool's name and does not mention pagination behavior, return format, or any side effects. The presence of limit/offset params is not disclosed in the description, leaving the agent without useful 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. It directly states what the tool does. This is appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema and annotations, the description is somewhat sparse. It does not explain the return structure or clarify how 'all' relates to pagination, which could confuse an agent. However, for a simple list tool with well-described parameters, it is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the parameters 'limit' and 'offset' are fully documented in the schema. The description adds no additional meaning beyond the schema, which aligns with the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('List') and a specific resource ('native ad templates'), clearly indicating what the tool does. However, it does not differentiate from the sibling tool 'list_ortb_native_templates', which could refer to a related but distinct resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'list_ortb_native_templates' or other list tools. It does not state any exclusions or preferred usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It merely restates the operation ('List all') without mentioning pagination, default limits, or any side effects. The phrase 'all' could be misleading given the limit/offset 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It succinctly captures the verb and resource in a clear structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the description omits any mention of return values or pagination behavior. The absence of an output schema and the presence of a similarly named sibling (list_native_templates) leave some ambiguity that a more complete description could resolve.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents both parameters (limit and offset) with descriptions, providing 100% coverage. The description adds no additional parameter semantics, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and resource ('OpenRTB native templates') scoped to the AdButler account. The inclusion of 'OpenRTB' helps differentiate it from the generic 'list_native_templates' sibling, though it does not explicitly explain the 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/5Does 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 such as list_native_templates or other ORTB asset list tools. It lacks any exclusions or contextual hints about suitability.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 should carry the full burden of behavioral disclosure. It only says 'List all PMP deals' without mentioning pagination behavior (despite limit/offset parameters), default limit, result structure, or whether it returns a summary or full objects. The read-only nature is implied but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the purpose. It contains no fluff and is appropriately brief for a simple list tool, though it is minimal enough that it misses opportunities to convey more useful context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a paginated list operation with two parameters and no output schema or annotations. The description is too sparse: it does not mention pagination, limit/offset usage, or that get_pmp_deal exists for fetching a specific deal. This leaves the agent without enough context to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents limit and offset with descriptions. The tool description adds no additional meaning beyond what the schema provides, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 ('all PMP deals') with scope ('in your AdButler account'). This distinguishes it from sibling tools like get_pmp_deal, create_pmp_deal, update_pmp_deal, and delete_pmp_deal, which are all different 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not mention when to use this tool vs. alternatives like get_pmp_deal, nor does it clarify that this is for bulk listing while get_pmp_deal is for retrieving a single deal. There is no explicit when/when-not or alternative tool reference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits but fails to mention pagination behavior, default/max limit, or the read-only nature beyond the verb 'list'. The claim 'List all' conflicts with the limit/offset parameters, suggesting incomplete or potentially misleading information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler or redundant phrasing. It gets straight to the point, though it lacks any additional structural breakdown such as field descriptions or examples.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal. With no output schema or annotations, it fails to explain what a rich media creative is, what fields are returned, or how pagination works. The 'all' wording also oversimplifies the behavior given the limit/offset parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes both parameters (limit and offset) with clear descriptions, providing 100% schema coverage. Per guidelines, the baseline is 3; the description itself adds no extra parameter meaning beyond what the schema already says.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a clear resource ('rich media creatives'), which distinguishes it from sibling list tools like list_video_creatives, list_audio_creatives, and list_rich_media_ad_items. The phrase 'List all' also conveys a comprehensive listing intent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as list_creatives, list_all_creatives, or other resource-specific list tools. No usage context, prerequisites, or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not explicitly state that the operation is read-only, nor does it disclose pagination behavior or the default/max limit of 100 results. The claim 'List all' contradicts the pagination parameters, making the behavior misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant phrasing or filler. It front-loads the primary action and resource. It earns its place by stating the purpose, though it could be slightly more informative without becoming verbose. The brevity is a positive, not a drawback.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description is too sparse. It does not explain what an 'attribute' is, what the response looks like, how pagination works, or that 'all' may require multiple calls due to the limit. The description leaves critical context missing, making it incomplete for an agent selecting and invoking the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all three parameters (user_db_id, limit, offset) already documented. The description adds no parameter-specific information beyond what the schema provides. Baseline 3 is appropriate because the schema handles parameter semantics, though the description's 'all' wording conflicts with the limit parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List'), the resource ('user attributes'), and the context ('in a user database'). It is specific enough to distinguish from siblings like get_user_attribute (single item) and list_user_dbs (different resource). The word 'all' is somewhat misleading given the limit parameter, but the core 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as get_user_attribute, create_user_attribute, or list_user_dbs. It does not mention exclusions or prerequisites. The only implied usage is that it lists attributes within a specific user database, but no explicit direction 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 only says 'Replace', implying a destructive mutation, but does not explain permissions, reversibility, how the new file is supplied, or what the response will be. This is minimal and leaves significant ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant words. It efficiently communicates the core action and resource. It is appropriately front-loaded, though it might be slightly under-specified, it is not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutating tool with no annotations and no output schema, the description is incomplete. It lacks context about how the file replacement works, prerequisites, potential side effects, and return values. The one-line description is not enough to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (the only parameter 'id' has type and description), so the baseline is 3. The description does not add any additional meaning about the parameter, and notably does not clarify how the replacement file is passed, which could be a gap. However, since the schema already documents the id parameter sufficiently, a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Replace' and the resource 'file on an image creative', which precisely identifies the tool's function. It also distinguishes it from sibling tools like replace_video_creative_file, replace_audio_creative_file, and replace_rich_media_creative_file by specifying 'image creative'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool vs alternatives. It does not mention that this is for image creatives specifically or how it differs from other replace_*_creative_file tools. No exclusions or contextual scenarios 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?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only says 'update' without explaining side effects, idempotency, whether all fields are required, or what happens if a field is omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It is concise and clearly structured, though it could be slightly more informative without violating conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotations, and the description doesn't explain return values, error handling, or behavioral nuances. For a 3-parameter update tool with one required parameter, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for all three parameters (id, name, type), giving 100% schema description coverage. The description adds no parameter-level insight beyond the schema, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an existing data key' uses a clear verb ('update') and resource ('data key'), and because sibling tools include create_data_key, delete_data_key, get_data_key, and list_data_keys, it clearly distinguishes itself as the modification operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives. It doesn't mention prerequisites, common use cases, or exclusions that would help an agent decide between update_data_key and 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, the description carries the full burden of behavioral disclosure. It only states that the tool updates an existing target but does not explain whether the update is partial or full, what happens if the ID does not exist, or what the response contains. For a mutation 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler words, making it efficient and front-loaded. It is appropriately sized for a simple CRUD operation, though it could include more behavioral detail without hurting conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an update tool with no annotations and no output schema, the description is incomplete. It lacks context about the data key target entity, the meaning of the target field, and how updates are applied. The schema helps with parameters but does not cover operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for all three parameters (100% coverage), so the description need not repeat them. However, the description adds no extra semantic context about the target field or update semantics, keeping it at the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (update) and resource (data key target), and 'existing' differentiates it from create/delete sibling tools. It is specific and unambiguous, leaving no doubt about the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 is no mention of prerequisites, whether to use create for new targets, or any conditions for updating, leaving the agent to infer on its own.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of explaining behavioral traits. It only states the basic action and gives no info about update semantics (e.g., whether unspecified fields are preserved or reset), validation, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One short, grammatically correct sentence that fully captures the tool's purpose. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The rich schema covers parameters, but there's no output schema, no mention of partial-update behavior, and no return value expectations. For a simple update tool this is acceptable but not complete; more context would help, especially given the large sibling set.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all 14 parameters with meaningful descriptions. The tool description adds no additional parameter context, but the baseline of 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does 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 type ('existing image ad item'), which distinguishes it from create/delete/get siblings. It's slightly terse but 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like create_image_ad_item or update_rich_media_ad_item. No context about partial updates, required fields, or prerequisites is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 only says 'update' without disclosing that it mutates state, requires specific permissions, or how it handles non-existent IDs. No side effects or idempotency info.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no redundancy. It is appropriately front-loaded but could add a bit more context without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple CRUD tool, but the description is minimal. It does not mention whether the update is partial or full, what the response contains, or error cases. The schema covers parameters, but the description lacks operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes both parameters with clear descriptions and 100% coverage. The description adds no additional parameter meaning beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 (existing trusted redirect domain), distinguishing it from create/delete operations. It is unambiguous and specific about the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like create_trusted_redirect_domain or delete_trusted_redirect_domain. The description doesn't mention prerequisites, exclusions, or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits but only states a generic create action. It does not mention any side effects, dependencies on an existing icon, dimension validation, or what happens on success/failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that clearly states the purpose without waste. However, it is almost too sparse, lacking additional context that could be included in a second sentence without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The low complexity (3 simple params, no output schema) is offset by the resource being a nested object (icon click fallback image) with likely dependencies on an icon. The description does not explain what a fallback image is or any constraints, leaving the agent without critical context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents all three parameters (name, width, height) with descriptions, and coverage is 100%. The description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create) and the specific resource (VAST 4.2 icon click fallback image). It distinguishes this from sibling tools like vast42_get/update/delete/list_icon_click_fallback_image and other create tools for different resource types (e.g., vast42_create_icon).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no context about when to use this tool versus alternatives, such as whether it must be associated with an existing icon or when a fallback image is required. No exclusions or conditional guidance 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?
With no annotations, the description carries full responsibility for behavioral disclosure. It only says 'Get', which merely echoes the tool name, and does not disclose return format, error behavior, or the fact that it is a read-only operation beyond the verb 'get'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It is concise and clearly placed, though it sacrifices substantive detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of a nearly identical sibling tool without the 'vast42' prefix, the description fails to clarify which version it targets. It also does not describe what is returned, making it incomplete for a simple get operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the 'id' parameter (100% coverage) with a clear description. The tool description adds no additional parameter semantics beyond implying that the ID identifies a single assignment.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a single VAST 4.2 campaign assignment' clearly specifies the action (get), resource (campaign assignment), scope (single), and version (VAST 4.2). This distinguishes it from list/create/update/delete siblings and names the exact entity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the similarly named 'get_campaign_assignment' or the list variant. The word 'single' implies an ID is needed, but alternatives, prerequisites, or exclusion criteria are not 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. 'Get' implies a safe read operation, but the description does not disclose the return format (e.g., whether it returns the full ad object or just the ID), error behavior (e.g., not found), permissions required, or any other side effects. This is a minimal gap, but without annotations, more context is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, 'Get a single VAST 4.2 universal ad ID,' with no redundant words, filler, or repetition. It is well-structured and front-loaded with the core action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema, so the description is mostly sufficient. However, it does not specify what the response contains (e.g., full ad details) or any error conditions. Given the low complexity, this is acceptable but leaves some gaps for an agent relying solely on the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% because the single parameter 'id' is already described as 'VAST 4.2 universal ad ID' in the input schema. The tool description adds no additional parameter information beyond what the schema provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a single VAST 4.2 universal ad ID' clearly states the verb (get), resource (universal ad ID), and scope (single), distinguishing it from sibling tools like vast42_list_universal_ad_ids, create, update, and delete. It is concise and unambiguous, though it does not explicitly mention 'by ID' or 'retrieves the full object'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives, such as the list function when multiple IDs are needed or create/update/delete for modifications. Usage is only implied by the name and the 'single' qualifier, but no alternatives 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?
With no annotations provided, the description is the sole behavioral disclosure. It only states 'List all' without revealing default limit, maximum results, pagination behavior, read-only nature, or any side effects. This leaves the agent to infer critical behavioral details from the schema and tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the verb 'List' and directly names the resource. There is no filler, and every word contributes to the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only two documented parameters, but the description lacks context about return format, default pagination, and how it relates to the many sibling ad-item tools. Since there is no output schema, this is a moderate gap in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents both parameters (limit and offset) with clear descriptions, so coverage is 100%. The tool description adds no parameter-level meaning beyond what the schema provides, earning the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and identifies the resource as 'VAST 4.2 ad items', clearly distinguishing it from single-item retrieval tools like vast42_get_ad. However, the word 'all' could mislead since the schema includes pagination parameters (limit, offset), implying it does not necessarily return every item in one response.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not mention when to choose this tool over alternatives such as vast42_get_ad, vast_list_ad_items, or other list tools, and it offers no exclusions or context about its role in the broader workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only states the operation without disclosing that results are paginated via limit/offset, with a default max of 100, so the claim 'List all' is potentially misleading. There are no annotations to convey side effects, so the description should explain behavior but does not.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler. It efficiently states the tool's purpose, though it could provide more context without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a two-parameter schema and no output schema or annotations, requiring the description to cover return values and behavioral details. It provides neither, leaving the agent unaware of the paginated response structure and default limits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes both limit and offset with clear descriptions, so the baseline is 3. The description adds no additional meaning beyond the schema, but that's acceptable given schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (List) and resource (VAST 4.2 non-linear media), distinguishing it from single-item getters and other media types. However, it does not differentiate from similar list tools like vast_list_non_linear_media, relying mostly on the version prefix.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided about when to choose this tool over alternatives such as vast42_get_non_linear for a single item or vast42_list_linears for linear media. The context implies it is the listing endpoint for non-linear media, but pagination behavior and use cases are not 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?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'Update' which implies mutation, but provides no details about side effects, idempotency, auth requirements, error behavior, or whether it is a partial or full update.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It is front-loaded with the verb and resource, making it easy to scan. However, it is slightly under-specified, which prevents a higher score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is too minimal. It does not clarify whether the update is partial or full, what happens when the id is invalid, or what the response contains. The schema alone provides parameter details, but operational context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers 100% of parameters with descriptions, so baseline is 3. The description does not add any additional meaning beyond what the schema already provides (id, name, language).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 ('a VAST 4.2 closed caption file'), which distinguishes it from sibling tools like create, delete, get, and list. The resource is specific and the verb is explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives (e.g., create, delete, get). There is no mention of prerequisites, typical use cases, or how this update tool compares to the create or delete counterparts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only states 'Update' without explaining whether it performs a partial patch or full replacement, what fields are affected, or what the response contains. No side effects, auth requirements, or idempotency are mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no redundant words, making it highly concise. However, it is arguably too sparse to provide meaningful guidance, but for pure conciseness it earns a 4 rather than a 5 because it lacks critical context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters and no output schema or annotations, the description is incomplete. It does not clarify whether the update is partial or complete, what happens if required fields are omitted, or what the return format is. Sibling CRUD tools exist, but without additional context, the description is insufficient for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% as every parameter has a clear description. The description adds no extra parameter-level context beyond the schema, which already defines id, name, bitrate, duration, and mime_type. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Update' and the specific resource 'VAST 4.2 linear media', distinguishing it from create/delete siblings. The version qualifier differentiates it from the similar 'vast_update_linear_media' tool. No ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 vast42_create_linear or vast42_delete_linear. It does not mention that an existing ID is required or that this is for modifying an existing entity, leaving usage entirely implied by the 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?
There are no annotations, and the description only says 'Update' without disclosing behavioral details such as whether unspecified fields are reset, required permissions, idempotency, or side effects. The agent is left without important safety or 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, making it very concise. However, the brevity comes at the cost of missing behavioral and usage context, so it is not perfect.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters, a nested object, no output schema, and no annotations, the tool requires more descriptive context to be fully understood. The minimal description leaves significant gaps about how updates behave and what the response will be.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all 7 parameters with descriptions (100% coverage), so the description does not need to add param details. However, it also adds no extra value beyond the schema, keeping it at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and the specific resource ('VAST 4.2 placement'), which distinguishes it from sibling create/delete tools for the same resource. It is direct and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 update_placement or vast_update_placement, nor any mention of prerequisites, typical scenarios, or contexts 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?
There are no annotations, so the description bears the full burden of disclosing behavioral traits. It merely states the action without noting permanence, side effects, or any prerequisites. Deleting a companion is likely irreversible, but this is not mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words. It is front-loaded with the verb 'Delete' and directly states the resource. This is an ideal length for such a simple operation, scoring high on conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter delete tool, the description is nearly sufficient, but it omits the crucial distinction from 'vast42_delete_companion'. It also does not explain what a 'VAST companion' is in this context. With no annotations or output schema, this lack of contextual detail leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with a single 'id' parameter described as 'VAST companion ID'. The description adds no extra meaning beyond implying the companion is identified by ID. With high schema coverage, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Delete a VAST companion.' This clearly conveys the core action and entity. However, it does not distinguish itself from the similarly named sibling tool 'vast42_delete_companion', which also deletes a companion, so it misses the differentiator.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. Notably, the sibling list contains 'vast42_delete_companion', and the description does not explain the difference (e.g., VAST vs VAST42). An agent could easily choose the wrong delete-companion tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Get details' which implies a read operation, but it does not disclose whether it is strictly read-only, requires specific permissions, how errors are handled (e.g., missing ID), or what the response structure includes. This is minimal coverage for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence of 8 words, front-loaded with the action 'Get details'. Every word earns its place, with no redundancy or filler. This is excellent conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID tool with one parameter and no output schema, the description is minimally viable. However, given the large sibling set with related tools like vast_list_schedules and get_schedule, the description lacks context about when to select this tool and what 'details' entails (full object vs. summary). It does not explain return values, but output schema absence relaxes that requirement. Overall, it is adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'id', with the description 'VAST schedule ID'. The tool description adds no extra meaning beyond the schema; it merely repeats the concept of a specific VAST schedule. Baseline is 3 because the schema already documents the parameter adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('details of a specific VAST schedule'), using a specific verb and resource. It distinguishes from list operations by emphasizing 'specific' schedule, but does not explicitly differentiate from sibling 'get_schedule' or mention when to use this variant.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 is no mention of exclusions, prerequisites, or context such as 'use this for a single VAST schedule by ID' vs. using vast_list_schedules for multiple schedules. The agent is left without 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, and the description only states the basic operation. It does not disclose pagination behavior, read-only nature, or any other contextual nuances beyond what the schema already provides, leaving the full burden on the description which fails to add 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary words. It efficiently states the action and target, earning every word it uses without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with fully documented parameters, the description is minimally viable. It lacks usage context and return expectations, but the schema and tool name cover the essentials, making it adequate though not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes both parameters ('limit' with default and max, 'offset' as pagination offset), so description coverage is 100%. The description adds no parameter-specific semantics, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all archived VAST campaigns' with a specific verb and resource. However, it doesn't differentiate from the sibling tool 'list_archived_campaigns' which has an identical function without the VAST prefix, leaving ambiguity about when to use which.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 like vast_get_archived_campaign or list_archived_campaigns. The description gives only the action and target, providing no context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden. It only states 'List all', but does not disclose that results are paginated via limit/offset, that 'all' requires iterating with offset, or what constitutes a tracking entry. This lack of behavioral detail could mislead an agent into assuming a single response contains every entry.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant verbiage. However, it is under-specified in terms of content, though this is more a completeness issue than a conciseness flaw.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description is too terse. It fails to mention that 'all' is subject to pagination, that offset can be used to retrieve subsequent pages, or what fields are returned in each tracking entry. This is a significant gap for an API that may return large datasets.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for both limit and offset with 100% coverage, so the baseline is 3. The description adds no extra meaning beyond confirming the pagination parameters exist; it does not explain their relationship to the 'all' scope.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 ('all VAST tracking entries'), which unambiguously differentiates it from sibling tools like vast_get_tracking (fetch one) and vast_create_tracking. The scope 'all' is explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided for when to use this tool versus alternatives. While the name suggests listing, there is no mention of pagination behavior or contrast with vast_get_tracking for individual lookups. The description does not state any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 says 'Update', which is a write operation, but doesn't state whether it's a partial or full update, any permission requirements, reversibility, effects on related entities, or what the response will look like. 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is well-structured and front-loaded with the verb and resource. It doesn't waste words, though it could be slightly more informative while still remaining concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 5 parameters, no output schema, and no annotations, the description is skeletal. It fails to explain update semantics (partial/full), return values, prerequisites, or error scenarios, leaving the agent without enough context to invoke it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions cover all parameters (100% coverage) with clear definitions for id, name, width, height, and mime_type. The description itself adds no parameter-specific semantics, so the baseline of 3 is appropriate because the schema already does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does 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 (VAST non-linear media), which distinguishes it from sibling tools like create, get, or delete. However, it doesn't provide any additional context about what 'non-linear media' means or what the update entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The word 'existing' implies this tool is for updating records that already exist, which gives a hint about when to use it. However, there is no explicit guidance on when to use this versus alternatives like vast_create_non_linear_media or vast_get_non_linear_media, and no exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It merely states the operation and does not mention side effects, duplicate handling, whether values are appended or replaced, validation, or error conditions. Minimal behavioral disclosure beyond the action itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the key action. No unnecessary words or filler. It earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is too sparse. It does not explain the relationship between user_db_id and user_id, expected behavior on duplicates, or what a successful addition returns. The agent lacks sufficient context to use the tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage for all 4 parameters, so the baseline is 3. The description adds no additional parameter semantics; it only repeats that values are added. The schema already documents each parameter adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Add values to a list attribute for a user', with a specific verb ('Add') and resource ('list attribute for a user'). It differentiates from the sibling 'remove_user_list_attribute_values' and other user attribute tools by specifying the list-attribute mutation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not specify when to use this tool versus alternatives, any prerequisites (e.g., attribute must already exist), or context for choosing it over create/update user attribute tools. Usage is only implied by the verb and noun.
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 adds no behavioral context beyond the action itself. It does not disclose effects like whether an advertiser ID is returned, whether duplicate names are prevented, or any permission requirements, leaving the agent without critical operational detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundancy. Every word contributes to stating the core action, 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.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite a fully described schema, there is no output schema and the description fails to state what the tool returns (e.g., created advertiser object or ID). It also omits any side effects, error conditions, or validation behavior, leaving a significant completeness gap for a create operation with six parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all six parameters including details like password constraints and metadata structure. The description itself adds no parameter-level meaning, but baseline 3 is appropriate when the schema carries the full semantic load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new advertiser' uses a specific verb and resource, clearly indicating it creates an advertiser. It differentiates well from sibling tools like update_advertiser, delete_advertiser, and get_advertiser by naming the create 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: use this when you need to create a new advertiser. However, there is no explicit guidance on when not to use it, no mention of prerequisites, and no alternatives are named, so it lacks the explicit clarity expected for a higher score.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 of behavioral disclosure, but it only restates the primary create action. It does not mention side effects, return behavior, permissions, or whether the campaign is created as active or draft.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately states the action and resource. There is no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite a 9-parameter schema with nested objects and no output schema, the description is only a bare one-liner. It does not explain the 'standard' distinction, setup requirements, or expected response, leaving significant context gaps for a create operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 9 parameters are well-documented in the schema. The description adds no parameter-specific details, but the baseline of 3 applies because the schema handles the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new standard campaign' uses a specific verb and resource, clearly indicating the action. The word 'standard' helps distinguish this tool from sibling tools like draft_create_campaign and vast_create_campaign.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 draft_create_campaign or vast_create_campaign. There is no mention of prerequisites, typical use cases, 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 present, the description must fully disclose behavioral traits, but it merely states the action without explaining consequences, required initial state, or side effects. It does not mention that the document is created empty, whether existing documents are affected, or any permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler or redundant content. It is appropriately sized for a simple create 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is insufficiently complete. It does not clarify what a 'document' is, note that attributes are optional, or indicate what is returned after creation. The sparse description leaves key aspects unaddressed for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters (attributes, contract_id) already described. The description adds no extra parameter context or meaning beyond what the schema provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description provides a clear action ('Create') and resource ('document for a contract'), effectively distinguishing from siblings like update_contract_document and delete_contract_document. It also implicitly contrasts with create_contract_document_from_template by omitting template 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool vs alternatives such as create_contract_document_from_template or replace_contract_document_file. There are no usage contexts, prerequisites, or exclusions 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 must disclose behavioral traits. It mentions multipart file upload, which is useful, but it fails to specify required permissions, response format, or the meaning of 'file attributes', leaving ambiguity. The mention of 'file attributes' also appears inconsistent with the schema parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the purpose. Somewhat concise, but the second sentence includes vague terminology ('file attributes') that reduces clarity; still appropriately short.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create operation with no output schema and no annotations, the description does not explain success/error outcomes or the multipart upload specifics. The schema omits the file attribute despite the description mentioning it, 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/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3, but the description adds little value beyond the schema. It refers to the 'group' parameter as media group ID (already in schema) and introduces 'file attributes' that are not in the schema, which confuses rather than clarifies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Create a new image creative' with a specific verb and resource. Differentiates from sibling tools like update_creative and delete_creative, and from create_video_creative/create_rich_media_creative by specifying 'image'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for creating image creatives but does not explicitly state when to use this tool vs alternatives. No exclusions or prerequisites mentioned; the multipart upload hint is technical, not 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 only says 'Create a new data list' without indicating whether a duplicate label is allowed, what happens on success (e.g., returned object), or any permission requirements. This is minimal and leaves the agent guessing about side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words. It is front-loaded with the key action and resource, making it efficient and easy to parse. This is an example of appropriate minimalism.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even though the tool is simple with one parameter, the description lacks context about the expected return value or post-creation behavior. There is no output schema and no mention of what the response will contain, which is important for an agent to verify success. This leaves the tool incomplete for knowledgeable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% since the sole parameter 'label' has a description ('Data list label/name'). The tool description adds no additional parameter details, but the schema already provides sufficient semantics, aligning with the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new data list' uses a specific verb ('create') and a clear resource ('data list'), which clearly distinguishes it from sibling tools like list_data_lists, get_data_list, update_data_list, and delete_data_list. It is unambiguous about its function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. It does not mention that for bulk operations one should use bulk_upload_add_data_list, or that for modifications update_data_list is appropriate. The description only states the action without any contextual 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. However, it only restates the action without adding context about side effects, required permissions, idempotency, or what the tool returns. For a create operation, the description should at least mention the creation behavior and any important consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the verb and resource, and contains zero unnecessary words. However, it closely mirrors the tool name, offering little additional value, so it is concise but not maximally informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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 description is acceptable, but the description lacks any context about the tool's position in the CRUD workflow, return value, or prerequisites. No annotations and no output schema increase the need for description-provided context, but the schema and name cover the basic 'create' semantics, making it minimally viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (each of the 5 parameters has a description), so the baseline is 3. The description itself adds no parameter information, but since the schema already documents name, format, enabled, frequency, and connection_id, the schema carries the parameter semantics. No additional meaning is provided by the description, preserving the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new event log upload configuration' uses a specific verb ('create') and a specific resource ('event log upload configuration'), which clearly distinguishes this tool from sibling tools like list_event_log_upload_configs, get_event_log_upload_config, update_event_log_upload_config, and delete_event_log_upload_config. The action and target are 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as when to create a new configuration vs. updating an existing one. It does not mention prerequisites, such as needing an existing SFTP connection, or any exclusions. The agent is left without context for choosing this tool 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Create a new title asset' and provides no additional context about side effects, return value, or required preconditions. This is minimal and adds little beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words. It is front-loaded with the verb and resource, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create operation with no output schema, the description should explain what will be returned (e.g., the created asset) or any constraints. It also does not clarify that template_id must reference an existing ORTB native template. The description is too sparse to fully prepare an agent for invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, as both parameters (len and template_id) have descriptions in the input schema. The description adds no further parameter semantics, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and clearly identifies the resource ('a new title asset for an ORTB native template'). It distinguishes from siblings like create_ortb_native_image_asset and update_ortb_native_title_asset by stating exactly what is 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites (like needing an existing template) or situations where another operation (e.g., update) would be more appropriate. The description simply restates the action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It states the core action but does not mention required permissions, side effects, whether the creation is reversible, or what the response contains. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 15 words, front-loaded with the action. Every word contributes meaning, and the parenthetical clarification adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex tool with 18 parameters, nested objects, mutual exclusions (zone/channel), and no output schema. The description only provides a minimal definition and fails to mention mandatory prerequisites, the requirement for both advertisement and schedule, or what happens after creation. The schema documents parameter rules but the description does not contextualize the overall operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 18 parameters. The description adds only the high-level concept of a placement, which is not parameter-specific. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 'placement', and parenthetically defines what a placement does ('assign an ad item or campaign to a zone or channel'). This makes the tool's purpose unambiguous and distinct from read/update/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/5Does 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 vast_create_placement, draft_create_placement, or vast42_create_placement. The description only states what the tool does, not when it should be preferred or excluded.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 of behavioral disclosure. It only restates the function without explaining side effects, required parent resources, validation rules, or response behavior. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no fluff. It front-loads the purpose efficiently and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a 9-parameter create operation with no output schema or annotations. The description fails to mention the necessity of publisher_id and catalog_id, the return format, or the relationship to product catalogs. It is under-specified for an unannotated mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all nine parameters with descriptions (100% coverage), so the baseline is 3. The description adds no parameter-level detail, but the schema already handles the semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb (Create) and resource (item in a product catalog), clearly distinguishing it from sibling tools like create_product_catalog (which creates a catalog itself) and create_catalog_ad_item (which creates an ad item). The phrasing is unambiguous and matches the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 an existing product catalog), exclusions, or when to prefer related tools like create_catalog_ad_item or bulk_upload_product_catalog.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it offers none. It does not state whether credentials are validated, whether duplicate names are allowed, what authentication is required, or what side effects occur beyond creating the resource. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with the action verb first and no redundant phrasing. Every word earns its place, 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.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and zero required parameters, the description leaves the agent without context about the result of the operation (e.g., what is returned, whether the connection is usable immediately, or if there are constraints like unique names). It is under-specified for a tool that creates a resource and accepts multiple credentials.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all six parameters with clear descriptions (e.g., 'SFTP host', 'Connection name'), so schema_description_coverage is 100%. The tool description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new SFTP connection' uses a specific verb ('create') and clearly identifies the resource ('SFTP connection'). It distinguishes this tool from its siblings (list/get/update/delete/test_sftp_connection) by signaling a create operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites. It does not explicitly exclude other connection-related operations like test_sftp_connection or update_sftp_connection, leaving usage to be inferred solely from the verb 'create'.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 does not mention potential side effects (e.g., sending emails to recipients), required permissions, or whether the contract must be in a specific state. The description only restates what the name implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is appropriately sized for a tool with one parameter and a straightforward purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should explain return values and behavioral context but does neither. It lacks information about what the creation returns, what happens after creation, or any prerequisites beyond providing contract_id, making it incomplete for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for contract_id ('Contract ID'), so the schema already documents the parameter. The description adds no additional meaning beyond stating 'for a contract', which aligns with the parameter but doesn't enhance it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 'signature request', and specifies 'for a contract' which adds context. This distinguishes it from sibling tools like update_signature_request, list_signature_requests, and delete_signature_request.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 update_signature_request or cancel_signature_request. There is no mention of prerequisites or scenarios where this tool should be avoided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits on its own. It only states 'Delete a catalog zone' without clarifying whether the deletion is permanent, reversible, or has cascading effects on dependent entities. The lack of any safety warnings or side-effect information leaves the agent without important context for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at four words, with no filler. It is front-loaded with the action. However, it sacrifices important detail for brevity, so while structurally efficient, it does not earn a perfect score for usefulness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema), and the description covers the basic function. However, for a delete operation, the absence of behavioral notes (permanence, dependencies) and usage context makes it minimally adequate rather than complete. The sibling set includes related catalog zone operations, yet no cross-references or conditions are provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage by documenting the required 'id' parameter as 'Catalog zone ID'. The description adds no additional parameter-level meaning, but given the schema's clarity, this meets the baseline. No further elaboration is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Delete a catalog zone' uses a specific verb and resource, distinguishing it from sibling tools that operate on other entity types (e.g., emails zones, channels, placements). Even without additional context, an agent can identify this as the deletion operation for catalog zones.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 or any alternatives. It does not mention prerequisites, related operations (e.g., get_catalog_zone, update_catalog_zone), or conditions under which deletion is appropriate. This is purely a statement of action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Delete' without stating whether the action is irreversible, whether it cascades to related data, or what the response looks like. This is a notable gap 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no filler or redundant information. It is front-loaded with the 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.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature, the absence of annotations, and no output schema, the description is insufficient. It does not explain irreversible consequences, return behavior, or any safety considerations that would help an agent use this tool responsibly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for the single parameter 'id' with description 'Report configuration ID'. The description adds no additional parameter semantics beyond what the schema states, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a report configuration' clearly states the specific verb (delete) and the resource (report configuration), matching the tool name. It distinguishes from sibling tools like create_custom_report, update_custom_report, list_custom_reports, and get_custom_report by indicating the delete operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 update_custom_report for modifications or get_custom_report for retrieval. It does not mention any prerequisites, exclusions, or scenarios where deletion is appropriate or should be avoided.
Agents often have multiple tools that could apply. Explicit usage guidance like "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. The verb 'Delete' implies destructive action, but the description does not disclose whether the operation is irreversible, whether it cascades to associated entities, or if specific permissions are required. This lack of context is a significant gap, especially given the existence of an archive variant.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence ('Delete an email zone') that is perfectly front-loaded and contains zero redundant information. Every word is necessary, making it extremely concise without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive mutation with no annotations and no output schema, this description is under-specified. It does not explain the permanence of the deletion, how it relates to archiving, or any side effects (e.g., impacts on campaigns or billing). While the simple schema is clear, the lack of behavioral context leaves the agent with incomplete information to make a safe choice.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the single parameter 'id', described as 'Email zone ID'. The tool description adds no additional detail about the parameter beyond what the schema already provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete an email zone' uses a specific verb ('Delete') and a clear resource ('email zone'), distinguishing it from sibling tools like 'archive_email_zone' (which preserves the zone) and 'delete_zone' (for regular zones). This is a concise and unambiguous statement of the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as 'archive_email_zone' or 'delete_zone'. The description does not mention whether deletion is permanent, what prerequisites exist, or any consequences of deleting an email zone, leaving the agent without helpful 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 must disclose behavioral traits. It only states the delete action without mentioning permanence, soft-delete behavior, permissions, or side effects. This is insufficient for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single four-word sentence that is front-loaded and directly states the purpose. There is no unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a destructive delete with no annotations and no output schema. The description omits critical context such as irreversibility, required permissions, or impacts on related objects. This leaves an agent under-informed for a high-stakes operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage for the single 'id' parameter with 'Ad item ID'. The description adds no additional parameter context beyond what the schema already provides, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and the specific resource ('image ad item'). It distinguishes from sibling delete tools for other ad item types like delete_custom_html_ad_item and delete_native_ad_item.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Sibling tools such as draft_delete_image_ad_item and vast_delete_ad_item exist, but the description does not explain differences or provide selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full responsibility for disclosing behavioral traits. It only explains what a placement is, not whether the deletion is permanent, reversible, requires special permissions, or affects associated data. It adds minimal behavioral context beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It clearly states the action and resource in an extremely concise manner.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating delete operation with no annotations and no output schema, the description lacks critical context about side effects, reversibility, or usage constraints. It is adequate for identifying the operation but insufficient for confident invocation in a complex workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of the single parameter ('id' with description 'Placement ID'), so the description does not need to add parameter details. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Delete' with the resource 'placement' and adds a clarifying parenthetical ('remove an ad item from a zone'), making the tool's function unambiguous and differentiating it from delete operations on other entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the many sibling delete_placement variants (e.g., vast_delete_placement, draft_delete_placement), nor does it mention any prerequisites or context in which this specific deletion applies.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 of disclosure. It only states the action (delete) but does not mention whether deletion is permanent, cascading, restricted by dependencies, or requires specific permissions. This is a significant gap 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with zero wasted words. It is appropriately sized for a simple delete endpoint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema), but for a destructive action the description lacks critical context such as reversibility, side effects, or usage conditions. The minimal description leaves the agent without enough information to safely decide when and how to invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'id' is described in the schema as 'Creative ID', and the schema coverage is 100%. The description adds no additional meaning beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a rich media creative' uses a specific verb and resource, clearly distinguishing it from sibling tools like 'delete_creative' or 'delete_video_creative'. The entity type (rich media creative) 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description does not explain when to use this tool versus alternatives like 'delete_creative' or other delete-type siblings, nor does it state prerequisites or conditions for safe use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden of behavioral disclosure. It only says 'Delete a role,' which adds no insight beyond the tool name. It does not mention whether deletion is permanent, reversible, or has cascading effects on associated data, nor any permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with zero filler or redundancy. It is concise and front-loaded, stating the action immediately. However, it is extremely minimal and could be expanded with useful context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple deletion tool with one parameter and no output schema, the description is functionally adequate but lacks contextual details such as consequences of deletion, whether the role must be unused, or any irreversible effects. Given the adjacent 'archive' tools for other entities, some usage context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter 'id' described as 'Role ID.' The description does not add any additional semantic meaning beyond what the schema already provides. Baseline of 3 is appropriate since the schema fully documents the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a role' clearly states the action (delete) and the resource (role), distinguishing it from siblings like get_role, create_role, and update_role. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs. alternatives. It does not mention prerequisites, conditions under which deletion is allowed, or whether archiving is an alternative. The description simply states the action with no contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 present, the description carries full burden for disclosing behavioral traits. It only states the basic action without revealing side effects (e.g., whether the recipient is notified, if the request is invalidated when the last recipient is removed, or any state 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that directly states the operation. There is no wasted wording, and the most important information is front-loaded. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a delete operation, the description is underspecified. There is no mention of return values, effects on the parent signature request, conditions for deletion, or any irreversible consequences. Given no annotations or output schema, the description should provide more context to make the tool fully understandable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all three parameters ('Signature request ID', 'Contract ID', 'Recipient ID'), so schema coverage is 100%. The description adds no further parameter context, but since the schema already documents the identifiers, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and the two resources involved ('recipient', 'signature request'), making it distinct from sibling tools like delete_signature_request or update_signature_request_recipient. It uses a specific verb+resource pattern that leaves no ambiguity about the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool vs. alternatives, no prerequisites, and no exclusions. There is no mention of when deletion is appropriate (e.g., before the request is signed, not after) or how it differs from cancel_signature_request or update_signature_request_recipient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the fact that it deletes, with no mention of irreversibility, permission requirements, cascading effects, or what happens on success or failure. This is a significant gap for a destructive 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is clear and directly to the point. Every word earns its place, with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple CRUD delete but has no output schema and no annotations. The description provides only the basic action, omitting important context such as permanence, dependencies, or consequences. It is minimally viable but lacks the depth expected for a destructive operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% as both id and user_db_id have descriptions in the input schema. The description adds no additional parameter meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Delete' with a specific resource 'user attribute' and scope 'from a user database'. It distinguishes itself from sibling tools like create_user_attribute, update_user_attribute, and get_user_attribute by its destructive verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention that this permanently removes an attribute, nor does it reference related operations like create or update, leaving the agent to infer 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 does not explain side effects, whether a draft campaign must exist first, whether creation is reversible, or what happens to the draft after creation. The description simply restates the creation action without adding 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant words. It is front-loaded with the action and resource, and every word contributes to the meaning. This is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a nested object parameter, the description is too minimal. It lacks context about the draft workflow, prerequisites (e.g., the need for a campaign_draft_id), or what a successful creation returns. The schema covers parameter meanings, but broader context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are already fully documented in the schema. The description adds no additional parameter semantics beyond what the schema states, thus meeting the baseline for schema-covered tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a new') and the resource ('draft catalog ad item'), using a specific verb and noun combination. It distinguishes itself from siblings like 'create_catalog_ad_item' through the 'draft' qualifier, leaving no ambiguity about what it creates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 vs. alternatives such as 'create_catalog_ad_item' or 'campaign_bulk_create_catalog_ad_items'. The 'draft' prefix implies usage in a draft workflow, but this is not explicitly stated, and no alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description must carry the full burden of behavioral disclosure. It merely states the action without explaining what 'draft' means (e.g., the item is not live until saved), potential side effects, or whether the operation is reversible. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise, front-loaded sentence with zero wasted words. It efficiently communicates the core action and object, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotations, so the description should provide more context about what a 'draft' creation entails, what the tool returns (e.g., the created draft's ID), and how it fits into the broader draft/save workflow. The current description leaves these gaps unaddressed, making it incomplete for a tool with a nested object parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for both 'campaign_draft_id' and 'draft'. The tool description adds no additional parameter semantics beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new draft native ad item' uses a specific verb ('Create') and clearly identifies the resource ('draft native ad item'), making it distinct from siblings like 'draft_create_catalog_ad_item' or 'create_native_ad_item'. The word 'draft' immediately signals a specific workflow 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/5Does 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 the non-draft 'create_native_ad_item' or the sibling 'draft_update_native_ad_item'. It does not explain the draft workflow or any prerequisites like the existence of a campaign_draft_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 the full burden for behavioral disclosure, but it only restates the action without detailing consequences like irreversibility, draft-state requirements, or return behavior. This is a mutation with zero additional 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded phrase with no filler or redundant explanation. For a simple delete operation, this is an appropriately concise and efficient structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too sparse for a deletion tool without annotations or an output schema. It omits important context such as whether this only deletes the draft version (not a published one), what success/error looks like, and any prereqconditions like the item existing or being in draft state.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of the single parameter 'id' with an adequate description, so the baseline is 3. The tool description adds no extra meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Delete' and the resource 'draft rich media ad item', which is specific and distinguishes it from sibling delete tools for other item types. Even though it repeats the tool name, it is unambiguous 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as deleting a non-draft rich media ad item or other draft item types. No context is provided about draft versus published workflows 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 the full burden of behavioral disclosure. It simply restates the operation ('List all draft campaign assignments') without adding any details about pagination, return format, whether the operation is read-only, or what 'draft' means in this context. The description adds no value beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler or redundancy. It is front-loaded with the action verb and object, making it immediately understandable. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool is simple and the schema covers parameters, the description lacks important context. It does not explain what 'draft' signifies, what the response contains, or how it relates to sibling list operations. With no output schema and no annotations, the description alone is insufficient for an agent to fully understand the tool's behavior and edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters (limit and offset) with descriptive text, so the schema handles parameter semantics. The description itself adds no information about parameters, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all draft campaign assignments' uses a specific verb ('List') and identifies a clear resource ('draft campaign assignments'). It distinguishes from sibling tools like 'list_campaign_assignments' and 'vast_list_campaign_assignments' by explicitly noting the 'draft' subset, and from draft_get/update/delete variants by indicating a list operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 'vast_list_campaign_assignments' or 'list_campaign_assignments'. The description does not explain the difference between 'draft' and non-draft assignments, nor does it mention 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'List all draft schedules' but does not mention pagination behavior, although the schema includes limit/offset with a max limit of 100, so 'all' is potentially misleading. There is no mention of ordering, read-only nature, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that communicates the primary action and target resource. It is front-loaded with the verb and avoids unnecessary detail, making it efficient for a simple list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is low in complexity (2 optional parameters, no output schema), so the description is minimally adequate. However, it does not explain what distinguishes a 'draft schedule' from a regular schedule, nor does it mention the return format or any caveats about the 'all' claim despite the limit parameter. Given the extensive sibling toolset, more context would help distinguish usage cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both 'limit' and 'offset' parameters are already well documented in the schema. The description adds minimal semantic value beyond the word 'all', which may slightly conflict with the default/max limit of 100, but it does not provide additional parameter-level context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a specific resource ('draft schedules'), clearly distinguishing this from sibling tools like 'list_schedules' and 'vast_list_schedules' which operate on non-draft or VAST-specific schedules. The 'draft' modifier provides unambiguous 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/5Does 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 'list_schedules' or 'vast_list_schedules'. There is no mention of context, prerequisites, or why one would choose draft schedules over the live versions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. 'Update' implies mutation, but the description does not state whether changes are draft-only, require specific preconditions, are reversible, or what the response contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that is immediately understandable and contains no filler. It is appropriately concise for the simple action it names.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, no output schema, and a nested draft object that is unspecified, the one-line description is not enough. It does not explain draft workflow implications, return values, or valid fields for the draft object.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The tool description adds no meaning beyond the schema, and the 'draft' parameter is an opaque object with no field details, but the description does not worsen this.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an existing draft image ad item' uses a specific verb and resource, and clearly distinguishes this tool from create/delete operations and from non-draft image ad item tools by including 'draft'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 draft_create_image_ad_item, draft_delete_image_ad_item, or the non-draft update_image_ad_item. There is no mention of the draft workflow or when changes are committed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only states the action 'update' without revealing consequences such as overwrite semantics, required permissions, reversibility, or return value. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence ('Update an existing draft schedule') with zero wasted words. It is appropriately sized for the tool's simplicity and achieves maximum conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal and only restates the tool's name without adding context. No output schema or annotations exist, so it should explain draft schedule specifics, side effects, or return behavior. It fails to provide this, especially when compared to sibling tools that differentiate draft vs. live workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: both 'id' and 'draft' have descriptions. The description adds no additional parameter semantics beyond what the schema provides. Baseline of 3 is appropriate since the schema effectively documents the parameters, though the nested 'draft' object's structure is left open-ended.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does 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 draft schedule), distinguishing it from creation and deletion tools. However, it doesn't explicitly differentiate from sibling tools like update_schedule or vast_update_schedule, relying on the 'draft' prefix in the name and description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for draft schedules through the word 'draft', but provides no explicit guidance on when to use this tool versus live schedule update tools, nor does it mention any prerequisites or exclusions. The context is implied by the naming convention, 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. The word 'Get' implies a read operation, but the description adds no behavioral context such as return format, error behavior, or required permissions. It merely restates the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is appropriately concise for a simple get-by-id tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the description omits important contextual details such as what 'details' are returned and how it differs from the draft variant (draft_get_catalog_ad_item). With no output schema and no annotations, the description should clarify these aspects but does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: the 'id' parameter is already described as 'Ad item ID'. The description does not add any further semantic detail beyond what the schema provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Get'), resource ('catalog ad item'), and scope ('specific'), distinguishing it from list/create/update/delete siblings. It unambiguously identifies a single-item retrieval operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like list_catalog_ad_items or draft_get_catalog_ad_item. No explicit exclusions or alternative references 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?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only says 'Get details' and does not mention response format, error behavior, auth requirements, or whether archived contracts are excluded. This is minimal disclosure for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It communicates the tool's purpose in the fewest possible words, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter get-by-id tool, the description plus schema is largely complete: the agent knows the resource, the required parameter, and the operation. However, the absence of an output schema and annotations means the description could add a bit more context about return value or archived-contract distinction, though these are not critical for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents the single 'id' parameter with 100% coverage, and the description adds no additional semantic meaning beyond the schema. The baseline of 3 applies because the schema carries the full parameter documentation burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Get') and resource ('details of a specific contract'), which distinguishes it from list_contracts and many other contract-related tools. However, it does not explicitly differentiate from sibling get_archived_contract or related document/payment getters, so it stops short of 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as list_contracts or get_archived_contract. The description implies a direct retrieval use case but provides no context, exclusions, or alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action without mentioning that this is a read operation, what the returned tag looks like, or whether any special permissions are needed. The 'Get' verb implies read-only, but this is not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear, front-loaded sentence with no wasted words. It is appropriately concise for a simple getter, though it could earn a 5 if it included additional useful context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter getter, the description is minimally adequate. However, without annotations, output schema, or usage guidance, it leaves gaps about the return value format and when to use it among many similar sibling tools. It is complete enough for a straightforward GET, but not richly informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a clear 'Ad item ID' description for the one parameter. The tool description adds no additional parameter meaning beyond what the schema already supplies, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and names the exact resource ('conversion tracking tag') scoped to 'image ad item'. This clearly distinguishes it from sibling tools like get_custom_html_ad_item_conversion_tag or get_native_ad_item_conversion_tag by identifying the ad item 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/5Does 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 simply states the action without any context about when to prefer this over other conversion tag getters, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 for behavioral disclosure. It only states 'Get details,' which implies a read operation, but does not explicitly mention the absence of side effects, authorization requirements, error behavior, or what 'details' entails. It adds no context beyond the tool name and 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no redundancy or fluff. Every word contributes to stating the tool's purpose, making it appropriately concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only one parameter and no output schema, so the description should clarify what 'details' means or what the response contains. It does not. There is no mention of return format, availability of fields, or how to locate the ID, leaving the agent without sufficient context for a complete invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents the single 'id' parameter with description 'List target ID' (100% coverage). The description does not add any additional meaning to the parameter, so the schema coverage baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Get details') and the resource ('list target'), and the word 'specific' distinguishes it from listing all list targets. It maps directly to sibling tools like list_list_targets and create/update/delete, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as list_list_targets for browsing or create_list_target for new targets. It does not mention prerequisites, related tools, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full behavioral disclosure burden. It implies a read-only operation via 'get', but discloses no additional traits such as response format, authentication needs, or behavior when the report is not yet generated. For a simple getter, this is minimally adequate but lacking depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence without extraneous information. It is front-loaded with the action and resource, making it easy to parse, though it could be slightly more informative without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with only two simple parameters and no output schema, the description is minimally viable. However, it does not explain the relationship between `report_config_id` and `generated_id` or when to use this over sibling report tools, leaving some contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes both parameters with 100% coverage ('Generated report ID' and 'Report configuration ID'). The description adds no additional semantic meaning beyond the schema, matching the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb+resource: 'Get a specific generated report'. This distinguishes it from related list operations, though it doesn't explicitly mention how it differs from `get_report_schedule_generated` or `list_report_generated`.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like `list_report_generated` or `get_report_schedule_generated`. There are no exclusions or context cues beyond the basic verb.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the tool retrieves tags, without explaining any side effects, authentication needs, rate limits, or return characteristics. This 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero wasted words. It is optimally concise for the simplicity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, yet the description does not explain what a 'serving tag' is, the response format (e.g., XML), or how it differs from other zone tag endpoints. This is insufficient for an agent to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the single parameter 'id' as 'VAST zone ID' with 100% coverage. The description adds no extra meaning beyond repeating the resource type. Baseline 3 is appropriate because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('VAST zone serving tags'). It is specific enough to distinguish from sibling tools like get_zone_tag (non-VAST) and get_vast_zone_conversion_tag (conversion-specific).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, use cases, or exclusions, leaving the agent to infer context 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 must carry the full behavioral disclosure burden. It only says 'Get', which implies read-only, but it does not disclose output format, potential errors, or side effects. This is insufficient for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly worded sentence with no filler. It is immediately understandable and front-loaded, earning full marks for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter get tool, the description is adequate but not complete. It does not clarify the return value (e.g., HTML/JS string) and does not address the close relationship with sibling conversion tag tools. With no output schema or annotations, more context is needed for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the parameter 'id' with a 'Zone ID' description, but the tool description adds the qualifier 'standard zone', which helps the agent understand it is not an email or vast zone. This is meaningful value beyond the schema, justifying a score above the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' and names the resource 'conversion tracking tag for a standard zone', which clearly distinguishes it from email/vast zone variants. However, it does not explicitly name sibling tools, so it falls just short of the highest clarity benchmark.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 get_email_zone_conversion_tag or get_vast_zone_conversion_tag. It only states what the tool does, leaving the agent to infer selection criteria 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 does not disclose pagination behaviors (limit/offset), sorting, or what 'archived' entails. It only states the action without additional 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately conveys the tool's purpose with no wasted words. It is well-front-loaded and efficiently sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description is minimal but lacks adequate context. It does not mention that the tool returns only archived contracts, how pagination works, or what fields are returned. With no output schema and no annotations, the description leaves important details unspecified, especially given the proximity of similar sibling tools like 'list_contracts'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes both parameters ('limit' and 'offset') with 100% coverage, so the baseline is 3. The description's phrase 'List all' implies pagination but adds no detail about parameter formats or defaults beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all archived contracts' clearly uses the verb 'list' and specifies the resource as 'archived contracts', distinguishing it from sibling tools like 'list_contracts' and 'get_archived_contract'. It unambiguously indicates the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that 'list_contracts' might be used for non-archived contracts, nor does it explain any filters or preferred use cases. Context signals show sibling tools but the description gives no exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It fails to mention pagination behavior despite the presence of limit and offset parameters, does not clarify whether 'all' implies multiple pages, and does not describe the return structure or any side effects. This leaves the agent uncertain about how results are delivered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant phrases or filler. It directly communicates the purpose without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema and no annotations, this minimal description is insufficient. It does not explain the response format, pagination implications, or how to interpret 'all' in light of the limit/offset parameters. For a list operation, more context about pagination and result structure is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all three parameters, so the schema already documents the meaning of user_db_id, limit, and offset. The description adds marginal context by indicating the list is scoped to a user database via user_db_id, but does not provide any additional semantics for limit/offset beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all audiences in a user database' clearly states the action (list), the resource (audiences), and the scope (all, within a user database). This distinguishes it from sibling tools like get_audience which retrieves a single audience.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_audience, nor are there any notes on prerequisites or exclusion criteria. The description simply states what the tool does without any contextual 'use this when' 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. 'List all channels' implies a read-only operation but does not mention pagination behavior, whether archived channels are included, or any response format 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with no filler. It is front-loaded and 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.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The simple description is not fully complete given the context. The word 'all' may conflict with the pagination parameters (limit/offset), and the absence of an output schema and annotations leaves the agent without return format or scope details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for both parameters (limit and offset) with 100% coverage. The description adds no additional parameter information, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all channels' uses a specific verb and resource, clearly stating the tool's action. It distinguishes from sibling tools like vast_list_channels (which is VAST-specific) and get_channel (single channel).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 vast_list_channels or list_all_zones. There is no mention of context, exclusions, or preferred scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosure. It only restates the tool's function without revealing pagination behavior, return format, read-only nature, or any constraints. The description adds no behavioral information beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. It is front-loaded with the verb and resource, making it instantly scannable and 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.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is incomplete for a tool with no output schema and no annotations. It does not mention pagination (despite limit/offset parameters), sorting, or what constitutes a 'document'. The statement 'List all' is also ambiguous given the presence of pagination parameters. More context is needed for an agent to understand the full behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all three parameters (limit, offset, contract_id), so the schema already explains each parameter. The tool description does not add any additional meaning beyond what the schema provides, warranting the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'List all documents for a contract' which clearly identifies the action (list) and resource (documents for a contract). This is specific enough to distinguish it from sibling tools like get_contract_document or create_contract_document.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_contract_document or list_contracts. The usage is only implied by the naming convention, but there is no explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only states 'List all payments' without explaining pagination. The schema includes limit and offset, creating ambiguity about whether 'all' means a single page or requires multiple requests. No info on response format or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single seven-word sentence that is front-loaded and contains no filler. It efficiently communicates the core action and target resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without annotations or an output schema, the description is too minimal. It omits pagination semantics, return type, and the potential mismatch between 'all' and limit/offset, leaving significant gaps for an agent to safely invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% description coverage for contract_id, limit, and offset. The tool description adds no additional semantic meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and identifies the resource as 'all payments for a contract', clearly indicating it returns multiple payments. This distinguishes it from siblings like get_contract_payment (single payment) and list_contracts (contracts).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_contract_payment or list_contracts. There is no mention of prerequisites, filtering criteria, 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 bears full responsibility for disclosing behavioral traits. It only states that it lists email zones, omitting details about pagination, default limits, return format, or whether archived zones are included. This is minimal and leaves significant ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant words. It is front-loaded and immediately 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.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, and the description does not mention what is returned or any filtering semantics. Given the presence of sibling tools like list_archived_email_zones, it is unclear whether 'all' includes archived zones. The description is not sufficiently complete for an agent to understand the full behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for both parameters (limit with default/max, offset for pagination), achieving 100% coverage. The description adds no additional meaning or context for the parameters, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all email zones' uses a specific verb and resource, clearly indicating that this tool retrieves email zones as opposed to other zone types. This distinguishes it from sibling tools like list_zones and vast_list_zones by the 'email' qualifier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as list_zones, list_all_zones, or list_archived_email_zones. The description is a bare statement without any context about specific use cases 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 the full burden. 'List all' conveys a read-only operation and implies a collection return, but it does not disclose behavior like pagination limits, ordering, or that 'all' may require multiple pages. This is adequate for a simple list tool but leaves some behavioral traits unstated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence with no irrelevant text, effectively communicating the core action. While it is terse, it is concise and not unnecessarily verbose, earning a high but not perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description is mostly sufficient, but it lacks information about the return format (no output schema) and does not mention that pagination parameters affect 'all'. For a list operation with siblings, a bit more context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for both parameters (limit and offset), with clear descriptions in the schema. The tool description adds no additional meaning beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all event log upload logs' clearly states the verb (list), the resource (event log upload logs), and the scope ('all'). It is distinct from the sibling 'get_event_log_upload_log' (singular) and 'list_event_log_upload_configs' (a different resource), though it does not 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as get_event_log_upload_log for a single log or list_event_log_upload_configs for configurations. The description provides no context about typical use cases 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, the description carries the full burden of behavioral disclosure. It implies a read-only operation via 'List', but it does not explicitly confirm safety, does not explain pagination behavior despite limit/offset parameters, and does not mention any constraints or return characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that states the tool's purpose directly with no filler. It is appropriately sized for the simplicity of the operation and front-loads the key action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without annotations or an output schema, the description leaves the agent without information about the return format, pagination behavior, or how data assets differ from closely related asset types. This is a significant gap for a list tool, especially given the existence of similar list tools for images and titles.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% description coverage for all parameters, including 'template_id', 'limit', and 'offset'. The description adds no additional semantic meaning beyond the schema; it merely restates the template context already present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and names the resource 'data assets' scoped to 'ORTB native template'. This clearly distinguishes it from sibling tools like list_ortb_native_image_assets and list_ortb_native_title_assets, which handle different asset 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_ortb_native_data_asset for retrieving a single asset or list_ortb_native_image_assets for image assets. The description only states what the tool does, not when to select 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 exist, so the description must carry the full burden. It only states the action and says 'all', but does not mention pagination, response format, sorting, or read-only nature. This is insufficient for behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One short, front-loaded sentence with no filler, earning high conciseness. Every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema or annotations, the description should explain what a returned result looks like or note pagination behavior. It does neither, leaving the agent with only the schema parameter descriptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage with clear definitions for limit (default 100, max 100) and offset. The description adds no parameter semantics, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with the resource 'postal code targets', making the operation clear and distinguishing it from the get/create/update/delete siblings for the same resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 instead of get_postal_code_target, list_geo_targets, or other target-list tools. The name implies listing, but no explicit alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the action and scope, but does not disclose pagination behavior (e.g., whether 'all' means all pages or just the first page), ordering, or that this is a read-only operation. The phrase 'List all' may mislead given limit/offset parameters exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is directly to the point, front-loaded with the action and resource. It contains no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description is too minimal to be complete. It does not mention return value structure, pagination behavior, or clarify the potential conflict between 'list all' and the limit/offset parameters. A more detailed description is needed for an agent to invoke this tool correctly in varied contexts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for publisher_id, limit, and offset (100% coverage), so the schema carries the parameter documentation. The description adds no additional semantics beyond what the schema states, such as the default limit or pagination usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all product catalogs for a publisher' clearly specifies the action (list), the resource (product catalogs), and the scope (for a publisher). This distinguishes it from siblings like get_product_catalog (single) and search_product_catalog_items (search/filter).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as search_product_catalog_items or get_product_catalog. It does not mention scenarios where one should prefer this tool or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are not provided, so the description must fully disclose behavior. It only states the action without mentioning pagination behavior, default limits, whether the operation is read-only, or what response structure to expect. This is a minimal description that adds no behavioral context beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero wasted words. It directly communicates the core purpose, making it highly concise and well-structured for a simple list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, no output schema, and 2 parameters, the description is too sparse to be complete. It does not explain pagination semantics, whether this includes draft or archived items, or how it relates to draft_list_rich_media_ad_items. The richness of the surrounding tool ecosystem (many list variants) requires more disambiguation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides complete descriptions for both parameters (limit and offset), so the description does not need to repeat them. However, it also does not add any extra context such as default pagination behavior or how offset interacts with the list. Schema coverage is high, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all rich media ad items, using a specific verb and resource. The 'rich media' qualifier differentiates it from sibling tools like list_image_ad_items, list_custom_html_ad_items, and list_native_ad_items, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, there is a draft_list_rich_media_ad_items sibling tool, and this description does not clarify whether this tool lists only published items or how it differs from other list ad item tools. The usage context is entirely implied by the 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 the full burden of behavioral disclosure. It only states that it lists ads, but fails to mention pagination behavior (despite limit/offset parameters), ordering, or the structure of the returned data. The word 'all' is ambiguous given the default limit of 100, creating a subtle inconsistency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It immediately conveys the action and resource. This is an ideal length for a simple list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too sparse for a tool with pagination parameters and no output schema. It does not explain what 'all' means in the context of limit, what the response format is, or whether there are any ordering guarantees. Given the lack of annotations and output schema, the description should provide more behavioral context but does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions for limit, offset, and zone_id already provide clear semantics (e.g., 'Max results to return (default 100, max 100)'). Since schema coverage is 100%, the baseline is 3. The tool description adds only the qualifier 'standard zone,' which is a minor enhancement over the schema's 'Standard zone ID.' No significant new parameter meaning is added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and identifies the exact resource ('ORTB native ads') and scope ('for a standard zone'). This clearly distinguishes it from siblings like get_zone_ortb_native_ad (singular) and list_ortb_native_image_assets (assets, not ads).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives. There is no mention of alternatives, prerequisites, or scenarios where another listing tool (e.g., list_zones or list_ortb_native_templates) would be more appropriate. The description merely states what it does, leaving usage entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 disclosing behavioral traits. It says 'Resend' but does not explain the side effects, such as sending another email to recipients, whether it requires an active request, or if it is idempotent. This is a mutation tool with zero 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—one short sentence with no redundant words. It front-loads the action and resource, and every word earns its place. There is no verbose filler or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two parameters, no annotations, and no output schema, the description is minimally viable but incomplete. It explains the core action but omits crucial context such as what happens when resending (e.g., new notification sent), any state restrictions, or what the response contains. This falls short for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for both parameters (request_id and contract_id), achieving 100% coverage. The tool description adds no additional parameter meaning, so the baseline score of 3 applies. The agent can rely on the schema for parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Resend a signature request' uses a specific verb and resource, clearly identifying the tool's function. It distinguishes itself from sibling tools like create_signature_request, cancel_signature_request, and list_signature_requests by indicating a unique 'resend' 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/5Does 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., an existing signature request), exclusions, or scenarios where resending is appropriate. Sibling tools exist for other actions, but no comparative 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?
With no annotations, the description carries the full burden, but it only states the action without revealing side effects, reversibility, permission requirements, or impact on future access. As a mutating operation, more behavioral context is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no wasted words. It clearly conveys the action and object in an efficient manner.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a mutating operation with no annotations and no output schema, yet the description only provides a bare statement. It lacks explanation of what 'historical access' entails, what happens to the schedule, or what the response will be, making it incomplete for a complex API.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with both parameters documented as 'Schedule ID' and 'Report configuration ID'. The description adds no additional parameter meaning, so the baseline of 3 applies since the schema already covers the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'revoke' with a clear resource 'historical access for a report schedule'. It clearly distinguishes from sibling tools like delete_report_schedule by focusing on revoking access rather than deleting the schedule 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives or prerequisites. The description does not mention when revoking historical access is appropriate or what conditions must be met.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states 'update an existing', implying mutation and existence, but does not disclose partial vs. full update, return value, permissions, or constraints. This is minimal and insufficient for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary words. It is appropriately sized for a simple update operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the large number of sibling tools, the description lacks sufficient context to distinguish it from other update/replace operations and does not explain the scope of updates. It is too terse for a complete picture, especially since annotations are absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all three parameters. The tool description adds no extra meaning beyond what the schema provides, so it meets the baseline but does not enhance understanding of how parameters interact with the update behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an existing audio creative' clearly states the action (update) and the resource (audio creative), distinguishing it from create, delete, and get operations. It is specific and not a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. It does not mention that this is for updating metadata, nor does it contrast with replace_audio_creative_file or other update-like tools. The usage context is entirely 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 of behavioral disclosure. It only states the action without explaining whether it performs a partial or full update, what happens to omitted fields, or any side effects. For a mutation 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant words. It is appropriately sized for the simple action it describes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters including a nested object and no output schema, the description is insufficient. It does not explain return values, update behavior (partial vs full), or error conditions. The tool needs more context to be used correctly by an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameters are already well-documented with descriptions. The tool description adds no extra parameter semantics beyond confirming the update operation, which is acceptable given the schema handles the details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does 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 ('day parting rule'), distinguishing it from sibling tools like create_day_parting, delete_day_parting, and list_day_partings. It could be more specific about what fields are updatable, but the schema covers that.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The word 'existing' implies this is for modifying already-created day parting rules, which is a basic usage hint. However, there is no explicit guidance on when to use this versus create_day_parting or how partial updates work. The implied usage is at a basic level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states 'Update an existing event log upload configuration' without detailing whether updates are partial or full, what side effects occur, or whether any permissions are required. This is minimal 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that is front-loaded and contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should explain what the tool returns or any side effects, but it does not. The single sentence leaves significant gaps about update semantics, error conditions, and return values, making it incomplete for such an operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes all six parameters with clear descriptions, so the description doesn't need to add parameter information. However, it also doesn't add any context about how the update behaves with respect to which fields are updatable or how omitted parameters are handled, so it remains at baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Update') and identifies the exact resource ('event log upload configuration'), clearly distinguishing this from sibling tools like create_event_log_upload_config or delete_event_log_upload_config. It fully states the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as create_event_log_upload_config or get_event_log_upload_config. It simply states the action, leaving usage context entirely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 'Update an existing image asset,' implying the asset must exist, but does not reveal whether fields are partially updated or fully replaced, what validation occurs, what the response looks like, or error behavior. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero filler. It efficiently states the action and the resource, 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.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 7 parameters and no output schema or annotations, the description only provides a one-line summary. It does not mention required parameters, update behavior, return values, or any business context (e.g., that this is part of an ORTB native template CRUD flow). A mutation tool of this complexity needs richer description to be fully contextualized.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no parameter-level meaning beyond the schema's own terse field descriptions (e.g., 'Height', 'Width'), and does not clarify relationships like h/hmin or w/wmin. However, since all parameters have schema descriptions, the tool is minimally viable in this dimension.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Update') and resource ('existing image asset for an ORTB native template'), clearly distinguishing it from sibling tools like create_ortb_native_image_asset or update_ortb_native_title_asset. The operation is unambiguous and correctly scoped to existing assets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as create or delete image assets. It does not mention that template_id and id are required to target an existing asset, nor does it explain the update semantics (e.g., partial vs. full replacement).
Agents often have multiple tools that could apply. Explicit usage guidance like "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 is the sole source of behavioral info. It only says 'update', implying mutation, but does not disclose partial-vs-full update semantics, error behavior, required permissions, or whether the asset must already exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that directly conveys the operation, well-structured with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple update, but the description lacks usage context, behavioral details, and return value expectations. It does not mention what fields are updatable (only len is updateable per schema), nor does it address how template_id relates to id. Without annotations or output schema, this is insufficient for an agent to confidently invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all 3 parameters with descriptions (template_id, id, len), so the parameter semantics are fully available in structured form. The description adds no additional parameter context beyond reiterating the operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (update), the resource (title asset), and the context (ORTB native template), differentiating it from create/delete/get 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the create/delete/list variants, nor does it mention prerequisites or alternative approaches. It only states what it does.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It only states the operation without explaining whether missing fields are reset, what happens if the id does not exist, or any side effects. The verb 'update' already implies mutation, adding no behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler words. It efficiently conveys the core purpose without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the one-line description is insufficient. It fails to explain partial versus full overwrite behavior, error handling for unknown IDs, or what the response contains, leaving the agent with significant uncertainty.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All four parameters have descriptions in the schema (100% schema coverage), so the baseline is 3. The description adds no extra parameter semantics, but the schema documents id, name, platform, and device_targets sufficiently.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Update' with the resource 'platform target', and the word 'existing' makes clear it modifies an already-created entity. This distinguishes it from sibling tools like create_platform_target, delete_platform_target, and get_platform_target.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 create_platform_target, delete_platform_target, or other update tools. It neither states the appropriate context nor excludes alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits itself. It states the action but does not explain update semantics (e.g., partial vs. full replacement), permissions required, side effects, or return values. This lack of detail is inadequate for a mutating 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no redundant words. It front-loads the verb and resource, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 12 parameters, a nested object, no output schema, and no annotations, the one-sentence description lacks important context about update behavior and expected return. The schema provides parameter details, but the description does not clarify partial updates, permissions, or effects, leaving the tool under-specified for an agent to invoke confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes all 12 parameters with 100% coverage, so the description does not need to re-explain them. The description itself adds no parameter-specific meaning, but the schema already provides adequate context, yielding a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'update' with resource 'publisher' and notes it applies to an existing one. This clearly distinguishes it from create_publisher, get_publisher, and delete_publisher among 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 Guidelines2/5Does 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 rather than alternatives. There is no mention of prerequisites, such as the publisher needing to exist or using get_publisher first, nor any comparison to create_publisher or archive_publisher.
Agents often have multiple tools that could apply. Explicit usage guidance like "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, but it only says 'Update an existing user attribute', implying mutation. It does not disclose whether partial updates are supported, what happens if the attribute does not exist, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, no filler. It concisely states the action and resource, making it appropriately sized for a simple update tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple CRUD update with 4 parameters and no output schema, but the description does not explain expected behavior (e.g., whether fields are optional, error handling) or any prerequisites. This is below the minimum viable level for a mutation tool with no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters, so the baseline is 3. The description adds no extra meaning beyond the schema fields and does not clarify relationships like id and user_db_id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update an existing user attribute') and the resource ('in a user database'). It distinguishes from sibling tools like create_user_attribute and delete_user_attribute by using 'Update' and 'existing'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 create/delete alternatives, nor any prerequisites. The description only states the action without contextual or alternative usage hints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry behavioral transparency. It only states the action ('create') without disclosing side effects, required permissions, idempotency, or what happens if an ID already exists. The description adds no context beyond what the tool name implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words or filler. It efficiently states the action and resource, making it highly scannable for an agent. There is no wasted content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create operation with no output schema and no annotations, the description is too minimal. It does not explain what a universal ad ID is, whether any parameter combinations are required, or what the expected response would be. This leaves the agent without enough context to confidently invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all three parameters (name, id_value, id_registry) achieving 100% schema_description_coverage, so the description need not repeat parameter syntax. The description itself adds no additional parameter meaning beyond the schema, warranting the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a VAST 4.2 universal ad ID' uses a specific verb ('create') and identifies the resource ('VAST 4.2 universal ad ID'), clearly distinguishing this tool from sibling tools that update, delete, get, or list the same entity. The 'VAST 4.2' qualifier also differentiates it from non-versioned ad 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 Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not state when to use this tool versus alternatives, mention any prerequisites, or indicate whether this is the preferred method for creating a universal ad ID. There are no exclusions or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 disclosing behavioral traits. It only says 'Delete' but does not specify whether the deletion is permanent, irreversible, or requires certain permissions, nor what happens to associated resources. For a destructive operation, this lacks essential transparency about consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words: 'Delete a VAST 4.2 icon click fallback image.' It is appropriately concise for such a simple tool, though it lacks actionable guidance within the text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one parameter, no output schema), the description adequately states the action but fails to provide context about the destructive nature of deletion, such as irreversibility or return behavior. An agent selecting this tool would benefit from a note about the permanent effect, making the description minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the single required parameter `id` as the 'VAST 4.2 icon click fallback image ID' with 100% coverage. The description adds no additional parameter detail, but since the schema is complete, the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and the specific resource ('VAST 4.2 icon click fallback image'), which exactly matches the tool name and distinguishes it from sibling operations like create, get, and update on the same resource. It is unambiguous and leaves no doubt about the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, context for deletion (e.g., removing an unused fallback image), or distinctions from related operations on icons or other resources. An agent would have to infer usage solely from the tool name and the generic 'delete' verb.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It only states that deletion occurs, but does not disclose whether deletion is permanent, irreversible, or has cascading effects on related entities. For a destructive operation, this is a significant transparency 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It is concise but not overlong; however, it is terse to the point of omitting useful detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one parameter, no output schema), the description is minimally sufficient to convey the core action. However, it lacks behavioral or consequence information that would make it complete for the user, especially without annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the only parameter 'id' as 'VAST 4.2 media file ID' (100% coverage). The description adds no extra meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Delete') and resource ('VAST 4.2 media file'), clearly distinguishing it from sibling tools like vast42_get_media_file, vast42_create_media_file, and vast42_update_media_file. The action and target are 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites, side effects, or cases where deletion would be inappropriate. The usage context is only implicitly understood from the CRUD sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must fully disclose behavior. It only states that it gets a single image, but does not describe what the response contains (e.g., image binary, URL, metadata), error behavior for missing IDs, permissions needed, or whether this is a read-only operation. This is a significant gap for a tool with no structured safety metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It is front-loaded and appropriate for a simple get operation. Every word serves a purpose, making it highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even for a low-complexity get tool, the description is incomplete because there is no output schema or annotations to compensate. It fails to specify what the returned resource looks like or how the result should be handled. The lack of behavioral detail and usage guidance leaves the description insufficient for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already defines the only parameter 'id' with a description 'VAST 4.2 icon click fallback image ID'. Since schema coverage is 100%, the description does not need to repeat parameter details. It adds no extra semantic information beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('VAST 4.2 icon click fallback image'), clearly stating it retrieves a single item. This distinguishes it from sibling list/create/update/delete operations and from the separately named 'get_icon' tool, so there is no ambiguity about purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 (e.g., vast42_list_icon_click_fallback_images for fetching all, or vast42_get_icon for a different resource). It does not mention prerequisites like having an ID or that it complements other CRUD 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 disclosing behavioral traits. It only repeats the action 'Get' and does not mention read-only status, return format, error handling, or other side effects, providing minimal 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no superfluous information. It states the essential action and resource without waste, making it appropriately sized for a simple get operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get tool with one well-documented parameter, the description covers the basic purpose effectively. While it does not explicitly describe the return value or potential failures, the simplicity of the operation and schema coverage make it reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of the single parameter 'id' with a description ('VAST 4.2 mezzanine ID'). The tool description adds no additional parameter meaning, but since schema coverage is high, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' and identifies the resource as a 'single VAST 4.2 mezzanine'. The word 'single' distinguishes it from list operations such as vast42_list_mezzanines, though it could be more explicit about what a mezzanine is.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 typical scenarios, prerequisites, or contrast with related get/list operations, leaving usage entirely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 available, the description carries the full burden of behavioral disclosure. It says 'List all' but does not mention pagination behavior (despite limit/offset parameters), potential large result sets, or that multiple calls may be needed to retrieve truly 'all' items. This could mislead an agent into expecting a single comprehensive response when the schema implies paginated results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler. It is front-loaded with the verb 'List' and clearly identifies the resource. It earns its place without unnecessary words, making it 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.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite being a simple list tool, the description lacks important context: it does not clarify how pagination works to actually retrieve all items, and there is no output schema to inform the agent about the returned data structure. The phrase 'List all' combined with pagination params is ambiguous, and without annotations or an output schema, the description is not fully complete for a reliable agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents both parameters with descriptions ('Max results to return (default 100, max 100)' and 'Pagination offset'), so the description does not need to add parameter details. The description itself provides no additional semantic context beyond the schema, matching the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all VAST 4.2 icon click fallback images' uses a specific verb ('List') and a precise resource ('VAST 4.2 icon click fallback images'), clearly distinguishing it from sibling tools like vast42_get_icon_click_fallback_image, vast42_create_icon_click_fallback_image, etc. The 'all' also signals a plural listing operation versus singular get/create/update/delete tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage context or alternative guidance is provided. It does not mention when to use this list tool versus the get tool for a single fallback image, nor any prerequisites or typical scenarios. The description simply states what it does without any when-to-use or when-not-to-use 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, the description bears the full burden of behavioral disclosure. It only says 'List all VAST 4.2 placements' and does not mention pagination, return format, read-only nature, or any side effects. The presence of 'limit' and 'offset' in the schema hints at pagination, but the description adds no explicit 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly worded sentence: 'List all VAST 4.2 placements.' It is front-loaded with the verb and resource, with zero wasted words. This is an appropriately minimal description for a simple list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, and the description does not explain the return value structure or pagination behavior. It also fails to clarify what a 'VAST 4.2 placement' is or how it differs from other placement types. Given the low complexity and 100% schema coverage, the description is minimally adequate but leaves out important contextual details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes both parameters (limit and offset) with 100% coverage. The description adds no additional parameter meaning beyond what the schema provides, which places it at the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the exact action ('List') and resource ('all VAST 4.2 placements'), making the purpose unmistakable. It distinguishes from similar sibling tools like vast_list_placements by specifically calling out the 'VAST 4.2' 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the many existing placement list tools (e.g., vast_list_placements, list_placements, draft_list_placements). The description lacks any context about use cases, alternatives, or exclusions, so 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 only states 'Update' without explaining whether this is a partial update, what happens to unspecified fields, required permissions, or potential side effects. No information is given about error behavior or idempotency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that immediately conveys the purpose. There is no redundant or extraneous information, and it is appropriately concise for a simple CRUD update tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Though the schema fully documents parameters, the description lacks critical context for an agent: no output schema, no annotations, and no behavioral or usage details. For a mutation tool, it should clarify update semantics (e.g., partial vs. full replacement), and what happens if the id is invalid. The description is insufficient for full contextual completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all four properties (id, name, width, height) having type and description in the schema. The tool description adds no additional meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and the specific resource ('VAST 4.2 icon click fallback image'). This distinguishes it from sibling CRUD tools like vast42_create_icon_click_fallback_image, vast42_delete_icon_click_fallback_image, etc. The verb+resource combination is explicit and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or contrast with related update tools (e.g., vast42_update_icon). For a CRUD tool, usage context is implied by the 'update' verb, but that is not articulated in the 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?
With no annotations, the description carries the full burden but doesn't disclose behavioral traits like whether this is a partial update, what happens if the ID is invalid, what the response looks like, or any side effects. It only states the 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence, front-loaded with the key word 'Update', and contains no waste. It is highly concise and well-structured for the minimal information it gives.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations and no output schema, so the description must compensate. It fails to provide context about return values, error conditions, or operational constraints, making it incomplete for a 5-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no parameter-level information beyond what the schema already provides, which is acceptable under the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Update') and resource ('VAST 4.2 non-linear media'), making it clear what the tool does. This distinguishes it from sibling create/get/delete/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/5Does 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 vs alternatives, prerequisites, or context. The verb 'Update' is the only signal, but it doesn't say, for example, that the ID must exist or that create/delete are different 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, the description carries the full burden. It merely says 'Update' without explaining whether it's a partial or full replacement, side effects, permission requirements, or return values. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It is appropriately concise for a simple update operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter update tool with no annotations or output schema, the description is severely incomplete. It does not explain the update behavior, optional fields, or any constraints beyond the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description need not repeat parameter details. However, it adds no additional context about how the parameters relate (e.g., whether id_registry is required for certain registries). The baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and the specific resource ('VAST 4.2 universal ad ID'). This distinguishes it from sibling tools like vast42_create_universal_ad_id and vast42_delete_universal_ad_id.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, prerequisites, or alternatives. It does not explain that this modifies an existing universal ad ID or that it should be used after creation.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 restates the action and adds a semantic clarification, but does not mention side effects, required permissions, return value, or any other behavioral traits beyond the basic create 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded with the core action and immediately clarifies the resource. No wasted words or redundant information, making it an example of efficient description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool having 13 parameters and complex relationships (e.g., zone/channel mutual exclusivity, required schedule), the description provides no lifecycle context, no mention of output/return value (since no output schema exists), and no differentiation from the very similar vast42_create_placement sibling. The rich schema partially compensates, but the description itself is too sparse for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no parameter-level semantics beyond what the schema already fully documents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('create') and resource ('VAST placement') and the parenthetical clarifies exactly what that means ('assign a VAST ad item or campaign to a VAST zone or channel'). This distinguishes it from similar tools like vast_create_campaign_assignment and vast42_create_placement by clearly defining the placement concept.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the many sibling tools (e.g., vast42_create_placement, vast_create_campaign_assignment). It does not mention prerequisites, exclusions, or contextual cues that would help an agent decide between 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 'Delete' without conveying irreversibility, cascading effects on associated entities (e.g., assignments, schedules), or any required authorization. This is a significant gap 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words or repetition. It efficiently states the tool's purpose without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool, the description is critically incomplete: it lacks any information about side effects, prerequisites, or post-deletion behavior. There is no output schema to clarify return values, and no annotations to cover safety or mutability, leaving the agent without essential context for such a destructive call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for the single 'id' parameter with the description 'VAST campaign ID'. The tool description adds no additional parameter context, so the baseline score of 3 applies as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a VAST campaign' clearly states the action (delete) and the resource (VAST campaign), and distinguishes from sibling tools like vast_delete_archived_campaign and vast_delete_campaign_assignment. It is specific enough to identify the tool's core function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 vast_delete_archived_campaign for archived campaigns. There is no mention of prerequisites, context, or exclusions, leaving the agent without direction for appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It merely restates the delete action without mentioning permanence, side effects, required permissions, or what happens to the assignment.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that efficiently conveys the core action with no redundant words or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simple interface (one parameter, no output schema, no annotations), the description is still too sparse. It lacks any note about the consequences of the removal, whether it is reversible, or what the result of a successful deletion is.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully documents the sole parameter `id` with the description 'VAST channel zone assignment ID', achieving 100% schema coverage. The tool description does not add any additional parameter context, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Remove') and clearly identifies the resource ('a VAST zone from a VAST channel'). It distinguishes this tool from generic channel or zone tools by naming the VAST-specific entities, even though a similarly named sibling exists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 instead of the sibling `delete_channel_zone_assignment` or any other channel/zone assignment tools. It only states the action without 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?
The description discloses no behavioral outcomes such as whether deletion is permanent, cascading, or requires specific permissions. Since no annotations are provided, the description carries the full burden of transparency, but it remains silent on these critical aspects of 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence with no unnecessary words. Every word contributes to the core meaning, making it exceptionally concise and well-structured for the minimal information it provides.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one required parameter, no output schema), the description could still mention consequences like irreversibility or impact on related resources (e.g., campaign assignments). It lacks such context, leaving the agent without a complete understanding of the action's implications.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full coverage of the single parameter, including its description ('VAST placement ID'). The tool description adds no further parameter information, so it does not enhance what the schema already conveys.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation ('Delete') and the resource ('VAST placement'), matching the tool name. The explicit mention of 'VAST' distinguishes it from the sibling tool 'delete_placement', which deletes a non-VAST placement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 or about prerequisites (e.g., whether associated campaign assignments should be removed first). The description only states the operation, leaving the agent without contextual decision-making information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention that this is a read-only operation, how pagination works (beyond the schema), or whether it includes archived/draft items. It essentially restates the tool name without adding 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary words. It is front-loaded and each word contributes to the core purpose, 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema or annotations, the description is too minimal to provide adequate context. It does not explain what constitutes a VAST ad item, how 'all' interacts with pagination, or how this listing relates to other VAST tools. The description leaves significant ambiguity for an agent trying to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage for both 'limit' and 'offset', including descriptions for defaults and max values. The description adds no additional parameter meaning, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all VAST ad items' clearly states the action (list) and the resource (VAST ad items), distinguishing it from create/update/delete/get operations among siblings. The use of 'all' clarifies scope, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as list_ad_items, draft_list_ad_items, or other VAST listing tools. The description lacks any context about which scenario this serves or exclusions for draft/archived items.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It only states 'Update an existing VAST zone' without disclosing whether the update is partial or full replacement, any side effects on associated ad items or campaigns, or whether the zone must exist. This is minimal behavioral disclosure 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, succinct sentence that immediately conveys the tool's purpose. There is no extraneous content, and it is appropriately front-loaded with the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter update tool with no annotations or output schema, the description is critically under-specified. It does not mention that only id is required, that other fields are optional for partial updates, or the mutual exclusion between default_vast_ad_item and default_vast_campaign. The schema provides some context, but the description itself fails to convey the update semantics, making it incomplete for reliable tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no parameter information beyond what the schema already documents. The schema itself provides decent descriptions for each field, including the mutual exclusivity of default_vast_ad_item and default_vast_campaign, so the description's lack of param detail is not penalized further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 VAST zone'), with a specific verb+resource structure. It distinguishes from sibling tools like vast_create_zone, vast_get_zone, and vast_delete_zone by explicitly indicating an update operation on a zone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 vast_create_zone or vast_delete_zone. There is no mention of prerequisites, scenarios, or exclusions, leaving the agent to infer usage solely from 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 the full burden of behavioral disclosure. The phrase 'replace all entries' hints at a destructive overwrite, but it does not disclose whether the operation is irreversible, whether it requires special permissions, what happens to the existing list structure, or what the response looks like. Given the absence of annotations and the mutating nature of the 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action ('Bulk replace'). It is appropriately sized for the simple purpose, though it could include a bit more detail without becoming verbose. The structure is clean and every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a bulk mutation with no annotations and no output schema, the description is too sparse to be fully actionable. It lacks critical context such as the destructive/irreversible nature of the operation, prerequisites (e.g., the data list must exist), what the CSV format should be (headers, column structure), and the expected response. An agent would need to guess these details, making the description insufficient for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: both 'id' and 'data' are described in the input schema. The description adds no additional meaning beyond the schema, so the baseline of 3 is appropriate. The schema already explains that 'data' is CSV content and 'id' is the data list identifier, and the description does not clarify format or constraints further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Bulk replace all entries in a data list' uses a specific verb ('replace') and resource ('data list'), clearly indicating the action and scope. It distinguishes from sibling tools like bulk_upload_add_data_list and bulk_upload_remove_data_list by specifying 'replace all entries', which is a unique 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you need to replace all entries in a data list) but does not explicitly state alternatives or exclusion criteria. There is no mention of when to use bulk_upload_add_data_list or bulk_upload_remove_data_list instead, so usage guidance is only implied, 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?
With no annotations present, the description must disclose behavioral traits, but it only restates required fields. It does not mention side effects, return values, permissions, or any implications of creating a template, leaving the agent with minimal insight beyond the obvious 'create' 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that covers the action and all required parameters without unnecessary wording. It is well-structured and front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create operation with clearly named parameters, the description is adequate but minimal. It does not specify return behavior or the exact format expected for 'file' (e.g., URL vs path), though the schema covers these details. The absence of an output schema means the agent may not know what to expect after invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema already describes each parameter. The description adds only the clarification that 'attributes' is a JSON string, which is also present in the schema, offering no additional semantic value beyond what structured data provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Create' with the clear resource 'new contract template', distinguishing it from sibling tools like update_contract_template and delete_contract_template. Listing required parameters further solidifies the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as create_contract, create_contract_document, or create_signature_request. The description only states what the tool does and its required fields, leaving the agent to infer 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 the basic action ('create') but omits side effects, permissions, return values, or error conditions. It only describes the parameter structure, not behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the purpose, and includes relevant structure for `areas`. It is concise and does not waste words, though it omits some important context about `range` and `inclusive`.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal. With no output schema and no annotations, it does not explain the return value, the role of `range` and `inclusive` parameters, or any prerequisites. Given 5 parameters and 2 required, the description is insufficient for an AI agent to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The tool description adds a brief summary of the `areas` array structure, but this largely duplicates the schema descriptions. No additional parameter semantics are provided beyond what the schema offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 geo target for geographic targeting.' This specifies a verb (create), a resource (geo target), and a scope (geographic targeting), distinguishing it from sibling tools like update_geo_target, delete_geo_target, and list_geo_targets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The usage is implied by the CRUD context—'create' clearly indicates its purpose—but no alternatives are mentioned and no exclusions are provided. Sibling tools like update_geo_target exist but are not referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "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, but it only restates the tool's purpose. It does not disclose preconditions (e.g., data_list must exist), effects of creation, whether changes are immediately active, or any validation/error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that communicates the action and key distinguishing feature without any filler or unnecessary technical detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and all parameters are documented, so the description is adequate for basic invocation. However, it lacks guidance on return values, required data_list existence, or how it relates to other targeting tools, leaving some contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully explains label, data_list, and inclusive. The description adds a slight conceptual link by mentioning inclusion/exclusion and data list, but does not add detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create'), the resource ('list target'), and the key purpose ('inclusion/exclusion using a data list'). This distinguishes it from sibling tools like update_list_target, get_list_target, and delete_list_target.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like data_key_target or platform_target. The context of use is only implied by the phrase 'Create a new list target,' with no explicit when-to-use 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 the full burden of behavioral disclosure. It only states a basic create action, but doesn't mention validation rules, the relationship between variables and raw_html, potential errors, or return behavior. This 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that communicates the core purpose without any wasted words. It is concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (3 params) and strong schema coverage, the description is minimally adequate. However, it lacks context about how this tool fits among siblings, such as create_ortb_native_template, and omits any mention of the variables array structure, though the schema covers that. It is sufficient but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with detailed descriptions for all parameters, including placeholder examples. The description adds little beyond the schema, only restating the existence of HTML and variable placeholders, so it meets the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and the resource ('new native ad template'), and adds specificity with 'HTML and variable placeholders.' This distinguishes it from sibling tools like create_ortb_native_template, which would be a different template 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as create_ortb_native_template or other template creation tools. There is no mention of prerequisites, exclusions, or scenarios where this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It discloses no side effects, permissions, uniqueness constraints, or return behavior. For a create operation, this lack of detail leaves the agent unaware of what happens on invocation or what the response will be.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the action and resource. There is no redundant or extraneous information, making it appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with fully documented parameters, but the description lacks information about expected output, usage context, and behavioral implications. It is minimally viable but could benefit from stating what the tool returns or when it should be used in a targeting workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter (name, platform, device_targets) already described in the input schema. The tool description adds no extra parameter semantics, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (create) and resource (platform target), and adds context about device/OS/browser targeting. It distinguishes from sibling CRUD tools (list, get, update, delete) by the specific verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. It does not reference the sibling platform target tools or suggest when creation is appropriate. The only implied usage is the action itself, which is insufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description only restates the create action without explaining side effects, required parent relationships, idempotency, permissions, or response behavior. It adds minimal behavioral context beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One compact sentence that states the action and scope with no filler. It is appropriately front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create operation, the description plus complete schema is minimally sufficient, but it lacks guidance on using bulk creation for multiple sources, any validation rules, or what a successful creation returns. It is adequate but not enriched.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes all four parameters at 100% coverage (source URL, name, type, publisher ID), so the description doesn't need to repeat them. It also adds no extra semantic constraints or relationships beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and resource ('product source') and scopes it to a publisher. It clearly distinguishes from sibling tools like update_product_source, delete_product_source, and bulk_create_product_sources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 bulk_create_product_sources or create_product_source_target. The phrasing implies a simple create action but offers no prerequisites, exclusions, or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits. It only repeats the operation 'create' with no additional details such as required existence of the user_db_id, uniqueness constraints, or potential side effects. The description adds minimal value beyond the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, front-loaded with the verb 'Create' and the resource. It is highly concise and to the point, with zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives basic context (creating an attribute within a user database) but omits other useful context like the distinction between required and optional parameters, the interpretation of 'id' vs 'label', or any post-creation behavior. Given the tool's simplicity and fully described schema, it is adequate but not rich in contextual detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All four parameters are fully documented in the schema with 100% coverage, so the schema carries the heavy lifting. The description does not add any parameter-level meaning beyond what the schema already provides, warranting the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and the resource ('a new user attribute in a user database'). It distinguishes itself from sibling tools like get_user_attribute, update_user_attribute, and delete_user_attribute by using the specific 'create' verb and the context 'in a user database'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. It does not mention that this is for adding a new field to an existing user database or contrast with updating an existing attribute.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 create (mutation) operation but does not disclose permissions, idempotency, whether a template is required, or what the response contains. This lack of detail makes it 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded declarative sentence with nine words. It conveys the essential purpose without redundancy or irrelevant details, earning every word's place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 3-parameter create tool with full schema coverage, the description is minimally adequate. However, it lacks behavioral details (e.g., return value, required template in practice) and usage guidance, which leaves gaps for agents unfamiliar with the domain. It is not as complete as the high-calibration example.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter described ('ORTB native ad name', 'Standard zone ID', 'ORTB native template ID'). The description adds no additional meaning beyond restating 'standard zone' from the schema, so it stays at the baseline without enriching parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create'), the resource ('ORTB native ad'), and the scope ('for a standard zone'), distinguishing it from sibling tools like create_native_template or create_zone. The inclusion of 'standard zone' narrows the target and differentiates it from zone types like email or catalog zones.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 does not mention prerequisites (e.g., needing an ORTB native template), exclusions, or that other tools like update_zone_ortb_native_ad exist for modifications. The only implicit guidance is the 'standard zone' qualifier, but no explicit when/when-not instructions 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, the description is responsible for disclosing behavioral traits, but it only states 'Delete.' It does not clarify whether deletion is permanent, whether there are cascading effects, what happens if the configuration is in use, or what the response looks like. This is insufficient for a destructive mutation tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that immediately states the action and target. There is no filler or redundant information, which is appropriately concise for a simple delete operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one fully documented parameter and no output schema, so the description does not need to explain return values. However, it lacks behavioral context such as permanence, side effects, or when deletion is appropriate, leaving it minimally complete but not fully contextual.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the single 'id' parameter as 'Upload configuration ID,' giving 100% schema description coverage. The description adds no extra parameter-level meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Delete') and a specific resource ('event log upload configuration'), making the operation unambiguous. It also distinguishes from sibling CRUD tools like get_event_log_upload_config, create_event_log_upload_config, and update_event_log_upload_config through the explicit delete verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the related get/create/update/list tools, and it mentions no prerequisites or exclusions. The intended usage is only implicit from the delete verb and the tool name, with no contextual or alternative 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 must carry the burden of disclosing behavior. It only says 'Delete' without mentioning whether the deletion is permanent, whether there are side effects, permission requirements, or error behavior. For a destructive operation, 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single four-word sentence that delivers the essential information with zero wasted words. It is front-loaded with the 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple (one parameter, no output schema), the description lacks information about return values, error cases, or permanence of deletion. It is minimally adequate for a basic delete operation but leaves out behavioral context that an agent would benefit from knowing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents the only parameter 'id' with 'Geo target ID', achieving 100% schema description coverage. The description adds no further semantic meaning beyond the obvious action, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a geo target' clearly states the action (delete) and the resource (geo target), distinguishing it from sibling tools like create_geo_target, update_geo_target, get_geo_target, and list_geo_targets. It uses a specific verb+resource construction with no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. It simply states the action without context about when deletion is appropriate or any constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It only says 'Delete a PMP deal' without disclosing irreversibility, cascading effects, or permission requirements. For a destructive operation, 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with clear front-loaded verb and object. No redundant information, ideal size.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter), but the description lacks important context about deletion behavior. It doesn't state whether deletion is permanent, whether there are dependencies, or what happens to related entities. Given the absence of annotations and output schema, more context would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the id parameter as 'PMP deal ID' with 100% coverage. The description adds no additional parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Delete' with the resource 'PMP deal', making the action unambiguous. It clearly distinguishes from sibling tools like create_pmp_deal, update_pmp_deal, and get_pmp_deal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, such as whether the deal must exist or whether deletion is permanent. The description simply states the action 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?
No annotations are present, and the description only states the action without disclosing consequences such as irreversibility, cascading effects, required permissions, or impact on related entities. For a destructive operation, this leaves the agent without critical behavioral context. The description does not describe the response format or any caveats.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no redundant words. It is appropriately sized for the tool's simplicity, though it could be longer if needed to address behavioral details—but that is a content issue, not a structure issue.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter delete tool with no output schema, the description provides the essential action but lacks any context about usage scenarios, side effects, or return values. Given the absence of annotations, this is minimally viable but leaves gaps in an agent's understanding. The tool is simple enough that a score of 3 is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the single required parameter `id` as the postal code target ID, so the description does not need to add parameter details. The description adds no extra semantics beyond the schema, which is acceptable given 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 (postal code target), distinguishing it from other delete operations for other entity types like geo targets or list targets. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not explain when to use this tool versus create, get, update, or list operations for postal code targets, nor does it mention alternatives or prerequisites. This leaves the agent without sufficient 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, but it only restates the action. It does not disclose whether deletion is permanent, whether it requires specific permissions, or what happens to objects using the connection. This lacks behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the action and resource. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with a fully described parameter and no output schema, the description is minimal but lacks any note about destructiveness, preconditions, or return behavior, leaving some gaps for an agent relying solely on it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes the single parameter `id` as 'SFTP connection ID' (100% coverage), so the description need not add parameter details. It adds no extra meaning beyond the schema, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Delete') and resource ('SFTP connection'), clearly distinguishing it from sibling tools like create_sftp_connection, get_sftp_connection, and test_sftp_connection. It leaves no ambiguity about the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor any prerequisites or side effects. It merely states the action without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action 'Delete' but does not disclose whether the deletion is permanent, what happens to associated data (e.g., placements, ad items), whether it only succeeds for drafts, or any side effects. The word 'draft' implies a limited scope, but key behavioral context 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the action and resource. It contains no fluff or redundant information, and every word carries meaning. This is appropriately sized for a simple delete operation with one parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one well-documented parameter, no output schema), the description is minimally viable. However, the absence of annotations and lack of guidance on consequences or usage context leave gaps that could be filled. It does clearly state what it does, but for a destructive operation, a bit more context (e.g., irreversibility, status constraints) would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage for the single parameter 'id' with description 'Draft campaign ID', so the baseline is 3. The tool description adds minimal meaning by clarifying the resource is a 'draft standard campaign', which slightly reinforces the parameter's context, but does not introduce new details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description "Delete a draft standard campaign" uses the specific verb 'delete' and clearly identifies the resource ('draft standard campaign'). This distinguishes it from sibling tools like delete_campaign (for live campaigns), draft_delete_campaign_assignment, and draft_delete_catalog_ad_item, which target different resources or states.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 contrast with delete_campaign, archive_campaign, or draft_save_campaign, nor does it mention any prerequisites or restrictions (e.g., only works on unsaved drafts). This leaves the agent to infer usage solely from the 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 the full burden of behavioral disclosure. It only restates the delete action and does not explain irreversible effects, permission requirements, or what happens to related data. This is a significant gap 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence of five words with no filler or repetition. It is appropriately sized for the simplicity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter delete operation with no output schema, the description plus schema minimally identify the action and target. However, the lack of any context about draft-state constraints, consequences, or differences from non-draft deletes leaves it only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'id' is fully described in the schema as 'Draft campaign assignment ID' (100% coverage), so the description does not need to add parameter details. It adds no extra semantic context, but the schema already provides sufficient meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Delete') and a specific resource ('draft campaign assignment'), clearly distinguishing it from sibling tools like draft_update_campaign_assignment, draft_get_campaign_assignment, and the non-draft delete_campaign_assignment. The intent 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/5Does 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 delete_campaign_assignment or draft_update_campaign_assignment. The word 'draft' implies it is for unpublished assignments, but there is no explicit when/when-not or prerequisite 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, the description carries the full burden of behavioral disclosure. It only states the action 'delete' without revealing whether deletion is permanent, cascades to related entities, requires special permissions, or what happens if the placement is not in draft status. Critical side-effect information 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately states the action and resource. Every word contributes to meaning, with no filler or redundant information. Perfectly sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter delete tool, the description is minimally adequate but lacks important context. It does not clarify what 'draft placement' means in relation to the draft workflow, nor does it mention permanence, side effects, or error behavior. Given the simple parameter set and absence of output schema, a middle score is justified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents the only parameter 'id' with the description 'Draft placement ID', achieving 100% schema coverage. The description adds no additional semantic meaning beyond this, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a draft placement' uses a specific verb ('Delete') and a specific resource ('draft placement'), clearly distinguishing it from sibling tools like 'delete_placement' or 'vast_delete_placement' via the 'draft' qualifier. It is unambiguous about 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/5Does 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 state that this is for draft placements only, nor does it mention the existence of non-draft deletion tools or any conditions/preconditions. The user is left to infer usage from the 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?
There are no annotations, so the description carries the full burden of behavioral disclosure. It adds no context about error behavior, authentication, response structure, or the distinction between draft and non-draft items, offering little beyond the operation's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It is front-loaded and immediately understandable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with one parameter, the description is minimally adequate but lacks context about draft status, return payload, and relationship to sibling tools. With no output schema, the description could have elaborated on what 'details' are returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single 'id' parameter is fully documented in the schema with description 'Draft ad item ID'. The tool description adds no additional semantic detail, so the baseline of 3 applies given 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the specific resource 'draft custom HTML ad item', distinguishing it from list/create/update/delete sibling tools. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives like get_custom_html_ad_item or draft_get_ad_item. The description relies solely on the tool name to convey its role, leaving the agent without 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'Get details' without specifying return format, error behavior, or any additional context such as authorization or data scope. For a simple read operation, the lack of information is still a 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero unnecessary words. It clearly conveys the action and object without fluff, making it appropriately sized for a simple getter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and a straightforward read purpose, and the schema covers parameter documentation. However, without annotations or an output schema, the description does not explain what 'details' includes, leaving the agent to infer the response structure. It is minimally adequate but not richly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage for the single 'id' parameter with a clear type and description. The tool description adds no extra meaning beyond what the schema specifies, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and resource 'specific draft placement', clearly conveying the tool's function. The 'draft' qualifier distinguishes it from the many non-draft placement getters in the sibling list, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 draft_list_placements or get_placement. It does not mention that this is for fetching a single draft placement by ID or suggest alternatives when listing is 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 must carry the behavioral disclosure burden. It only says 'Get details' with no mention of read-only semantics, response format, or any side effects. The agent gets no additional context about what 'details' entails or how the operation 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no fluff or redundancy. It states exactly what the tool does in as few words as possible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only one parameter and no output schema, the description is minimal but sufficient for a simple get-by-id tool. However, it does not specify what the returned details include or any special behavior, leaving some ambiguity about the tool's full scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — the single parameter 'id' is described as 'Draft ad item ID'. The description adds no further parameter meaning, so the baseline score of 3 applies because the schema already documents the parameter adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get details') and the resource ('specific draft rich media ad item'). It differentiates this tool from siblings like draft_get_image_ad_item and get_rich_media_ad_item by specifying both 'draft' and 'rich media'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 draft_get_ad_item or get_rich_media_ad_item. There are no exclusions, prerequisites, or context clues about selecting this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'details' but does not describe the return structure, potential errors, required permissions, or any side effects. For a read operation, this lack of context is a notable 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant wording. It is front-loaded with the action and resource, and every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with one well-documented parameter and no output schema, the description is minimally viable but does not explain what 'details' are returned. The lack of annotations and output schema means the description could have added more context, but the operation is straightforward enough that a basic description suffices.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the single parameter 'id' with a description 'Draft schedule ID', and schema description coverage is 100%. The description adds no additional meaning beyond what the schema already provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and identifies the resource as 'a specific draft schedule', clearly distinguishing it from list, create, update, and delete operations. It also differentiates from non-draft schedule getters like get_schedule and vast_get_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/5Does 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 draft_list_schedules. The description simply states what it does without any contextual cues 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?
There are no annotations, so the description carries the full burden. It states 'all' but does not mention pagination behavior, default limits, ordering, or return format. The presence of 'limit' and 'offset' parameters implies pagination, but this is not explicitly described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that effectively communicates the core purpose. No filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with fully documented parameters, the description is minimally sufficient. However, the lack of annotations and absence of any explanation about pagination behavior or output structure leaves some gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides complete descriptions for both parameters ('limit' and 'offset') with 100% coverage. The description adds no additional semantic value beyond what the schema already communicates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the specific resource ('draft catalog ad items'). The 'draft' qualifier distinguishes it from the sibling tool 'list_catalog_ad_items', making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'list_catalog_ad_items' or 'draft_get_catalog_ad_item'. It is implied that this lists all draft items, but no explicit context or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It claims to 'List all' items but does not mention that the tool uses pagination via limit/offset, nor does it clarify whether 'all' means all across pages or just the current page. Read-only behavior is implied but not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words. It is appropriately sized and front-loaded, conveying the core purpose immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with pagination parameters, the description is minimally adequate. However, it lacks context about the draft vs. non-draft distinction and how pagination interacts with 'all'. The presence of sibling tools like 'draft_list_ad_items' makes the missing clarification more significant, but the name and schema partially compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage with descriptions for 'limit' and 'offset', so the schema already documents these parameters. The description adds no additional meaning about how they affect the results, but the schema is sufficient. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all draft rich media ad items' uses a specific verb ('List'), a clear resource ('draft rich media ad items'), and distinguishes from sibling tools like 'draft_list_image_ad_items' and 'list_rich_media_ad_items' by explicitly targeting draft rich media 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/5Does 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 explain when to choose this over 'draft_list_ad_items' or the non-draft 'list_rich_media_ad_items', nor does it mention any prerequisites or 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 only states the operation (update) without revealing whether it performs a partial update, replaces the entire draft, requires specific permissions, or what happens if the id does not exist. This leaves the agent without 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately conveys the tool's purpose with no filler. It is well-structured and front-loaded, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update tool with a schema that documents both parameters, the description is minimally complete. However, the lack of an output schema, no annotation guidance, and no explanation of behavior on partial updates or valid native ad item fields means the agent must infer important details from elsewhere. It is adequate but not rich enough for confident invocation in ambiguous scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description covers 100% of parameters (id and draft), so the baseline is 3. The description adds no additional parameter semantics beyond what the schema already provides, but it also does not introduce confusion. The nested 'draft' property is described as containing fields to update, which gives minimal useful meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an existing draft native ad item' uses a specific verb (Update) and clear resource (draft native ad item), accurately reflecting the tool's function. It distinguishes from sibling tools like draft_create_native_ad_item and draft_delete_native_ad_item, and 'draft' differentiates it from the non-draft update_native_ad_item.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 draft_create_native_ad_item (for new items) or update_native_ad_item (for non-draft items). The description lacks any contextual direction for an agent to choose this tool correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 says 'Get details', implying a read operation, but does not mention response format, permissions, or any side effects. This is a minimal disclosure with 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It is appropriately sized for a simple getter, though 'details' is somewhat vague.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema, the description does not explain what details are returned. It also fails to clarify the distinction from get_publisher or when to use this tool over list_archived_publishers. The tool is simple but the description leaves important context unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with the single 'id' parameter described as 'Archived publisher ID'. The description adds 'specific' but no substantive meaning beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets details of a specific archived publisher, using the verb 'Get' and specifying the resource. The qualifier 'archived' distinguishes it from sibling tools like get_publisher for active publishers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied by the name and description: use when you need details of an archived publisher by ID. However, no explicit alternatives or when-not-to-use guidance is provided, despite the existence of sibling tools like get_publisher and list_archived_publishers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden for behavioral transparency. The description only says 'Get details' and does not disclose whether the operation is read-only (though the verb implies it), what specific details are returned, or error behavior (e.g., if the audience is not found). It also does not mention any permission requirements or side effects. This is minimal disclosure, adding little beyond what the tool's name already conveys.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence: 'Get details of a specific audience in a user database.' It front-loads the purpose, uses no unnecessary words, and fully conveys the action and scope without repetition or filler. This is appropriately sized for a simple read operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get tool, the description provides the essential purpose but lacks some context that would be helpful given there is no output schema and no annotations. It does not mention what the response includes (beyond 'details'), any prerequisites (e.g., that the user_db must exist), or how this tool relates to list_audiences for finding IDs. However, the tool is simple and the schema covers parameters, so it is minimally complete but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes both parameters: 'id' as Audience ID and 'user_db_id' as User database ID, giving 100% schema coverage. The description does not add any additional meaning about parameter semantics beyond what the schema provides. It reinforces that the audience is within a user database, but does not explain relationships or constraints (e.g., that audience IDs are unique only within a user_db), so it stays at the baseline for well-documented schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get details of a specific audience in a user database' uses a specific verb ('get') and identifies the resource ('audience') and its context ('user database'). It distinguishes from sibling tools like list_audiences (which retrieves multiple) and create/update/delete by focusing on a single, specific audience. However, it could more explicitly differentiate from list_audiences, but the word 'specific' makes it clear enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when you need details of one audience in a user database. It does not, however, provide explicit guidance on when not to use it or mention alternatives such as list_audiences for browsing. Since the context is straightforward and the name is self-explanatory, the usage is implied rather than 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 states 'Get details' without explicitly confirming it is a read-only operation, describing return format, or addressing error cases (e.g., unknown ID). This is minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the tool's purpose without any redundant words or fluff. It is perfectly sized for a simple getter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter getter, the description is minimally adequate: it states the resource and action. However, there is no output schema, so the description should clarify what 'details' includes, but it does not. It also omits any mention of return value shape or potential edge cases, making it only partially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents the 'id' parameter with type number and description 'Bidder ID', so schema coverage is 100%. The description's mention of 'by ID' merely echoes the schema, adding no extra semantic value beyond what is already present.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get details of a specific bidder by ID' uses a specific verb (Get), resource (bidder), and scope (by ID). This clearly distinguishes it from siblings like list_bidders, update_bidder, and delete_bidder.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as list_bidders or get_advertiser. It does not mention prerequisites, complementary tools, or 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Get details' without mentioning return format, error conditions, authentication needs, or what 'details' includes. For a simple read operation this is minimal but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded. It contains no unnecessary words and effectively communicates the core purpose without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema. The description is adequate for a basic 'get by id' operation but doesn't clarify what specific campaign details are returned or that it's a read-only operation. Given the lack of annotations and output schema, a bit more context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the only parameter 'id' with a description 'Campaign ID', so schema coverage is 100%. The description doesn't add further meaning beyond implying the id targets a specific campaign, which matches the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get details') and the resource ('a specific standard campaign'). The word 'standard' distinguishes it from archived or draft campaign variants, though it doesn't explicitly name alternative 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The word 'standard' implies this is for regular campaigns, not archived/draft/vast ones, giving some usage context. However, there is no explicit guidance on when to use this tool versus alternatives like get_archived_campaign or vast_get_campaign.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 of behavioral disclosure. It only says 'Get eligible zones,' giving no information about the return format (e.g., zone IDs or full objects), whether it requires special permissions, or what happens if the campaign doesn't exist. The behavior is largely opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence with no filler words. It front-loads the action and resource clearly, and every word contributes to meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one parameter and no output schema, the description is minimally viable but not fully self-contained. It does not explain what makes a zone 'eligible,' which is a core domain concept, nor does it mention any related resources or edge cases, leaving the agent to infer meaning.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage for the single parameter 'id' with description 'Campaign ID,' so the description doesn't need to add parameter details. The tool description's 'for a campaign' reinforces the id's purpose, but adds no extra semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and identifies the resource ('eligible zones') with an explicit scope ('for a campaign'). This clearly communicates what the tool does and distinguishes it from sibling tools like list_zones or get_campaign, even though no alternatives are mentioned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, no mention of prerequisites (e.g., campaign must exist), and no context about what constitutes an 'eligible zone.' The description merely states an action without explaining situational use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Get' implies a safe read operation, but it does not mention error conditions, required permissions, or response structure. This is minimal transparency beyond the 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence ('Get details of a specific catalog zone') with no redundant words. It is appropriately sized for a simple get-by-id tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one documented parameter and no output schema, the description covers the core purpose but lacks any details about return contents, error behavior, or usage context. It is minimally viable but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% since the only parameter 'id' is described as 'Catalog zone ID'. The description adds no additional parameter meaning beyond what the schema provides, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('catalog zone'), clearly indicating it retrieves details for a single zone. It implies differentiation from list operations and other zone-related tools, though it doesn't explicitly distinguish from get_catalog_zone_tag.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: the tool is for retrieving details of a specific catalog zone by ID. However, there is no explicit guidance on when to use this versus alternatives, or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only says 'get details' which implies a read operation, but it does not specify whether the item must exist, what permissions are required, what response structure to expect, or whether any fields are omitted. The description adds no behavioral context beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that states the verb, resource, and scope with no unnecessary words. It is front-loaded and straightforward.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a single parameter and no output schema or annotations, so the description is the only source of behavioral info. It adequately identifies the purpose but leaves gaps: it doesn't describe what 'details' includes, how to handle not-found cases, or how it differs from the draft_get_custom_html_ad_item counterpart. For a simple getter, this is sufficient but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully documents the single parameter (id) with a description ('Ad item ID'), so the baseline is 3. The description adds minimal meaning by saying 'specific' and tying the ID to the custom HTML ad item, but it does not elaborate on constraints, formats, or possible values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('get') and clearly identifies the resource ('details of a specific custom HTML ad item'), distinguishing it from sibling tools like list_custom_html_ad_items (list) and get_custom_html_ad_item_conversion_tag (tag retrieval). The word 'specific' implies lookup by ID, matching the required id parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that this tool is for live (non-draft) items, distinguishing it from draft_get_custom_html_ad_item, nor does it advise using get_custom_html_ad_item_conversion_tag for conversion tags. An agent must infer usage solely from 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?
With no annotations, the description carries the full burden for behavioral disclosure. It mentions the type of content (account activity) but omits details on date filtering defaults, log_type enumerations, pagination, or return format. The phrase 'etc.' is vague and does not clarify 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that immediately conveys the tool's purpose. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with three parameters and no output schema, the description provides a minimum viable explanation. However, it lacks critical operational details such as acceptable log_type values, date format expectations, and behavior when optional from/to are omitted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 100% of parameters ('End date filter', 'Start date filter', 'Type of event log to retrieve'), so baseline is 3. The description adds light context by linking log_type to 'account activity,' but does not specify date formats or valid log_type values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get'), the resource ('event logs'), and the scope ('account activity'), with concrete examples ('changes, logins'). This distinguishes it from sibling tools like get_event_log_upload_log, which target upload-specific logs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives or when not to use it. There is no mention of available log_type values, date range handling, or relationship to similar event log 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 for behavioral disclosure. It does not state whether the operation is read-only, what permissions are required, or what the returned tag contains. The 'Get' verb implies a read but lacks explicit safety or side-effect 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of eight words, immediately stating the verb and resource with no filler. It is optimally concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only one parameter, no output schema, and no annotations, the description is adequate but minimal. It identifies the resource but does not explain the return format (e.g., tag snippet) or prerequisites, which would be helpful given the lack of structured output information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'id' is fully described in the schema as 'Ad item ID', giving 100% schema description coverage. The description adds no additional semantic detail about the parameter beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' with the resource 'conversion tracking tag' scoped to 'native ad item', clearly distinguishing this tool from sibling conversion tag getters for other entity types like get_zone_conversion_tag or get_image_ad_item_conversion_tag.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention that this is the correct tool for native ad items or reference other conversion tag tools, leaving the agent to infer usage solely from the 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, the description carries the full burden. It states 'Get details' which implies a read-only operation, but it does not disclose return format, potential errors, authentication requirements, or any side effects. Minimal behavioral insight beyond the verb 'Get'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no unnecessary words. It immediately states the action and resource, achieving high conciseness and clear structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get tool with two required parameters, the description is adequate but lacks return value details and any business context. There is no output schema, so the description could have explained what 'details' includes, but it remains sufficient for a basic read operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both catalog_id and publisher_id described, but those descriptions are just field names. The tool description adds no further semantics about how the IDs relate or why both are needed, so it meets the baseline without adding value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get details of') and resource ('product catalog'), clearly indicating a read operation targeting a single catalog. It distinguishes from sibling tools like list_product_catalogs (which lists all) and get_product_catalog_item (which retrieves an item within a catalog).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The phrase 'a specific product catalog' implies a single-catalog lookup, but it does not mention alternatives or exclude cases like listing catalogs or retrieving catalog items.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the burden of behavioral disclosure. It only says 'Get a specific report schedule' and provides no information about read-only behavior, return format, error conditions, permissions, or any side effects. The get operation is inherently read-only, but the description adds no context beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no unnecessary words or repetition. It is appropriately sized for a simple getter tool and front-loads the key action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two well-documented parameters, but there is no output schema and no annotations. The description does not mention what is returned (e.g., the full schedule object) or any potential errors. It is minimally complete for a getter but lacks the extra context that would make it fully self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for both parameters (schedule_id and report_config_id), so the baseline is 3. The description itself adds no additional meaning beyond the schema; it does not explain how the parameters relate or provide extra context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a specific report schedule' uses a clear verb ('get') and resource ('report schedule') and explicitly indicates it retrieves a single item ('specific'). This distinguishes it from siblings like list_report_schedules which list multiple schedules, and create/update/delete variations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives. It does not mention that it requires both parameters or contrast with list_report_schedules or get_report_schedule_generated. Usage context is entirely implied by the verb, with no explicit when-to-use or when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 read operation with 'Get', but does not disclose what the report contains, whether it is a summary or detailed data, any required permissions, or return format. This is a minimal disclosure that adds little beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words. It is front-loaded with the action and resource, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only two optional parameters and no output schema, so the setting is relatively simple. However, the description does not explain what 'preset' or 'timezone' mean in practice, nor does it clarify how this relates to sibling forecast tools. It is minimally viable but lacks helpful context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The parameter descriptions in the schema ('Date preset', 'Timezone') are sparse but self-explanatory. The tool description does not add any additional context about how these parameters behave or their allowed values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('VAST channel forecast report'), clearly indicating a read operation for a forecast. It is distinguishable from sibling forecast tools by name and phrasing, but it does not explicitly differentiate from tools like get_vast_forecast or get_display_channel_forecast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'VAST channel forecast report' implies the tool is used when a forecast for a VAST channel is needed, providing some usage context. However, there is no explicit guidance on when to choose this over similar forecast tools (e.g., get_vast_forecast) or any 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 for behavioral disclosure. It only states the action with no detail on return format, permissions, rate limits, or what the conversion tracking tag looks like. This is insufficient for a tool with zero annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately states the purpose without any redundant phrases or filler. It is front-loaded 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one well-documented parameter, but there is no output schema to explain return values, and the description does not describe the output format or usage context. It lacks mention of related conversion tag tools or what an agent should do with the returned tag, making it minimally viable but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the only parameter 'id' has a description ('VAST placement ID'), so the schema already explains the parameter. The description does not add any additional context about the parameter beyond what the schema provides, keeping the baseline at 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get'), the object ('conversion tracking tag'), and the scope ('VAST placement'), which precisely identifies what the tool does. It distinguishes from sibling tools like get_vast_zone_conversion_tag or get_vast_campaign_conversion_tag by specifying 'VAST placement'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as get_placement_conversion_tag or get_vast_zone_conversion_tag. There is no mention of exclusions, prerequisites, or context that would help an agent choose this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It only states the operation ('Get') without mentioning return format (e.g., HTML/JavaScript snippet), authentication needs, or any side effects. The verb implies a read, but no additional behavioral context is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states exactly what the tool does without wasted words. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple read tool with one fully documented parameter and no output schema. The description adequately conveys the basic purpose but does not explain what a 'conversion tracking tag' is or what format the response will take, leaving a minor gap in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the single 'id' parameter clearly described as 'VAST zone ID'. The description adds no parameter details, but the schema already fully documents the parameter, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get VAST zone conversion tracking tag' uses a specific verb ('Get') and resource ('VAST zone conversion tracking tag'), clearly distinguishing it from sibling tools like get_vast_zone_tags (which likely returns all tags) and other conversion tag tools for ad items, campaigns, or placements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as get_vast_ad_item_conversion_tag, get_vast_campaign_conversion_tag, or get_vast_placement_conversion_tag. There is 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 responsibility for behavioral disclosure. It only states 'Get details', implying a read-only operation, but does not disclose permissions needed, error behavior, what 'standard' excludes, or whether archived zones are included. This is a significant gap for a mutation-free but potentially permission-sensitive 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action ('Get') and clearly identifies the resource ('details of a specific standard zone'). Every word contributes to clarity, with no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description is minimally viable but still lacks important context. It does not specify what 'details' are returned, how to interpret 'standard' against sibling zone types, or whether additional query parameters exist. However, the core purpose is clear enough for a basic get-by-id operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (the sole parameter 'id' is described as 'Zone ID'), so the baseline is 3. The description adds no extra meaning to the parameter beyond confirming the zone is 'standard' and specific, which is minimal but not harmful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves details for a specific standard zone, using the verb 'Get' with a specific resource. It distinguishes from siblings like list_zones (plural) and zone types like archived, email, or catalog zones by using 'standard' as a qualifier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as list_zones, get_archived_zone, get_email_zone, or get_catalog_zone. There is no mention of prerequisites, exclusions, or scenarios where another tool would be 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 the full burden. It only states 'List all advertisers' without disclosing pagination behavior, default limits, whether archived advertisers are included, or any other behavioral details. The description adds little beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action ('List all advertisers') followed by a minimal context phrase. There is no unnecessary information, and it is efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple list tool with a straightforward return value implied. However, the description does not clarify whether archived advertisers are included, which is a notable gap given the existence of list_archived_advertisers. The schema covers pagination, so completeness is acceptable but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters (limit and offset) with descriptions, so schema coverage is 100%. The description does not add any information about these parameters, but the schema already provides adequate semantics, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('List all advertisers') and distinguishes from get_advertiser by implying multiple results. However, it does not explicitly state whether archived advertisers are included, which is ambiguous given the sibling tool list_archived_advertisers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing advertisers but provides no explicit guidance on when to use this tool versus alternatives like list_archived_advertisers or get_advertiser. The context is clear but exclusions are 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?
With no annotations, the description must disclose behavior on its own. It adds nothing beyond what the name implies—it doesn't mention pagination, read-only nature, or any constraints on the returned data. The description is essentially a restatement of the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no filler or redundant information. It is appropriately sized for a simple list endpoint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward list tool with complete schema documentation, the description is functionally adequate but minimal. It does not explain return format or relationship to sibling tools, but the simplicity of the operation and complete parameter schema make it minimally viable without being misleading.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents both parameters (limit, offset) with descriptions, so the description does not need to add parameter details. Baseline score of 3 is appropriate since schema coverage is 100% and the description adds no extra meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all archived publishers' uses a specific verb and resource, clearly distinguishing it from tools like list_publishers (which likely lists active/all publishers) and get_archived_publisher (which fetches a single archived publisher).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. It does not mention that list_publishers exists for non-archived publishers, nor does it state any preconditions 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, the description carries the full burden of behavioral disclosure. It states 'List all' but fails to mention that pagination via limit/offset constrains the result set, which could mislead an agent into expecting every creative in one response. It also omits details about read-only guarantees, response format, or potential filtering, making the behavior partially opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, four-word sentence that is front-loaded and free of redundancy. Every word earns its place, and the structure is perfectly concise for a simple list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with two well-documented parameters and no output schema, the description is minimally adequate. However, the claim of 'all' without acknowledging pagination creates a subtle gap, and there is no mention of default ordering or response fields. The lack of any behavioral context or alternative tool references makes it incomplete for full agent autonomy.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with limit and offset clearly described as pagination controls. The description adds no additional meaning beyond 'all', which slightly conflicts with the pagination parameters but does not degrade the parameter understanding. A baseline score of 3 is appropriate because the schema carries the semantic weight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all audio creatives' uses a specific verb and resource, clearly distinguishing this from sibling tools like list_creatives or list_video_creatives. The scope ('audio') is explicit, and the intent 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/5Does 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 list_creatives, list_video_creatives, or get_audio_creative. The context is implied by the name and description, but there is no explicit differentiation or exclusion, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It implies a read-only operation via 'List' and scopes to the account, but doesn't mention pagination behavior (despite the schema's limit/offset params), response format, or any caveats. The word 'all' could be misleading given the default limit of 100, but it's not an explicit contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that front-loads the purpose. No wasted words or redundant information, making it appropriately concise for a straightforward list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple list tool but leaves gaps: no output schema exists and the description doesn't hint at the response structure. It also lacks usage guidance and mention of pagination. However, given the low complexity and the schema covering parameters, it meets the minimum viable threshold.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the two parameters (limit, offset), so the schema already provides full parameter documentation. The description adds no additional meaning about parameters, earning the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and identifies the resource ('beacon signing keys') with a clear scope ('in your AdButler account'). It clearly distinguishes from sibling tools like get_beacon_signing_key or validate_beacon_signing_key by being the list operation for this resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., get_beacon_signing_key for a single key, or validate_beacon_signing_key for validation). It doesn't mention exclusions or compare to sibling tools, 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?
Annotations are absent, so the description carries the full burden of behavioral disclosure. It only states what is listed and does not mention pagination, default limits, read-only nature, or any side effects, which are important for a list 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that effectively conveys the core purpose without redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with documented parameters, the description covers the main purpose. However, without an output schema or annotations, it lacks details about return format and pagination behavior, leaving minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both 'limit' and 'offset' parameters documented. The description adds no additional context about parameters, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list), the resource (campaign assignments), and defines the resource as 'ad items assigned to campaigns'. This specificity distinguishes it from other list tools like list_campaigns or vast_list_campaign_assignments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. Sibling tools such as draft_list_campaign_assignments or vast42_list_campaign_assignments are not mentioned, and there is no explanation of context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 only states that the tool lists all data lists. It does not disclose pagination behavior (despite limit/offset parameters), result format, default limits, or confirm read-only nature. The verb 'List' implies read-only, but no substantive behavioral detail is added.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, clear sentence with no redundant information. Every word contributes to the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation, the description is minimally adequate. However, there is no output schema and no mention of pagination defaults or return structure. The description does not fully compensate for the missing behavioral context, though the schema and simple nature of the tool keep it at a viable level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes both parameters (limit and offset) with 100% coverage. The description adds no additional meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource ('data lists'), the action ('List all'), and the scope ('in your AdButler account'). This distinguishes it from sibling tools like get_data_list (single) and create_data_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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_data_list. The phrase 'all data lists' implies listing versus fetching a single item, but no explicit when/when-not or alternative naming 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?
There are no annotations to provide behavioral context, and the description adds little beyond the basic list operation. It does not disclose behaviors such as whether deleted managers are included, how pagination behaves, ordering, or rate limits. The agent is left without crucial information about the tool's runtime behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear, front-loaded sentence that conveys the core purpose without any unnecessary words or repetition. It is highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with pagination parameters and no output schema, the description is minimally adequate. However, the phrase 'List all managers' could mislead an agent into thinking it receives every manager in one call, when in reality the limit/offset pagination means multiple calls may be required. More detail about pagination behavior and returned fields would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full descriptions for both 'limit' and 'offset' parameters (100% coverage). The description does not add additional meaning to these parameters, but since the schema handles the heavy lifting, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all managers in the AdButler account, using a specific verb ('List') and resource ('managers'). It distinguishes from 'get_manager' by explicitly indicating the scope is 'all' managers rather than a single entity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided about when to use this tool versus alternatives like 'get_manager'. The description only states what the tool does, not in what scenarios it should be preferred, nor does it mention pagination or when the limit/offset parameters would be needed to retrieve all results.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 does not mention pagination behavior (despite the limit/offset parameters), return format, or any side effects. 'List all roles' could be misleading since the schema implies pagination, but no clarification is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no wasted words. It efficiently communicates the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no output schema and no annotations, the description is minimally adequate. It states the core purpose but omits useful context such as pagination, whether results are sorted, or any scoping constraints beyond 'all roles'. A more complete description would mention these details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents both parameters (limit and offset) with clear descriptions. The description adds nothing beyond the schema, but since schema coverage is 100%, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all roles in your AdButler account' clearly states the verb (List), resource (roles), and scope (AdButler account). It effectively distinguishes this from sibling tools like get_role (which fetches a single role) and other list tools (e.g., list_managers, list_advertisers).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives like get_role or other listing tools. It merely states what it does without mentioning exclusions, prerequisites, or pointing to a more specific tool for filtered queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. 'List' clearly signals a read operation, and 'standard' indicates a scope limitation, but it does not disclose pagination defaults, response shape, or whether any hidden filtering applies. This is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
'List all standard zones' is a single, front-loaded phrase with no filler or redundancy. Every word contributes meaning, and the brevity is appropriate for a simple listing operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity list tool with fully documented parameters, the description is minimally adequate, but with no output schema and no sibling differentiation, it leaves ambiguity about what 'standard' excludes and what the response contains. It is not as complete as descriptions that explicitly name alternatives or define scope boundaries.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both limit and offset with descriptions, giving 100% schema coverage, so the description adds no parameter-level value. The word 'all' implies pagination, but the schema already documents limit/offset, keeping this at baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and resource 'zones' with the qualifier 'standard', which helps distinguish it from sibling variants like list_archived_zones, list_email_zones, vast_list_zones, and list_all_zones. However, 'standard' is not defined, and the distinction from list_all_zones remains somewhat ambiguous, so it stops short of 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool instead of the many sibling zone-listing tools, such as list_all_zones, list_archived_zones, or vast_list_zones. The description does not state exclusions or alternatives, so 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 explaining behavior. It merely says 'test', which implies a connection attempt, but it does not disclose what happens on success or failure, whether any state is modified, what permissions are required, or what the response format looks like. This is a significant gap for a tool that could have side effects like network calls or credential validation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that is to the point. It avoids unnecessary verbosity. However, it is so brief that it omits important behavioral details, so while it is concise, it could be slightly more informative without becoming bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description should compensate by explaining the tool's purpose and behavior. It fails to clarify what 'test' means operationally (e.g., does it authenticate, check connectivity, validate credentials?), what the return value represents, or whether specific fields are required for a successful test. The description is incomplete for a tool with five parameters and no structured output information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter (host, path, port, password, username) having a short description. The tool description adds no additional meaning beyond the schema. Since the schema already documents the parameters, a baseline of 3 is appropriate; no extra value is provided by the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Test an SFTP connection with the provided credentials'. The verb 'test' is specific and the resource 'SFTP connection' is clear. It distinguishes itself from sibling tools like create_sftp_connection, get_sftp_connection, and delete_sftp_connection, which manage the lifecycle of SFTP connections rather than testing them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to validate SFTP credentials, but it does not explicitly state when to use this tool versus alternatives such as create_sftp_connection or get_sftp_connection. It lacks clear context about prerequisites or exclusions, though the intended use case is reasonably inferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral transparency burden. It discloses only the core action (unarchiving/restoring) but omits side effects, permissions, reversibility, or what 'restore' entails (e.g., making the contract active again). This is minimal and leaves important behavioral traits undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. The action is front-loaded and the parenthetical adds a clear synonym without padding, making it appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter mutation without annotations or output schema, the description plus schema provide a baseline understanding: it unarchives a contract given an archived ID. However, it lacks context about the operation's effects on contract state, return behavior, or its place in the archive/unarchive workflow, leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the only parameter 'id' as 'Archived contract ID' (100% coverage). The description adds no parameter-specific meaning, so the baseline score of 3 applies for adequate schema-driven semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (unarchive) and resource (contract), with a clarifying parenthetical 'restore from archive'. This distinguishes it from sibling tools like archive_contract and delete_archived_contract, as it specifies the opposite operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention that it only applies to archived contracts, nor does it reference related operations like list_archived_contracts or archive_contract. Usage is only implied by the verb 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?
With no annotations provided, the description carries the full burden. It states the delete action but does not disclose whether deletion is permanent, requires special permissions, or affects related objects. No warnings or side effects are mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that conveys the essential operation with no superfluous words. It is appropriately concise for a simple delete tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no nested objects, no output schema). However, the description does not mention the success response, whether the operation is reversible, or any prerequisites. The lack of annotations and output schema leaves some behavioral gaps, but the minimal resource-destructive nature makes this borderline adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the single parameter 'id' with the description 'VAST 4.2 ad item ID' (100% coverage). The tool description adds no extra parameter details, but the schema already provides sufficient meaning for the required id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a VAST 4.2 ad item' uses a specific verb ('Delete') and resource ('VAST 4.2 ad item'), clearly distinguishing it from sibling tools like vast42_create_ad, vast42_update_ad, and vast42_list_ads.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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., vast_delete_ad_item or other vast42_delete_* tools). The name implies VAST 4.2 scope, but the description does not explicitly state preferred contexts 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 must disclose behavioral traits. It states 'Delete' but does not mention whether the deletion is permanent, whether it cascades to related data, whether special permissions are required, or what the return/error behavior is. The bare verb conveys only basic destructive intent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, 'Delete a VAST 4.2 campaign assignment', with no filler or redundant content. It is immediately readable and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-id delete operation, the description is minimally adequate, but with no annotations and no output schema, it omits useful context such as whether the action is reversible, whether it affects assignments in other states, and what the response contains. Given the large family of sibling CRUD tools, a little more context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage for the only parameter (id) with 'VAST 4.2 campaign assignment ID'. The description adds no new parameter semantics beyond echoing the resource name, so the high-coverage baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Delete') and resource ('VAST 4.2 campaign assignment'), clearly stating what the tool does. The 'vast42' prefix differentiates it from the generic vast_delete_campaign_assignment and delete_campaign_assignment 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the many related assignment tools (e.g., vast42_get_campaign_assignment, vast42_update_campaign_assignment, draft_delete_campaign_assignment, delete_campaign_assignment). The description merely states an action without context, preconditions, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for disclosing behavioral traits. It only states the deletion action without mentioning whether deletion is permanent, whether it cascades to related resources, or any side effects. This is insufficient for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately states the tool's purpose. There is no redundant information or unnecessary words, making it appropriately sized for a simple delete operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with one parameter and no output schema, the description is minimally adequate. However, it lacks any behavioral context (e.g., permanence, failure handling) that would be essential in the absence of annotations. The tool is low complexity, but the description could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter 'id', which is already documented as 'VAST 4.2 icon ID'. The description adds no extra semantic value beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a VAST 4.2 icon' uses a specific verb and resource, clearly distinguishing it from sibling tools like vast42_delete_ad or vast42_delete_icon_click_fallback_image. The resource is precisely identified as a VAST 4.2 icon.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 vast42_get_icon, vast42_update_icon, or vast42_create_icon. There are no prerequisites, exclusions, or alternative suggestions, 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?
No annotations are provided, and the description only says 'Delete' without disclosing whether the deletion is irreversible, cascading, or requires special permissions. It does not describe side effects or success/failure 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence with no redundant wording, immediately stating the action and target. Fully front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete-by-ID operation, the description and schema cover the basic invocation. However, the absence of annotations or behavioral notes leaves ambiguity about consequences (irreversibility, cascading deletes), making it minimally adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes the single required 'id' parameter (100% coverage), so the description adds little semantic value. The schema's description 'VAST 4.2 interactive creative file ID' is sufficient and matches the tool's purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Delete' and clearly identifies the target resource as 'VAST 4.2 interactive creative file', matching the tool name and distinguishing it from sibling delete tools for other VAST 4.2 entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 compared to alternatives such as vast42_delete_creative or vast42_delete_media_file. It only restates the action without providing context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It conveys only that the tool deletes a resource, with no mention of irreversibility, permissions, side effects, or consequences to associated entities.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that stays exactly on point. There is no redundant information or unnecessary elaboration, making it maximally concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with one well-documented parameter, the description is adequate to convey the core purpose. However, it lacks any usage context or behavioral details, and there is no output schema to clarify expected return values, leaving the agent with minimal guidance beyond the basics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes the single 'id' parameter as 'VAST 4.2 non-linear media ID' with 100% coverage. The description itself does not add new parameter semantics beyond reinforcing that the ID identifies the media to delete, so it meets the baseline but no more.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description "Delete a VAST 4.2 non-linear media" clearly specifies the action (delete) and target resource (VAST 4.2 non-linear media). This distinguishes it from sibling delete tools like vast42_delete_linear or vast42_delete_ad, which 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives, such as the non-4.2 vast_delete_non_linear_media or other VAST 4.2 delete operations. There is no mention of prerequisites, exclusions, or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only says 'Delete' without explaining whether the deletion is permanent, cascades to related resources, requires specific permissions, or affects serving. This is opaque for a mutating 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It communicates the essential operation and resource in minimal space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete-by-id tool, the description is minimally adequate, but it omits important context such as irreversibility, parent resource relationship, or what happens to related data. Given the lack of annotations and output schema, the description leaves noticeable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single 'id' parameter is adequately described in the schema as the VAST 4.2 universal ad ID. The description adds no extra meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Delete') and names an exact resource ('VAST 4.2 universal ad ID'), clearly distinguishing it from sibling tools like vast42_delete_ad or vast42_delete_creative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, such as when a universal ad ID should be deleted from a creative versus deleting the entire ad. The description only states the action 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?
No annotations are present, so the description must carry the full burden of behavioral disclosure. It only repeats the action 'Get' without stating that it is read-only, what happens if the ID is not found, permission requirements, or the structure of the returned object.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that is front-loaded with the verb and resource. Every word is useful, and there is no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-get tool with one well-documented parameter, the description is adequate but incomplete. It does not explain return value structure or error behavior, which is more critical because no output schema or annotations are present to fill the gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'id' already described as 'VAST 4.2 linear media ID'. The tool description adds no additional detail about the parameter, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb 'Get' and clearly identifies the resource as 'a single VAST 4.2 linear media'. The word 'single' distinguishes it from listing siblings like vast42_list_linears and from create/update/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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention that this is for retrieving one specific item by ID while list endpoints return collections, nor does it reference any prerequisites or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only says 'List all VAST 4.2 icons', which implies read-only behavior but does not explicitly state side effects, pagination, or required permissions. The default limit of 100 is not mentioned, potentially misleading the 'all' claim.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no wasted words. It is appropriately brief for a list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal but generally sufficient for a simple list tool. However, it omits pagination details and the fact that 'all' is limited by default, which could lead to incomplete retrieval expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully documents both limit and offset parameters with descriptions. The description adds no additional parameter semantics, but baseline of 3 applies due to high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies a list operation for VAST 4.2 icons, using the verb 'List' and a specific resource. It distinguishes from sibling get/create/update/delete icon tools by indicating the plural 'all icons'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 vast42_get_icon or vast42_list_icon_click_fallback_images. There is no mention of use cases 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, the description carries the full burden of behavioral disclosure. It only says 'List all' without revealing nuances such as pagination behavior, whether results are scoped to a particular advertiser/workspace, or any access requirements. The read-only nature is implied but not explicit, and no details about response characteristics are provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words. Every part of the sentence ('List all', 'VAST 4.2', 'interactive creative files') contributes to identifying the tool's purpose, making it extremely concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with two self-explanatory parameters, the description is minimally adequate. However, it lacks any mention of pagination semantics or return format, and without an output schema the agent is left guessing about the response structure. It does convey the scoping constraint ('all'), which is useful, but more detail on behavior would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema documents both parameters (limit and offset) with descriptions, achieving 100% schema description coverage. The tool description adds no additional meaning beyond what the schema already provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List all') and the specific resource ('VAST 4.2 interactive creative files'), making it distinct from sibling tools like vast42_list_ads or vast42_list_creatives. It also aligns with the naming pattern of other vast42 list tools, unambiguously indicating this is the enumeration operation for interactive creative files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 vast42_get_interactive_creative_file or the create/update/delete counterparts. While the name implies it is for listing, there is no explicit mention of when to prefer it over other tools or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states the basic action ('List all') and does not mention pagination behavior, default limits, return format, or any side effects (though listing is inherently read-only). The verb 'List' implies a safe operation, but no additional behavioral details are given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff. It is concise and front-loaded, efficiently 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (2 optional params, no output schema), the description is adequate for a basic listing operation. However, it omits any mention of pagination behavior (despite limit/offset parameters), which could lead an agent to assume 'all' means all results in a single response. Lacks detail on response structure, but this is partially mitigated by the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage: both 'limit' and 'offset' have descriptions. The description adds no parameter-specific meaning beyond what the schema already provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all VAST 4.2 universal ad IDs' uses a specific verb ('List') and a clear resource ('VAST 4.2 universal ad IDs'). It distinguishes this tool from siblings like vast42_get_universal_ad_id, vast42_create_universal_ad_id, etc., by clearly indicating a list operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that this should be used for listing as opposed to retrieving a single item (vast42_get_universal_ad_id) or for creating/updating/deleting. No context about typical use cases or exclusions 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 of behavioral disclosure. 'Delete' implies a destructive side effect, but the description does not state whether deletion is permanent, whether it cascades to associated records, or whether special permissions are required. This is a significant transparency 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It conveys the verb and resource clearly in minimal space, making it appropriately concise for a simple one-parameter deletion tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one fully documented parameter and no output schema, the tool is simple, but the description still lacks behavioral context such as permanence, side effects, or return format. It is minimally viable for an agent to invoke the deletion, but it leaves clear gaps about what happens after the call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the only parameter (id) with the description 'VAST non-linear media ID', providing 100% schema coverage. The tool description adds no additional parameter meaning beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and the specific resource ('VAST non-linear media'), using a specific verb+resource construction. It is distinct from sibling tools like vast_delete_linear_media and vast_delete_tracking, so there is no ambiguity about what is being deleted.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives, no prerequisites (e.g., checking existence via vast_get_non_linear_media first), and no exclusions. It only states the action, leaving the agent without contextual 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 'Delete' but does not disclose whether the deletion is permanent, whether it cascades to related entities, what permissions are required, or behavior for non-existent IDs. Minimal 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no wasted words. The description is front-loaded and immediately conveys the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with one parameter, the description is minimally sufficient. However, it lacks context about when to use it, what happens after deletion, and any alternatives or exclusions. Adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with 'VAST tracking ID'. The description adds no additional meaning about the ID format, how to obtain it, or any constraints. Since schema coverage is high, the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Delete a VAST tracking entry'. It clearly distinguishes this tool from siblings like vast_create_tracking, vast_get_tracking, vast_update_tracking, and vast_list_tracking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, prerequisites, or alternatives. The description simply states the action without contextualizing when deletion is appropriate or what side effects may occur.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 disclosing behavior, but it only says 'Get details' without mentioning whether the operation is read-only, what response format to expect, or any permission/error considerations. The read intent is implied but not elaborated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler words. It efficiently communicates the core purpose without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter get operation, the description is minimally adequate, but it lacks optional context such as what fields are included in 'details', behavior when the ID is not found, and relationship to sibling tools. Since there is no output schema and no annotations, a bit more explanatory detail would make it more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents the 'id' parameter with a description ('VAST ad item ID') and 100% schema coverage, so the description adds no additional parameter meaning beyond the schema baseline. The word 'specific' reaffirms the need for an ID but adds no new semantic detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and a clearly defined resource 'details of a specific VAST ad item', which distinguishes it from list operations like vast_list_ad_items and create/update/delete counterparts. It clearly conveys a retrieval-by-id operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 vast_list_ad_items, vast42_get_ad, or draft_get_ad_item. There is no mention of prerequisites, exclusions, or preferred 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 for behavioral disclosure. It states the operation is a 'get' (implying read-only) but does not describe what 'details' includes, how errors are handled (e.g., non-existent or non-archived zones), or any limitations. This is minimal beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately states the purpose with no filler or repetition. It is front-loaded and easily scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple, the description lacks context to disambiguate it from closely related sibling tools like 'get_archived_zone' (without VAST) and 'vast_get_zone' (non-archived). It also doesn't mention return value structure, though no output schema exists. The core purpose is clear, but completeness is limited given the sibling ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% description coverage for the 'id' parameter ('Archived VAST zone ID'). The description text adds no additional parameter semantics beyond what the schema already defines, so it meets the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get details') and the target resource ('a specific archived VAST zone'). It distinguishes itself from 'vast_list_archived_zones' (list vs. specific) and 'vast_get_zone' (archived vs. active) through the inclusion of 'archived' and 'VAST'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives such as 'vast_get_zone', 'vast_list_archived_zones', or 'get_archived_zone'. No conditions, prerequisites, or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must bear the full burden of behavioral disclosure, but it only states 'Get details' without mentioning that this is read-only, what happens when the ID is not found, or what fields are returned. It adds no context beyond the literal 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundancy. It efficiently conveys the action and resource, which is appropriately concise for a simple get operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema, so the description is minimally adequate. However, it does not explain what 'details' are included or error semantics, leaving some ambiguity for the agent. A 3 is appropriate for the given complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single required parameter 'id' with description 'VAST linear media ID', providing 100% schema coverage. The tool description does not add additional meaning, but the schema already documents the parameter fully, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('details of a specific VAST linear media'), and the word 'specific' distinguishes it from listing operations like vast_list_linear_media. It is unambiguous and identifies the target resource accurately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 vast_list_linear_media or vast42_get_linear. The description does not mention context, preconditions, or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states 'Get details' which is the obvious action, but does not disclose any behavioral traits such as read-only safety, required permissions, error responses, or return format. It adds no value beyond the literal meaning.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence ('Get details of a specific VAST placement') that is fully front-loaded and contains no wasted words. It is appropriately sized for a simple get-by-ID tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple signature (one required ID parameter, no output schema, no annotations), the description is minimally sufficient. However, it does not explain what 'details' will be returned, nor does it clarify which VAST API version (VAST vs VAST42) this applies to among the many sibling get tools, leaving some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the only parameter 'id' with 'VAST placement ID' at 100% coverage. The description does not add any additional meaning to the parameter. Baseline of 3 is appropriate since schema fully covers it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function using a specific verb ('Get') and resource ('details of a specific VAST placement'). It distinguishes from sibling list/create/update/delete tools, and 'specific' indicates a single entity by ID. The purpose is immediately apparent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives like vast_list_placements, vast_create_placement, or other get variants (get_placement, vast42_get_placement). The word 'specific' implies a need for an ID, but no exclusions or alternative recommendations 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?
No annotations are provided, so the description carries the full burden. It states the tool lists archived zones but does not disclose pagination behavior, default/max limit, or response format. The claim 'all' could mislead an agent into thinking it returns every archived zone in one call, despite the limit/offset 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that immediately conveys the action and resource. It contains zero filler or redundant content, earning a top score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation, the description is minimally adequate: it states the purpose and the schema covers parameters. However, with no output schema and no annotations, the description leaves gaps about pagination semantics and return value shape, making it only partially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes both parameters: limit ('Max results to return (default 100, max 100)') and offset ('Pagination offset'). Since schema coverage is 100%, the baseline is 3, and the description adds no additional parameter context beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all archived VAST zones' uses a specific verb ('List'), identifies the resource ('archived VAST zones'), and the word 'all' signals unbounded scope. This clearly distinguishes it from siblings like vast_list_zones (non-archived zones) and list_archived_zones (non-VAST zones).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 vast_list_zones, vast_get_archived_zone, or vast_unarchive_zone. There are no explicit context cues or exclusions, so an agent gets no help in selecting among related zone tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full transparency burden. 'List all' implies a read-only operation returning all campaign assignments, but it does not disclose pagination behavior, default limit, or any filtering limitations. The simplicity of a list operation makes this acceptable, but there is no added context beyond what the name suggests.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise phrase, 'List all VAST campaign assignments'. Every word carries meaning with no superfluous text. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with only two optional parameters and no output schema, the description is marginally adequate. However, it lacks important context about the distinction between 'VAST' and non-VAST campaign assignments, potential return value contents, or any caveats about what 'all' means in practice. The high number of sibling tools with similar names increases the need for such context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add any parameter-specific semantics beyond what the schema already provides for 'limit' and 'offset'. It does not explain how pagination works or that 'limit' has a max of 100, but the schema covers those details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'List' and the resource 'VAST campaign assignments', with 'all' indicating scope. It distinguishes from the sibling 'list_campaign_assignments' by the 'VAST' prefix, though it doesn't explain what makes a campaign assignment 'VAST'. This is clear and specific, but not as rich as examples that add distinguishing constraints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 vast_get_campaign_assignment, vast_create_campaign_assignment, or the non-VAST list_campaign_assignments. There is no mention of use cases, exclusions, or relationship to sibling tools. The agent is left to infer based on 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?
With no annotations available, the description carries full burden for behavioral disclosure. It does not mention read-only status, pagination mechanics, default limits, or that 'all' may require multiple calls due to limit/offset. The description adds no value beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, 'List all VAST campaigns', front-loaded with the verb and resource, and contains zero wasted words. It is 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a straightforward list operation with documented parameters, but the lack of an output schema and absence of any context about return format, sorting, or pagination nuances makes it minimally complete. It does not mention behavior when no parameters are provided or relationship to other VAST entities.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with clear descriptions for limit and offset. The description adds no additional semantic meaning beyond what the schema already provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'list' and clearly identifies the resource as 'VAST campaigns', explicitly stating 'all' to indicate scope. This distinguishes it from sibling tools like list_campaigns (generic) and vast_list_campaign_assignments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 list_campaigns or vast42_list_ads. The description lacks context on prerequisites, exclusions, or when a different tool would be more appropriate, forcing the agent to infer 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 the full burden. It discloses only that this is a listing operation, but omits behavioral details such as pagination semantics (the 'all' claim vs. limit/offset defaults), sorting, or whether archived items are included. No contradiction, but minimal 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with zero wasted words. It conveys the essential purpose immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple listing tool, but it lacks qualifiers: 'List all' conflicts with the limit parameter defaulting to 100, and it does not distinguish from vast_list_media which may return a broader set. Given the minimal output schema, more context on pagination or coverage would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the two parameters, so the baseline of 3 applies. The description adds no additional context about limit/offset behavior, but the schema already documents them adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and resource ('VAST linear media'), clearly distinguishing from siblings like vast_list_non_linear_media. The word 'all' conveys scope, making the operation 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/5Does 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 vast_list_media or vast_list_non_linear_media. There is no mention of use cases, 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 responsibility for behavioral disclosure. It states the action but does not mention side effects, required permissions, reversibility, or what impact 'active status' has on campaign serving or related assignments. This lack of detail 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that conveys the essential purpose without any wasted words. It is front-loaded with the action and resource, making it immediately clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description covers the basic purpose. However, it does not explain return behavior, potential errors, or the post-condition of the campaign after unarchiving, which would be helpful for an agent to predict outcomes accurately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has full description coverage (100%) for the single 'id' parameter, which is described as 'Archived VAST campaign ID'. The tool description adds no additional parameter context, but the schema adequately conveys the meaning, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Restore') and the target resource ('archived VAST campaign') along with the intended outcome ('back to active status'). It is specific and unambiguous, but it does not explicitly differentiate from the sibling tool 'unarchive_campaign', relying on the 'VAST' prefix and description mention to imply the 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied by the description: use this when you want to reactivate an archived VAST campaign. However, it does not mention any prerequisites, such as the campaign must be archived first, nor does it provide alternatives or specify when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states a mutation but does not disclose behaviors such as whether it is a partial update, what happens if the ID does not exist, required permissions, or what the response contains. The description offers no additional behavioral context beyond the basic update action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short, front-loaded sentence with no redundant words. It is concise and easy to parse, though it could arguably include more detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a moderate schema (5 params, 1 required) and no output schema or annotations. The description is extremely brief and does not explain the update behavior, return value, or constraints. It provides only the bare minimum, leaving significant context gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with all five parameters documented in the schema. The description adds no parameter semantics, but the baseline of 3 applies since the schema already provides the necessary details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('update') and resource ('VAST linear media'), with 'existing' distinguishing it from create. It clearly differentiates from sibling tools like vast_create_linear_media, vast_list_linear_media, and vast_update_non_linear_media.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance—'existing' implies the resource must already exist, but there is no mention of when to use this versus other operations, no prerequisites beyond existence, and no alternatives. Usage is only implied 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 must convey behavioral traits. It states 'Update' indicating mutation, but does not disclose whether the update is partial or full replacement, whether fields can be cleared, or any side effects. This is a significant gap for a mutating tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It clearly conveys the core operation in six words, earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update operation with fully documented parameters, the description might suffice, but the absence of annotations and output schema leaves gaps about expected return values or failure conditions. Given the large sibling toolset, some additional context about the scope of updates would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (all four parameters have descriptions), so the schema already explains id, url, name, and event. The description adds no additional parameter semantics beyond implying 'existing' requires an id, which is already marked as required in the schema. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Update') and resource ('VAST tracking entry'), clearly distinguishing it from sibling tools like vast_create_tracking and vast_delete_tracking. It also implies the target exists, which separates it from creation 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives such as vast_create_tracking or vast_update_channel_zone_assignment. It only implies that the entry must already exist, but does not state prerequisites or scenarios where update 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 the full burden of disclosing behavior. It only states that sources are created; it doesn't disclose whether the operation is atomic, what happens on partial failure, rate limits, or what is returned. This is insufficient for a bulk 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that conveys the core purpose without unnecessary words. It is well-sized for a simple create operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema and annotations, the description is too sparse. It doesn't explain the return value, error handling, or the required fields within each source object, which are critical for a bulk create operation. The description is not complete enough for an agent to confidently invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters (publisher_id and sources) with 100% coverage. The description adds no additional parameter semantics, such as the structure of each source object or constraints on the array size.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (bulk create), the resource (product sources), and the context (for a publisher). The word 'bulk' distinguishes it from the sibling create_product_source tool, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The term 'bulk' implies this tool is for creating multiple product sources at once, but the description does not explicitly state when to use it over the sibling create_product_source, nor any prerequisites or limitations. The usage 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 must carry the full burden of behavioral disclosure. The description only states the action ('Bulk remove') without clarifying consequences, such as whether removal is permanent, what happens if entries are not found, whether the operation is idempotent, or how partial failures are handled. For a mutation tool with no annotation safety signals, this is insufficient transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words or fluff. It efficiently conveys the core purpose and action, earning a perfect score for conciseness and structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a mutation with no annotations, no output schema, and an optional 'data' parameter, the description lacks critical context. It does not explain what happens when 'data' is omitted (e.g., does it remove all entries?), nor does it mention expected return values, error handling, or prerequisites like requiring the data list to exist. The minimal description is not complete enough for an agent to invoke the tool correctly in all scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for both parameters (id: 'Data list ID', data: 'CSV data to remove'), giving 100% schema description coverage. The description does not add any additional meaning beyond what the schema provides; it merely restates the action on a 'data list.' Baseline of 3 is appropriate because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Bulk remove entries') and the resource ('a data list'), using a specific verb and scope. It distinguishes itself from sibling tools like delete_data_list (which deletes the entire list), bulk_upload_add_data_list (which adds entries), and bulk_upload_replace_data_list (which replaces entries). The name reinforces this distinction with 'remove' in the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the tool name and description: use when you need to remove multiple entries from an existing data list without deleting the list itself. However, the description does not explicitly state when to use this tool versus alternatives like delete_data_list or bulk_upload_replace_data_list, nor does it mention exclusions or prerequisites. No explicit guidance is provided 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 must disclose side effects. It does not specify whether the conversion mutates the existing item, creates a new item, or deletes the original. Critical behavioral details (like reversibility or impact on the native ad) are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler words. It is appropriately sized for a simple one-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and minimal description, the tool lacks essential context about what the conversion does to the original, whether it returns something, and any prerequisites. The one-liner is not enough to fully understand the operation's consequences.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes the only parameter 'id' as 'Native ad item ID', achieving 100% schema coverage. The description itself adds no extra parameter context, so a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Convert') and the resource transformation ('a native ad item to an image ad item'). It is specific and distinguishes this from sibling tools that merely create/update/get/delete native or image ad items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when converting a native ad to an image ad, but does not explicitly state when to prefer this over creating a new image ad item or provide any exclusions or alternative guidance. The purpose itself gives a hint of the scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It does not disclose side effects, permissions, duplicate handling, or response format. The phrase 'create a new audience' adds little beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is 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 action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too sparse for a tool with nested objects and no output schema. It fails to explain the relationship between the audience and user_db_id, the requirement to reference an existing user database, or what the response will be.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add parameter-level meaning, but the schema already provides clear descriptions, including an example for the 'attributes' object.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create), the resource (audience), and the context (user database). It distinguishes from sibling tools like get_audience, update_audience, and delete_audience by specifying a create 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (use to create a new audience) but does not provide when-to-use vs alternatives, prerequisites, or exclusions. No comparison to related tools such as create_data_list or create_user_db.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the multipart file upload mechanism, which is a useful behavioral trait. However, with no annotations providing additional context, it does not cover other important aspects like permissions, side effects, or the fact that the audio file itself is not reflected in the input 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences. The purpose is front-loaded, and the multipart upload note is valuable without adding unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is incomplete for a tool with no annotations and no output schema. It does not clarify how to provide the actual audio file (especially since the schema lacks a file parameter), nor does it mention response structure or any additional prerequisites beyond the required group.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage of parameter descriptions (name, group, description). The tool description does not add further parameter-specific meaning, but it does hint at the multipart file upload, which may compensate for the missing file parameter in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new audio creative' with a specific verb and resource type. This distinguishes it from sibling tools like create_creative and create_video_creative by specifying the audio creative 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/5Does 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 indicates only what the tool does, not when to choose it over similar creation tools like create_video_creative or generic create_creative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden for behavioral disclosure. It does not mention permissions, whether this is a final vs. draft creation, side effects, or that it requires an existing native template. This is a minimal statement 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the verb and object. Every word earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 10 parameters, nested objects, no output schema, and a sibling draft variant, this description is too minimal. It lacks prerequisites (e.g., template must exist), variable matching expectations, and any context about how it fits into the ad item workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with detailed descriptions for all parameters, so the baseline is 3. The description's 'using a native template' adds no new parameter semantics beyond what the schema already states for the template field.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Create' with a clear direct object 'new native ad item' and specifies the mechanism 'using a native template'. This distinguishes it from sibling tools like update_native_ad_item or draft_create_native_ad_item, which are clearly different 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'using a native template' implies this is the template-based creation path, but there is no explicit guidance on when to choose this over draft_create_native_ad_item or other create variants. No alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states 'Create a new image asset' without disclosing any behavioral traits such as required permissions, whether existing assets can be overwritten, what happens on failure, or what the response contains. For a mutation tool with no annotations, 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that is front-loaded with the verb and resource. It is appropriately sized for a simple create tool and contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, no annotations, and six parameters. The description fails to mention what the tool returns (e.g., the created asset ID), any prerequisites (e.g., the template must exist), or how the parameters semantically relate to an image asset. This is incomplete for an agent to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all six parameters. The description adds little meaning beyond confirming template_id is the ORTB native template ID. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create'), the resource ('image asset'), and the context ('for an ORTB native template'). It distinguishes this from sibling tools like create_ortb_native_title_asset and create_ortb_native_data_asset by specifying 'image'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: create a new image asset for a template. It doesn't explicitly mention when to use this versus update/delete/list operations, nor does it state prerequisites like the template must exist. Context is clear but no exclusions or alternatives are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must disclose behavior. It adds the meaningful detail that schedules are automatically linked to ad items via placements, which goes beyond a simple create operation. However, it does not mention mutation, idempotency, or response behavior, so it 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and immediately states the core purpose. It is front-loaded and contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 15 parameters and no output schema, this brief description leaves operational questions unanswered, such as how placements are used, whether a placement must be pre-created, and what success returns. The automatic linking fact is helpful but insufficient for a complex creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already describes all 15 parameters. The description adds nothing about parameter semantics beyond the high-level time-based delivery context, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a schedule for time-based ad delivery, using a specific verb and resource. The additional sentence about automatic linking to ad items via placements provides scope and distinguishes it from generic schedule handling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided about when to use this tool versus siblings like vast_create_schedule or draft_create_schedule. The only contextual hint is the placement linking, but it does not explain 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 the full burden but only adds one behavioral detail: 'The API uses multipart file upload.' This is useful but incomplete; it does not disclose permissions, response behavior, or the notable mismatch that no file parameter appears in the input schema. The description is not misleading but has clear transparency 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. The main action is front-loaded, and the multipart note is a valuable addition that justifies its place. Every word earns its keep.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is too sparse. It does not explain what a video creative is, what creating it entails, how the group relates to media groups, or what the response contains. The multipart upload mention actually raises questions because the schema lacks a file parameter, leaving the agent without enough context to invoke the tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and each parameter (name, group, description) already has a clear description. The tool description adds no extra meaning to these parameters and does not compensate for the missing file parameter implied by the multipart note, though the baseline for high coverage is appropriately 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new video creative' with a specific verb and resource, distinguishing it from sibling tools like create_audio_creative or create_rich_media_creative. The mention of 'video' and the multipart upload detail further differentiate it from generic creative 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 Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like create_creative or create_rich_media_creative. It does not mention prerequisites, exclusions, or situations where another tool would be more appropriate, leaving the agent to rely solely on 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 the full burden of behavioral disclosure. It merely restates the action ('Delete a standard campaign') without mentioning consequences such as reversibility, cascading deletions, authorization needs, or whether this is a hard or soft delete. The description adds no value beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single terse sentence with no filler or redundant clauses. It is front-loaded and appropriately sized for a simple deletion operation, though it borders on under-specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and many related campaign-deletion sibling tools, the description is too thin. It does not clarify what 'standard' means, whether archived campaigns are excluded, or any side effects, making it insufficient for safe and correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents the `id` parameter as 'Campaign ID' with 100% coverage. The description does not add any additional meaning or context for the parameter, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description uses the specific verb 'delete' with resource 'standard campaign', and the qualifier 'standard' distinguishes it from sibling tools like delete_archived_campaign, vast_delete_campaign, and draft_delete_campaign. It clearly states the tool's function and scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The word 'standard' implies this is for regular (non-archived) campaigns rather than archived or specialized (vast/draft) ones, but no explicit guidance is given about when to use this tool over alternatives. It lacks clear context or exclusions beyond the implied meaning of 'standard'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It merely states 'Delete a media group' without mentioning side effects, irreversibility, permissions, or cascading consequences, which is a significant gap 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that communicates the core functionality without wasteful words. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description is too minimal for a destructive tool. It omits important context such as permanence of deletion, associated data impact, or any required conditions, making it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the 'id' parameter described as 'Media group ID'. The description adds no additional parameter details, warranting the baseline score of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Delete' and resource 'media group', which clearly distinguishes it from sibling tools like get_media_group, create_media_group, and update_media_group. The intent is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does 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, but the delete action is implied by the name. No prerequisites, exclusions, or alternative recommendations 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, the description carries the full burden of behavioral disclosure. It mentions the draft nature but omits important details such as whether the draft is immutable, what validation is performed, or what the response contains. The description is too sparse 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the action and resource. Every word earns its place, and there is no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a nested object parameter with no specified subfields, no output schema, and no annotations. The description does not explain what 'standard campaign fields' are, how the draft relates to other draft operations, or what happens after creation. This is a significant gap for an agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description covers the single parameter at 100% ('Object containing standard campaign fields'), and the tool description only restates this by saying fields go inside a 'draft' wrapper. No new meaning is added beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and resource ('new draft standard campaign'), clearly distinguishing it from create_campaign and other draft-related tools. It immediately clarifies that this is for creating a draft, not a live campaign.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through the word 'draft' but does not explicitly state when to use this tool versus alternatives like create_campaign or draft_save_campaign. It lacks guidance on prerequisites or exclusions, leaving the agent to infer context from the 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 the full burden of behavioral disclosure. It only states the operation and scope, without mentioning security implications (e.g., whether the key secret is exposed), permission requirements, or response characteristics such as pagination or field completeness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the verb and object, containing no filler or irrelevant information. It is exactly as concise as needed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description is insufficient: 'details' is vague and does not specify what fields are returned, whether the response includes sensitive key material, or any prerequisites beyond the ID. This is a minimal get-by-ID tool that could benefit from a phrase describing the response shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes the parameter 'id' as 'Beacon signing key ID' with 100% coverage. The description's 'by ID' adds no semantic detail beyond what the schema provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' and identifies the resource as 'beacon signing key' with the scope 'by ID', clearly distinguishing it from sibling CRUD operations like list, create, update, delete, and validate. It unambiguously states 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by ID' implies this tool is for fetching a single key when the ID is known, but it does not explicitly mention alternatives or when to use this versus list/create/update/delete. There is no direct guidance such as 'use list_beacon_signing_keys to find all keys'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only says 'Get details' without disclosing response format, error conditions, archival status, or any other behavioral traits. This is minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short, front-loaded sentence with no filler. While it closely mirrors the tool name, it is appropriately sized for such a simple getter operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with one parameter and no output schema, this is minimally adequate for selection and basic invocation. However, it does not explain what 'details' includes, the entity's meaning, or any related context, leaving gaps for an agent unfamiliar with the domain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes the single parameter 'id' as 'Channel zone assignment ID'. The description adds no extra meaning beyond the schema, so the baseline of 3 applies due to high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (get) and the resource (channel zone assignment), and 'a specific' implies fetching a single entity by ID. This distinguishes it from sibling list operations like list_channel_zone_assignments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The word 'specific' implies use for a single assignment when you have an ID, contrasting with list tools, but no explicit alternatives or exclusions are named. Usage is only implied, not clearly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It does not mention any side effects, authentication requirements, rate limits, or return format. The read-only nature is implied by 'Get' but not explicitly stated, and no additional safety or behavioral context is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the verb and resource. It contains no unnecessary words or filler, making it appropriately sized for the tool's simple purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with one well-documented parameter and no output schema, the description sufficiently explains what the tool returns (a conversion tracking tag). The complexity is low, and no additional context is needed beyond what is already in the name and schema. Missing details like the exact response format are not critical for this straightforward operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage for the single parameter 'id' with description 'Ad item ID'. The tool description adds little beyond clarifying the resource type is 'custom HTML ad item', but this is already evident from the tool name. The schema already documents the parameter, so the description does not need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get conversion tracking tag for a custom HTML ad item' clearly specifies the verb (Get) and resource (conversion tracking tag for a custom HTML ad item), and it distinguishes from sibling tools like get_custom_html_ad_item (which gets the item itself) and get_image_ad_item_conversion_tag (different ad item 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/5Does 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 only states what it does, with no mention of prerequisites, exclusions, or alternative tools, leaving the agent to infer usage solely from the 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 disclosure burden. It only states 'Get details' with no mention of permissions, error handling, return format, or side effects. The read-only nature is implied but not explicitly detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler. Every word contributes to clarity, 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.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one required parameter, no output schema), the description is mostly complete. It communicates the core purpose, though it omits return value details which could be expected with no output schema present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the 'id' parameter described as 'Ad item ID'. The description adds no additional parameter semantics beyond the schema, which is the baseline expectation for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get details of a specific native ad item' uses a specific verb+resource construction, clearly distinguishing it from related getter tools like conversion tag getters or draft versions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 draft_get_native_ad_item, get_native_ad_item_conversion_tag, or list_native_ad_items. The description implies usage for retrieving a specific item but offers no exclusions or comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the purpose ('Get details') without confirming read-only behavior, error handling, authorization needs, or response format. No additional behavioral traits are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It efficiently captures the tool's purpose without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get tool with two well-documented parameters and no output schema, the description is adequate. It doesn't explain return values, but the 'Get details' phrasing implies the response contains the asset details. Slightly more detail could improve completeness, but it's sufficient for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (both id and template_id have descriptions in the schema). The description adds no extra parameter semantics, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get details' with a clear resource 'title asset' and a qualifier 'for an ORTB native template'. This distinguishes it from sibling tools like get_ortb_native_image_asset, get_ortb_native_data_asset, and list/create/update variants.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternative guidance is provided. The description does not mention that list_ortb_native_title_assets should be used for listing, nor does it explain when to prefer this over the image or data asset equivalents. The usage context is only implied by the 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 the full burden. It only says 'Get details' and adds no context about return format, error behavior, permissions, or rate limits. Unlike a tool with annotations that at least establish read-only safety, this minimalist description provides no behavioral disclosures beyond the action itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence of eight words, front-loaded with the action and resource. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description should clarify what 'details' are returned, but it does not. Also, the three required parameters (publisher_id, catalog_id, identifier) are not explained in terms of their relationship or why all are needed. This is insufficient for a tool in a complex domain with many related entities.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter having a basic description ('Catalog ID', 'Unique identifier for the catalog item', 'Publisher ID'). The tool description adds no additional meaning beyond what the schema already provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get details of a specific product catalog item' uses a specific verb ('Get') and resource ('product catalog item') with a clear scope ('specific'), distinguishing it from sibling tools like 'list_product_catalogs' and 'search_product_catalog_items'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives such as 'get_product_catalog' or 'search_product_catalog_items'. The usage is implied (when you have the identifier for a single item), but no exclusions or alternative conditions 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?
No annotations are present, so the description must carry the behavioral disclosure burden. It only states the basic purpose and offers no additional context such as return format, pagination behavior, or potential side effects, making it insufficient for 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that directly conveys the operation without any redundant words or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a tool with no output schema and no annotations, the description is sparse. It doesn't explain what the returned list contains, whether pagination is required, or any other operational details, leaving gaps for an agent to interpret.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents both limit and offset with descriptions, and schema coverage is 100%. The description adds no parameter-specific semantics, so it meets the baseline for schema-covered parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (List), the resource (archived standard zones), and the scope (all), effectively distinguishing it from sibling tools like list_zones (active zones) and list_archived_email_zones (different zone 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving archived standard zones, but it doesn't explicitly state when to use it over alternatives like list_zones or list_archived_advertisers. No explicit exclusions or preferred 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?
No annotations are provided, so the description carries the full burden. It does not disclose read-only nature, pagination behavior, scoping, or return format. The one-line description leaves major behavioral traits unaddressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no unnecessary words. It is appropriately concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with two well-documented pagination parameters, the description is adequate. It could note whether 'all' is scoped to an account, but the tool's simplicity and complete schema make it reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both limit and offset, so the description adds no additional parameter meaning. This matches the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the specific resource ('event log upload configurations'). This distinguishes it from sibling tools like get_event_log_upload_config, create_event_log_upload_config, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 simply states the action without mentioning use cases, exclusions, or relationship to get_event_log_upload_config.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior, but it only states 'List all image assets'. It does not mention that pagination is required to truly list all (default limit 100, max 100), nor does it describe the return structure or ordering. The word 'all' is potentially misleading given the limit/offset parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words, front-loading the main action and resource. It is appropriately sized for a simple list tool, though it is slightly terse given the missing pagination behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with fully schema-documented parameters, the description provides the essential purpose. However, with no output schema and no annotations, it does not explain the return format, pagination semantics, or how 'all' relates to limit/offset, leaving some contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (template_id, limit, offset all documented). The description adds no additional parameter semantics beyond the template scoping, so the baseline of 3 applies since the schema already carries parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') with a clear resource ('image assets') and scope ('for an ORTB native template'). It distinguishes itself from sibling tools like get_ortb_native_image_asset (single asset) and list_ortb_native_title_assets (different asset 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The context 'for an ORTB native template' implies this is the list operation scoped to a template, but it does not explicitly state when to use this over get_ortb_native_image_asset or mention pagination behavior with limit/offset. Usage guidance is implied rather than 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 must carry the burden of behavioral disclosure. It merely states 'Update an existing PMP deal' without explaining whether this is a partial update (PATCH-like) or full replacement (PUT-like), what happens with unspecified optional fields, or any side effects. This adds no behavioral context beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler words. It is appropriately concise and front-loaded with the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters, no output schema, and no annotations, the description is too sparse. It does not explain partial vs full update semantics, what the response looks like, or any constraints on updating geo/audience targets. The schema picks up some slack, but the description should provide more operational context for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline of 3 applies. The description adds no parameter semantics beyond what the schema already provides; it does not mention that only id is required or how the optional fields are applied.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 (existing PMP deal), distinguishing it from sibling tools like create_pmp_deal, delete_pmp_deal, and list_pmp_deals. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool vs alternatives. The usage is implied by the tool name and sibling context (create vs update vs delete), but the description does not state prerequisites, when not to use, or contrast with create_pmp_deal.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 should carry the full transparency burden. However, it only states that it retrieves details without disclosing potential error conditions, required permissions, or the exact structure of the returned object, leaving the agent to assume standard GET 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the action and resource. It avoids unnecessary words and clearly communicates the tool's purpose, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with one parameter, the description covers the essential operation and is reasonably complete given the absence of an output schema. The phrase 'Get details' implies the return value, but slightly more specificity about the returned data would make it fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully documents the single 'id' parameter with a clear description ('VAST campaign assignment ID'), achieving 100% schema coverage. Since the tool description adds no additional parameter semantics beyond what the schema provides, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get details' and identifies the resource 'specific VAST campaign assignment', clearly distinguishing it from list/create/update/delete sibling tools. It accurately conveys what the tool does without 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/5Does 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 over alternatives like vast_list_campaign_assignments or the draft variants. It only states the operation itself and does not mention any exclusions or alternative tool names, leaving the agent to infer usage from the general purpose.
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. The verb 'Get' implies read-only behavior, but the description adds no further behavioral context such as authentication requirements, potential errors, or side effects. It is minimally adequate for a simple read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, complete sentence with no wasted words, front-loading the verb and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter getter, the description is sufficient to convey core purpose. It lacks details about the return structure, but given the low complexity and full schema coverage, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema documents the only parameter 'id' with a clear description ('VAST non-linear media ID'), achieving 100% schema description coverage. The description adds no additional parameter details, but the schema fully covers parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('VAST non-linear media'), clearly indicating the tool retrieves details for a single non-linear media item. However, it does not differentiate from the similar sibling tool 'vast42_get_non_linear', so it earns a 4 rather than 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no information about when to use this tool versus alternatives like 'vast_list_non_linear_media' or 'vast42_get_non_linear'. There are no usage conditions, exclusions, or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of disclosing behavior. It only states 'List all VAST placements', which implies a read operation, but it does not mention pagination (limit/offset defaults), potential size of results, or any other behavioral traits. The schema documents parameters, but the description adds no extra context about how the listing 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly crafted sentence with no filler. It front-loads the action ('List') and resource ('VAST placements'), followed by a concise definition in parentheses. Every element serves a purpose, 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.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with two optional parameters and no output schema, the description adequately states what the tool does. It does not explain return values (no output schema exists) but gives the core purpose. Lacking annotations and with sibling tools like draft_list_placements, a brief note on pagination or the 'all' scope would improve completeness, but the current state is sufficient for a low-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: both 'limit' and 'offset' have descriptions in the input schema. The tool description adds no additional parameter semantics, but the baseline of 3 applies when the schema fully covers parameters. The description's 'List all' could conflict with the limit/offset defaulting, but the schema clarifies defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and clearly identifies the resource as 'VAST placements', with a parenthetical definition ('assignments of VAST ad items to VAST zones'). This distinguishes it from related tools like vast_get_placement (single fetch) and vast_create_placement (creation), and the 'VAST' prefix disambiguates from the non-prefixed 'list_placements'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that it lists all placements, nor does it direct users to vast_get_placement for a single placement or to list_placements (non-VAST) when appropriate. With many sibling list tools, the lack of explicit exclusions or alternatives leaves the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 says 'update an existing VAST campaign' without revealing whether updates are partial or full replacement, whether the tool returns the updated object, or any side effects. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that immediately conveys the operation. It is front-loaded and contains no unnecessary words, 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.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description should clarify update semantics (e.g., partial vs. full update) and what the response contains. It does neither, leaving the agent uncertain about the tool's behavior beyond the basic action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents each parameter (id, name, contract, advertiser). The description adds no extra parameter-level context beyond what the schema provides, earning the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Update' and the resource 'VAST campaign', distinguishing it from sibling tools like vast_create_campaign, vast_get_campaign, and vast_delete_campaign. The prefix 'VAST' disambiguates from the generic update_campaign tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: you use this tool when you have an existing VAST campaign ID and want to modify its fields. However, it provides no explicit guidance on when not to use it, such as pointing to vast_update_campaign_assignment for assignment changes or vast_create_campaign for new campaigns.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description labels destructive action without disclosing irreversibility, partial failure behavior, or permission requirements. For a bulk delete operation, 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, zero redundancy. Every word contributes to meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with fully described params, but missing details on return value, atomicity, and error handling for invalid IDs. No output schema exists, so description should provide more operational context for a destructive bulk operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage, so baseline 3 applies. The description adds no additional meaning beyond schema fields, and the schema already documents items array and campaign_id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Bulk delete' and resource 'catalog ad items from a campaign', clearly distinguishing from sibling campaign_bulk_create_catalog_ad_items and single delete_catalog_ad_item. The scope 'from a campaign' is precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The word 'bulk' implies use for multiple items, but no explicit guidance on when to use this over single delete_catalog_ad_item or draft_delete_catalog_ad_item. No exclusions or alternatives named.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 'Create a new bidder' and does not disclose side effects (e.g., persistence), required permissions, validation rules, or what happens on success or failure. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the verb and object. It contains no wasted words and is immediately understandable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create tool with three well-described parameters, the description meets the minimum viable standard. However, it lacks behavioral context (e.g., defaults, required permissions, response format) because there are no annotations and no output schema, leaving the agent with only the schema and description to work with.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for name, status, and bid_url, so the description does not need to add parameter details. However, the description provides no additional meaning beyond the schema, which is sufficient per the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new bidder' clearly states the action (create) and the resource (bidder), making it distinct from sibling tools like update_bidder or delete_bidder. It is a specific verb+resource statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied by the verb 'create' and the resource 'bidder', but there is no explicit guidance on when to use this tool versus alternatives, nor any mention of prerequisites. It does not state exclusions or when to avoid using it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Create a new payment' without disclosing any side effects, such as whether the payment updates contract balances, whether the contract must exist, or what the response contains. This is minimal and lacks contextual behavior beyond the obvious write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear, and concise sentence. It contains no unnecessary words or filler and immediately conveys the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple CRUD create operation with fully documented parameters, the description is minimally adequate. However, it lacks any mention of return behavior, side effects, or prerequisites, and there are no annotations or output schema to fill these gaps. It is sufficient for a basic tool but not richly contextual.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage of parameter descriptions (contract_id, amount, note), so the baseline is 3. The description adds no extra semantic information beyond what the schema already offers, but it does not need to compensate for any gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create) and the resource (payment for a contract). It unambiguously distinguishes itself from sibling tools like list_contract_payments, get_contract_payment, and delete_contract_payment, which represent different operations on the same resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternatives are mentioned. The intended use is implied by the tool name and description: use when adding a new payment to a contract. However, there is no guidance about prerequisites, such as the contract existing or when this should be used over other payment-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full behavioral transparency. It only states 'Create,' which implies mutation, but does not disclose side effects, permissions, reversibility, or what the response contains. The added explanation of ranges format is parameter semantics rather than 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the purpose, and includes only relevant details. No fluff or repetition, 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a straightforward create operation with all 4 parameters fully documented in the schema. However, without an output schema, the description does not mention return values or success behavior. It also lacks any usage prerequisites or side-effect disclosures, making it adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds an example for ranges ('09:00:00-17:00:00') which is helpful but largely redundant with the schema. It does not add significant meaning beyond the schema for the other three parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Create a new day parting rule for time-of-day targeting,' which uses a specific verb and resource. It clearly distinguishes from sibling tools like update_day_parting, list_day_partings, and delete_day_parting by focusing on creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for creating a new day parting rule, but does not explicitly state when to use it versus alternatives (e.g., update_day_parting for modifications). No when-not-to-use guidance is provided, but the intent is clear from the verb 'Create'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only states the basic create operation, with no information about required permissions, validation of publisher_id, idempotency, or response behavior. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no unnecessary words. It conveys the essential purpose efficiently, earning a high score for conciseness and structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple with two parameters fully documented in the schema. However, with no annotations and no output schema, the description does not provide details about return values, prerequisites, or edge cases. It is minimally complete for a create operation but lacks contextual richness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (both parameters have descriptions). The description adds minimal value beyond the schema, only reinforcing that publisher_id identifies the publisher. Since the schema already documents the parameters, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create', the resource 'product catalog', and the scope 'for a publisher'. It effectively distinguishes itself from sibling tools like list_product_catalogs, get_product_catalog, and update_product_catalog by specifying the action (create) and the target (new catalog for a publisher).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The verb 'Create' implies this is for new product catalogs only, but the description does not explicitly provide when-to-use guidance or mention alternatives like update_product_catalog for existing catalogs. The usage context is implied rather than stated, leaving room for confusion among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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, yet it only states the action without mentioning potential side effects, idempotency, validation, or any domain rules. It provides no additional behavioral context beyond the obvious creation 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words. It is appropriately sized for a tool with one parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal but adequate for a simple create operation with a fully documented parameter. However, it lacks broader context about what trusted redirect domains are used for, what constitutes a valid domain, or any operational constraints. Given no annotations or output schema, the description does not fully cover the tool's context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already fully documents the 'domain' parameter with an example. The description adds no extra semantic information beyond what the schema provides, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and resource ('trusted redirect domain'), clearly distinguishing it from sibling tools like list/get/update/delete. It states exactly 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the CRUD pattern and the tool's name, but there is no explicit guidance on when to use it versus alternatives, nor any prerequisites or exclusions. The sibling tools suggest this is the create operation, so the context is somewhat clear 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral disclosure burden. It explains the constraint that dynamic zones require width/height to be 0, which is a useful behavioral trait, but this information also appears in the schema. The description does not mention permissions, return values, or side effects of creation, leaving gaps in the behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences, front-loading the primary action ('Create a new standard zone') and then addressing the key dimension-setting decision. Every clause earns its place; there is no fluff or repetition, and the structure is clean and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex 27-parameter create operation with no output schema and no annotations. The description covers the most important distinction (fixed vs dynamic) but does not mention that 'name' is the only required field, nor what the created zone object looks like in the response. Given the schema's detailed parameter documentation and the tool's relatively high complexity, the description is minimally adequate but incomplete for full orientation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides descriptions for 100% of the 27 parameters, so the baseline is 3. The tool description adds the explicit default for 'dimensions' ('fixed') and reiterates the width/height constraint, but it does not add meaning beyond what the schema already documents for other parameters. Overall, the schema does the heavy lifting, and the description adds little extra semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new standard zone' — a specific verb and resource — and distinguishes this tool from other zone types (email, catalog, vast) by using the qualifier 'standard'. It also highlights the fixed/dynamic dimension modes, which is a key feature of standard zones. However, it does not explicitly name alternative tools as seen in high-scoring examples.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives implicit usage context by referring to 'standard zone', implying this is not for email or catalog zones. It does not explicitly state when to use this tool over alternatives or exclude other zone types. However, it does provide guidance on setting dimensions to 'dynamic' vs 'fixed', which is a contextual usage instruction, though it is parameter-focused rather than tool-selection-focused.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 for behavioral disclosure. It only states 'Delete' without mentioning irreversibility, cascading effects, required permissions, or any confirmation mechanism. For a destructive tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with two well-documented parameters and no output schema, the description is minimally adequate. It clarifies the basic purpose but lacks context about deletion consequences, which is important for a destructive operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% parameter description coverage for both 'id' and 'user_db_id'. The description adds no additional parameter semantics, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the direct verb 'Delete' with the specific resource 'audience' and container 'user database', clearly distinguishing this tool from get_audience, update_audience, and list_audiences 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use or alternative guidance, but the operation is self-evident. It lacks any prerequisites or caveats about when deletion is appropriate or what happens if the audience is in 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, and the description only says 'Delete an image creative.' It does not disclose whether the deletion is permanent, whether it affects associated campaigns or files, whether special permissions are required, or any other consequences. For a destructive operation, this is a significant transparency 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words or irrelevant details. Every word contributes to the meaning, making it an efficient and well-structured statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a very simple tool with one fully documented parameter and no output schema. The description is adequate for identifying the operation, but it omits any mention of side effects, irreversibility, or dependencies. For a delete action, this absence of safety-related info makes it minimally complete rather than comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes the single parameter 'id' with the description 'Creative ID' (100% coverage). The tool description adds no additional meaning beyond confirming the resource type, so it meets the baseline of 3 without exceeding it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Delete') and identifies the exact resource type ('image creative'), which clearly distinguishes it from sibling tools like delete_video_creative, delete_rich_media_creative, and delete_audio_creative. It leaves no ambiguity about what operation is performed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The word 'image' implies this tool is for deleting image creatives only, but the description does not explicitly state when to use it over alternatives or mention the other creative-type deletion tools. Usage context is implied rather than stated, so it gets a 3.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description simply restates the action 'Delete a data asset' without disclosing behavioral traits such as irreversibility, cascading effects, permissions, or error conditions. It adds no information beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that clearly states the action and object. Every word earns its place with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with two required parameters and no output schema, the description provides the core information. However, it lacks context about side effects, permanence, or required permissions, which are important for a destructive operation with no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters with descriptions (id as 'Data asset ID' and template_id as 'ORTB native template ID'), achieving 100% schema coverage. The description adds no additional parameter semantics, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Delete' and identifies the resource 'data asset' and its container 'ORTB native template'. This clearly distinguishes it from sibling tools like delete_ortb_native_image_asset and delete_ortb_native_title_asset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for deleting a data asset from an ORTB native template but provides no explicit when-to-use or when-not-to-use guidance, nor does it reference alternatives. An agent must infer the intended use from the asset type and 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, the description carries the full burden of behavioral disclosure. It only states the action without indicating that deletion is permanent, whether there are cascading effects, or if special permissions are required. While the verb 'delete' implies a destructive action, no additional context is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence of five words, front-loaded with the action verb. Every word is meaningful, and there is no redundant information or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (1 parameter, no output schema), and the description is minimally adequate. However, it does not differentiate this from the sibling delete_native_template, nor does it mention that deletion is irreversible or that IDs can be retrieved via list_ortb_native_templates. These are notable gaps for an agent selecting among similar delete tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents the single `id` parameter with a clear description ('ORTB native template ID'), achieving 100% schema coverage. The tool description adds no extra parameter semantics, so it does not improve upon the schema, but the baseline of 3 is appropriate given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Delete' and names the exact resource 'OpenRTB native template', clearly distinguishing it from sibling tools like delete_native_template or delete_zone_ortb_native_ad. It is unambiguous and immediately 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit usage guidance is provided. The description implies that this tool is for deleting an OpenRTB native template, but it does not mention prerequisites, how to obtain the ID, or when to prefer this over the similar delete_native_template tool. This is a minimal viable level of 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?
With no annotations, the description carries the full burden of behavioral disclosure. It mentions 'Delete' but does not disclose whether deletion is permanent, what permissions are required, or any cascading effects on the ORTB native template. This lack of context is a significant gap 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action and resource, and contains no filler or redundant information. It is perfectly concise for its purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only two parameters and no output schema, so the description is mostly adequate. However, it omits important context for a delete operation, such as irreversibility or prerequisites, leaving some gaps given the absence of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters ('id' and 'template_id') have descriptive names and descriptions. The tool description adds no additional meaning beyond what the schema already provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Delete' and clearly identifies the resource as 'a title asset from an ORTB native template'. It distinguishes from sibling tools like delete_ortb_native_image_asset and delete_ortb_native_template by naming the exact asset 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states what the tool does but gives no explicit guidance on when to use it versus alternatives. There are no exclusions or hints about which sibling delete tools to prefer in different scenarios. Usage is implied rather than 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 'Delete' but offers no information about permanence, cascading effects, required permissions, or success/failure behavior. For a destructive operation, this is a meaningful 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that front-loads the verb and scope with no unnecessary words. It is appropriately sized for the simple operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with two well-described parameters, the description is adequate. However, there is no output schema, and the description does not mention the result of deletion or any prerequisites. The lack of safety context (irreversibility, side effects) makes it incomplete for a destructive tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both id and zone_id already described in the schema. The description adds no additional semantic value beyond what the schema provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (Delete), resource (ORTB native ad), and scope (from a standard zone). This distinguishes it from sibling tools like delete_ortb_native_image_asset or delete_ortb_native_title_asset, which delete other asset types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the action and scope, but there is no explicit guidance about when to choose this over update_zone_ortb_native_ad or when deletion is appropriate. No alternatives or exclusionary conditions 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It simply states the delete action without mentioning permanence, side effects, permissions, or reversibility, which is a significant gap 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the action and resource. 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema, so a brief description might suffice. However, the lack of annotations and the presence of many sibling tools leave gaps: no mention of response behavior, irreversible deletion, or how this fits into the draft workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% since the 'id' parameter includes the description 'Draft ad item ID'. The tool description adds no additional parameter information, but per the rubric, a baseline of 3 is appropriate when schema covers all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a draft custom HTML ad item' uses a specific verb (delete) and identifies the exact resource (draft custom HTML ad item), distinguishing it from sibling tools like 'delete_custom_html_ad_item' which targets non-draft items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the word 'draft', indicating this tool is for deleting items in draft status. However, no explicit guidance is given about when to use this over the non-draft delete tool or other related 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 only states 'Get details' and gives no information about read-only behavior, authentication requirements, potential error responses, or what is actually returned. For a simple get, this is a notable gap despite the implied safety of a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that immediately communicates the tool's purpose. There is no redundant or extraneous information, achieving high conciseness and clear front-loading of the core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema), but the description could be more complete by explicitly stating the return value (e.g., 'Returns the full draft campaign assignment object') or noting any draft-specific behavior. It is minimally adequate but leaves gaps in understanding what 'details' entails.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'id' is fully described in the schema as 'Draft campaign assignment ID', giving 100% schema coverage. The description adds no additional parameter context beyond what the schema already states, warranting the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get details of a specific draft campaign assignment' clearly states the verb (get), resource (draft campaign assignment), and singularity (specific). This distinguishes it from siblings like draft_list_campaign_assignments (which lists) and draft_get_campaign (different resource), and the 'draft' prefix differentiates it from non-draft variants.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the verb and resource: use this when you need a single draft campaign assignment by its ID. However, there is no explicit guidance on when to choose this over alternatives, such as draft_list_campaign_assignments, or mention of any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states 'List all draft ad items across all types' without mentioning pagination behavior, return format, or whether this includes all statuses or only drafts. The verb 'List' implies read-only, but the description adds minimal context beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the action and resource. There is no extraneous information, and every word adds value. It is 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a straightforward list operation with well-documented parameters and no output schema, the description is minimally adequate. It clearly communicates the core purpose and scope, but it does not provide additional context about what 'draft' entails, whether this returns only active drafts, or how results are ordered. This is a gap, but not a severe one for such a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage for the two parameters (limit and offset), each with a description. The tool description does not add any parameter-level detail, but since the schema already documents them, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('List'), a resource ('draft ad items'), and a scope ('across all types'). This differentiates it from sibling tools like draft_list_image_ad_items or draft_list_rich_media_ad_items, which are type-specific. The purpose is unambiguous and immediately understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used to retrieve all draft ad items regardless of type, but does not explicitly state when to choose this tool over the many type-specific draft list siblings (e.g., draft_list_image_ad_items). There is no mention of alternatives or exclusion criteria, so guidance is only 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, the description carries the full burden. It clearly states the scope (draft standard campaigns) but does not disclose potential behavioral traits such as pagination behavior, ordering, or that the operation is read-only. The limit/offset parameters imply pagination, but this is not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, telegraphic sentence that starts with the verb and conveys the entire scope. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The lack of an output schema and annotations means the description must carry more context. While it is adequate for a simple list operation, it could benefit from a note on what constitutes a 'standard' campaign or how it differs from list_campaigns. It is minimally complete but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters (limit and offset) have complete descriptions in the schema, so the description adds no additional parameter semantics beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all draft standard campaigns' clearly states a specific verb ('List') and resource ('draft standard campaigns'), distinguishing it from sibling tools like list_campaigns and vast_list_campaigns. It precisely indicates the scope (draft status and standard 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving draft standard campaigns, but it does not explicitly mention alternatives or when to choose this over list_campaigns or list_all_campaigns. It lacks 'use this when' or 'instead of' 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. While it discloses the main effect (draft to live conversion), it omits crucial behavioral details such as reversibility, required permissions, what happens if the ID is already live, or any side effects. For a mutation tool that changes campaign status, 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence: 'Save/publish a draft campaign (converts draft to live campaign)'. It is concise, front-loaded with the action, and contains no unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema), so the description covers the core action. However, as a publish/mutation operation with no annotations, it lacks context about the consequences and error behavior. The description is adequate but not fully complete for an agent to understand the full impact.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for the single parameter 'id' with description 'Draft campaign ID'. The tool description adds minimal extra meaning beyond saying it's for a draft campaign, which matches the schema. With high schema coverage, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Save/publish a draft campaign' and explicitly explains the outcome: 'converts draft to live campaign'. This distinguishes it from sibling tools like draft_create_campaign, draft_update_campaign, and draft_delete_campaign, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the primary use case: for draft campaigns that should be converted to live status. However, it does not explicitly state when to use this tool versus alternatives (e.g., draft_update_campaign for editing drafts, or create_campaign for creating a live campaign directly), nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It only states that tags are generated for multiple zones, but does not mention what the output looks like, whether it is a read-only operation, any limits on zone_ids, or potential side effects. This is a significant gap for a tool with no annotation safety signals.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler: 'Generate ad serving tags for multiple zones at once'. Every word earns its place and the verb is immediate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter) and the schema explains the input, but there is no output schema or annotation coverage. The description does not explain the return format (e.g., a list of tags, a map keyed by zone ID), nor does it mention any constraints on batch size or error handling. For a tool with zero annotations and no output schema, the description should disclose more about the result to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage of the only parameter (zone_ids) with a clear description 'Array of zone IDs to generate tags for'. The tool description adds no parameter-specific meaning beyond what the schema contains, so the baseline score of 3 is appropriate since the schema handles the parameter semantics well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates ad serving tags for multiple zones at once. The verb 'generate' plus the resource 'ad serving tags' and scope 'multiple zones' make the purpose specific, and it distinguishes itself from single-zone tag tools like get_zone_tag and VAST-specific get_vast_zone_tags.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for multiple zones at once' implies this is the bulk variant of single-zone tag generation, but the description does not explicitly state when to use this tool versus alternatives or provide any exclusions. The usage context is implied through the 'multiple' wording, but no direct comparison to sibling tools 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, the description carries the full burden of behavioral disclosure. It only states 'Get details,' providing no information about error behavior, permissions, or return payload characteristics beyond the generic implication of a read operation. This is minimal disclosure for a tool that may return null or throw if ID is not found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no filler. It is appropriately sized for a simple getter and front-loads the primary action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read tool, the description is adequate but lacks explicit information about the returned details or potential error conditions. Since there is no output schema, the description could have elaborated on what 'details' includes or any constraints, making it slightly incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully covers the single parameter 'id' with a description ('Archived advertiser ID'). The description adds no extra semantic detail beyond what the schema provides, but the baseline of 3 applies because schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get details') and the resource ('specific archived advertiser'). It distinguishes this tool from siblings like 'get_advertiser' (presumably active) and 'list_archived_advertisers' by emphasizing a single archived advertiser.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'specific archived advertiser' implies that this tool is for retrieving one archived advertiser by ID, contrasting with listing operations. However, no explicit guidance is given about when to prefer this over 'get_advertiser' or how it complements 'unarchive_advertiser'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It only states 'Get details' and fails to mention that the operation is read-only, what happens if the document is not found, or any permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with zero wasted words. It is appropriately front-loaded and clear, providing the essential information without padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool, the description is minimally adequate, but without an output schema it does not specify what 'details' are returned or how errors are handled. It leaves some ambiguity about the response structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema descriptions cover 100% of the parameters (contract_id and id), and the description adds no additional parameter semantics. The baseline of 3 applies because the schema already documents the parameters adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Get) and the resource (details of a specific contract document), distinguishing it from sibling tools like list_contract_documents, create_contract_document, update_contract_document, and delete_contract_document.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving a single document by ID, but it provides no explicit guidance on when to use this tool versus alternatives such as list_contract_documents or get_contract. No exclusions or alternative references are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the burden of behavioral disclosure. It conveys that this is a read operation ('Get details'), but it does not disclose error behavior, permission requirements, or what specific details are returned. This is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It efficiently states the action and target resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with two fully described parameters, the description is adequate, but it omits any details about the response shape or potential errors, especially since there is no output schema or annotations. The term 'details' is vague, so a bit more specificity about what information is returned would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters ('Payment ID' and 'Contract ID') with 100% coverage, so the description adds little semantic value. The phrase 'specific contract payment' aligns with the required contract_id and id but does not explain formats, relationships, or constraints beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get details of a specific contract payment'. It uses a specific verb ('Get'), identifies the resource ('contract payment'), and 'specific' indicates a singular lookup, distinguishing it from list, create, or delete operations on the same resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as list_contract_payments or get_contract. There are no stated prerequisites, exclusions, or references to related tools, leaving the agent to infer usage from the 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 must carry the full burden of behavioral disclosure. It only says 'Get details' without mentioning what those details are, error behavior, permissions, or response format. This adds little beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that effectively communicates the tool's purpose with no unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter getter with no output schema, this description is minimally adequate. It states what the tool does, but lacks any context about the returned details or when to use it among the many contract-related sibling tools. It could be slightly more informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with a clear description for the single 'id' parameter. The tool description does not add any additional meaning or context beyond what the schema provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets details for a specific contract template, using a specific verb and resource. This distinguishes it from sibling tools like list_contract_templates (which lists all) and create/update/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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'specific contract template' implies this tool is for retrieving a single template by ID, which is useful guidance. However, it does not explicitly state when to prefer this over list_contract_templates or mention any exclusions/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 of behavioral disclosure. It uses the verb 'Get' which implies read-only behavior, but it does not explicitly state that the operation is safe, does not modify data, or what errors/returns to expect. The description adds little beyond the tool name itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence: 'Get details of a specific data key target'. It contains no filler and every word contributes to the core purpose, 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema or annotations), the description is minimally adequate for selecting and invoking it. However, it does not specify what 'details' includes, such as response fields, error handling, or whether additional permissions are needed, leaving gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for the single 'id' parameter with description 'Data key target ID'. The tool description does not add any additional parameter semantics, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get details of a specific data key target' clearly states the action (get) and resource (data key target), and the word 'specific' distinguishes it from sibling tools like list_data_key_targets, create_data_key_target, etc. It precisely describes a single-object retrieval 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when retrieving an individual data key target by ID, but it does not explicitly mention alternatives such as list_data_key_targets for listing all targets or create/update/delete for modifications. 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 must carry the full burden of behavioral disclosure. It only says 'Get details,' which implies a read operation, but does not clarify return format, error handling, authorization requirements, or whether there are any side effects. This is minimal and leaves significant behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words or filler. Every word contributes to conveying the tool's purpose, 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no nested objects, no output schema), so the description plus schema cover basic invocation. However, without annotations or an output schema, the description should ideally say more about the return value or error behavior to be fully complete. It is minimally viable but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single 'id' parameter, and the schema already describes it as 'Demand endpoint ID.' The description's 'by ID' adds no additional semantic information beyond what the schema provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get details of a specific demand endpoint by ID' clearly identifies the verb (get), the resource (demand endpoint), and the scope (specific, by ID). This distinguishes it from sibling tools like list_demand_endpoints, create_demand_endpoint, and update_demand_endpoint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when you need details for a single demand endpoint and know its ID, but it does not explicitly state when to prefer this over alternatives like list_demand_endpoints, nor does it mention any exclusions or prerequisites. The usage context is discernible but not directly 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 'Get details' which implies a read-only operation, but it does not mention response format, error behavior, permissions, or other side effects. This is minimal guidance 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the action, target, and qualifier without redundancy. It is appropriately concise for a straightforward retrieval operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID operation with one parameter and no output schema, the description is mostly adequate but does not specify what 'details' are returned or potential edge cases. It lacks enough context for an agent to fully understand the expected response without additional assumptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (the only parameter 'id' is described as 'Demand source ID'), so the schema already documents the parameter. The description does not add additional meaning beyond the schema, which is acceptable for a simple single-parameter lookup.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') with a specific resource ('demand source') and scope ('by ID'), clearly distinguishing it from sibling tools like list_demand_sources, create_demand_source, update_demand_source, and delete_demand_source.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving a single demand source when its ID is available, but it does not explicitly state when to use this tool versus alternatives or mention any prerequisites. Usage context is inferred rather than 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 must carry the full burden of behavioral disclosure. It only says 'Get details' without elaborating on any behavioral traits such as error handling (e.g., 404 if not found), authorization requirements, side effects (none, but not stated explicitly), or whether the response contains all fields or a subset. This is a significant gap for a fetch 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that is front-loaded with the action and resource. It contains no filler or redundant information and is immediately parseable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description is minimally adequate but leaves gaps. It does not mention what 'details' entails (e.g., which manager fields are returned) or any error behavior. While a simple get-by-id tool may not need extensive documentation, the lack of output schema and annotations increases the need for more context to fully prepare the agent for the response and potential failures.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter 'id', which already has a clear description ('Manager ID'). The description's phrase 'by ID' adds no new meaning beyond the schema. Since the schema handles parameter documentation, the baseline of 3 is appropriate; the description does not compensate with additional context like ID format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('details of a specific manager') with a clear access method ('by ID'). This distinguishes it from sibling tools like list_managers, which retrieves all managers, and create_manager/update_manager/delete_manager, which perform other 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied: the user should have a specific manager ID and want its full details. However, it does not explicitly state when to use this instead of list_managers (e.g., to find an ID) or that get_manager is the read-only counterpart to update_manager/delete_manager. There is no explicit when/when-not or alternative mentioned, so it only meets the 'implied usage' level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose whether this is a read-only operation, what happens if the media group is not found, or what response details are included. 'Get details' implies a safe fetch but lacks explicit 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that is front-loaded with the action and object. It contains no filler words or unnecessary detail, making it exceptionally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple CRUD 'get' with one parameter, the description is minimally adequate but leaves out return format details. With no output schema, the agent does not know what 'details' are returned, which is a gap for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the single parameter 'id' as 'Media group ID' (100% coverage). The description adds no further semantic meaning beyond what the schema already provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('media group'), clearly indicating a single-entity retrieval. It distinguishes itself from sibling tools like 'list_media_groups' by specifying 'a specific' media group, implying lookup by ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given for when to use this tool versus alternatives. The context is implied by the name 'get' and the 'specific' wording, which suggest singular fetch, but there are no stated exclusions or references to 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 only says 'Get details', which implies a read operation but does not disclose permissions, return value shape, error behavior, or any side effects. This adds little beyond what the name already conveys.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the verb and resource, containing no redundant or filler content. It is appropriately concise for a simple getter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 params, no output schema, no annotations), and the description states the core purpose. However, it does not clarify what 'details' include or what the response looks like, leaving some ambiguity for an agent invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for both parameters ('Image asset ID' and 'ORTB native template ID'). The description does not add any additional parameter semantics beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and clearly identifies the resource ('details of a specific image asset') and its context ('for an ORTB native template'). This distinguishes it from sibling tools like list/create/update/delete on image assets and other asset types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the name and description—this fetches a single image asset as opposed to listing all—but there is no explicit guidance on when to use this over alternatives, no exclusions, and no mention of prerequisites. It's adequate but not instructive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only states 'Get details', which implies a read-only operation, but it does not disclose error handling (e.g., what happens if the ID is not found), permissions, rate limits, or response format. This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is direct and front-loaded. It contains no filler and every word contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple getter with one parameter and no output schema. The description is adequate but minimal: it does not explain what 'details' includes, potential error scenarios, or the structure of the returned object. Given the lack of annotations and output schema, more context could be beneficial, but complexity is low and the description meets the minimum viable standard.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (the 'id' parameter is fully described as 'PMP deal ID'). The description adds the word 'by ID', which aligns with the schema, but provides no additional meaning beyond what the schema already defines.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (get), the resource (PMP deal), and the scope (by ID). This distinguishes it from sibling tools like list_pmp_deals, create_pmp_deal, update_pmp_deal, and delete_pmp_deal, which handle collection operations or mutations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: when you have a specific deal ID and need its details. However, it does not explicitly mention alternatives (e.g., 'use list_pmp_deals to find IDs') or exclusions, so guidance is limited to what is naturally inferred from the verb 'get'.
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 of behavioral disclosure. It implies a read-only operation ('Get details') but does not disclose error behavior (e.g., 404 if not found), authentication requirements, or what fields are included in 'details'. For a simple getter, this is minimally adequate but leaves room for more 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant information. It is appropriately front-loaded and easy to parse, containing exactly the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with two required parameters and no output schema or annotations, the description is adequate but minimal. It does not specify what 'details' includes or what the response looks like, nor any edge cases. Given the low complexity, this is a reasonable minimum, but additional context about response structure or error handling would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with descriptions for both parameters ('Publisher ID' and 'Source target ID'). The description adds no additional meaning beyond the schema, such as explaining the relationship between publisher_id and source_target_id or how they form a composite key. With such high schema coverage, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets details of a specific product source target, using the verb 'get' and the resource 'product source target'. This distinguishes it from sibling tools like list_product_source_targets, create_product_source_target, update_product_source_target, and delete_product_source_target. The word 'specific' signals a single-object lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as list_product_source_targets for multiple records or get_product_source for a different resource. No prerequisites, exclusions, or alternative tool references are given. The need for both publisher_id and source_target_id is implied only by the schema, not by the description.
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?
There are no annotations, so the description carries the full burden. 'Get details' implies a read-only operation, but it does not disclose potential side effects, authentication requirements, or response format. It is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no wasted words, front-loading the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema or annotations, the description does not explain what 'details' include, error conditions, or return structure. It is minimally complete for a simple fetch but leaves ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the 'id' parameter as 'Role ID', and the description simply restates 'by ID'. No additional meaning such as id format, source, or validation rules is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' with the resource 'role' and scope 'by ID', clearly distinguishing it from list_roles, create_role, update_role, and delete_role 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/5Does 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 list_roles or other alternatives. The usage is implied by the name and description 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. It only states 'Get details', which implies a read operation, but does not disclose the return shape, potential errors, authentication needs, or whether a non-existent ID leads to an error or null. This adds little beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It is concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID tool with one parameter and no output schema, the description is minimally adequate but vague about what 'details' includes. It would benefit from stating that it returns the full database object and possibly noting behavior when the ID does not exist.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the single parameter `id` with 'User database ID' (100% schema coverage). The description does not add extra meaning, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' and clearly identifies the resource ('user database') and scope ('by ID'). It distinguishes from sibling tools like list_user_dbs and create_user_db, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you have a specific ID and want details) but does not explicitly mention alternatives like list_user_dbs or create_user_db. There is no when-not-to-use or exclusion 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, and the description only states the purpose. It fails to disclose any behavioral aspects such as whether the tag is returned as an HTML snippet, if permissions are required, or if the operation is read-only. This leaves the agent with insufficient information about side effects and output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that directly states the tool's purpose. It contains no unnecessary words or repetition, making it highly concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema, but the description provides no information about the return value or any caveats. Given the lack of annotations and output schema, a slightly richer description (e.g., what the tag looks like) would be more complete. The current description is adequate but minimal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description for the single 'id' parameter is complete ('VAST campaign ID'), covering 100% of the parameters. The description adds no additional meaning beyond the schema, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a conversion tracking tag specifically for a VAST campaign. This distinguishes it from sibling tools that fetch conversion tags for other entity types (e.g., zones, ad items, placements).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied by the resource type: use it when you need a conversion tag for a VAST campaign. However, it does not explicitly mention alternatives or exclusions, such as when to use get_campaign_conversion_tag instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of disclosure. It only says 'Get details,' which implies a read operation, but it does not disclose any authentication requirements, rate limits, or what happens if the ID is invalid. It adds no behavioral context beyond the 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is direct and front-loaded. It contains no filler words and clearly conveys the action and target, earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter get tool, the description is minimal. However, with no output schema, it does not clarify what 'details' are returned or any special behavior. It is adequate but lacks richer context that could help an agent understand the full scope of the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the only parameter 'id' as 'Creative ID' with 100% coverage. The description does not add any further meaning to the parameter, so it provides no additional value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get details of a specific video creative' uses a specific verb (Get), identifies the resource (video creative), and scopes it to a specific item (by ID). It clearly distinguishes from list, create, update, and delete operations, as well as from the generic get_creative or other creative types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need details of one video creative by ID, but it does not explicitly state when to use this tool over alternatives like list_video_creatives or get_creative. No when-not or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must itself convey behavioral traits. It states the output is an 'ad serving tag (embed code)', which clarifies the return type and implies a read-only operation. However, it omits details like authentication requirements, error conditions, or the exact format of the embed code.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately states the tool's purpose. Every word contributes, and it is front-loaded with the verb 'Get'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with one parameter and no output schema, the description is adequate but not rich. It does not explain any edge cases, such as whether the zone must be active, nor does it clarify the relationship to similar tag-related tools, leaving some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage; the only parameter 'id' is described as 'Zone ID'. The description adds no further parameter semantics, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets the ad serving tag (embed code) for a zone, using a specific verb and resource. This distinguishes it from sibling tools like get_zone_conversion_tag or get_email_zone_tag, which target different tag types or zone 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It does not mention prerequisites, such as the zone needing to exist or be active, nor does it point users to related tools for conversion tags or other zone types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It clarifies the scope ('across all configurations') and the action ('List'), which implies a safe read operation. However, it does not disclose pagination behavior, result ordering, or any potential side effects, leaving 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence of six words, front-loaded with the verb and resource. Every word earns its place; zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with well-documented pagination params, the description is adequate but lacks context about what 'generated reports' includes (e.g., file types, time range) and how this differs from list_report_generated. No output schema exists, so the description could usefully state the return format, but it does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% because both `limit` and `offset` are documented in the schema. The tool description adds no extra param meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List'), names the resource ('generated reports'), and provides scope ('across all configurations'), which clearly distinguishes it from sibling tools like list_report_generated or list_all_report_schedules. It is specific and immediately understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention that list_report_generated might be filtered by schedule or that list_all_report_schedules lists schedules rather than report files. There is no context on ideal use cases 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, and the description only restates the function name without disclosing how pagination works, what 'all configurations' encompasses, or any side effects. It adds minimal context beyond the name, leaving the agent without safety or behavior 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, leading with the action verb and immediately stating the resource scope. For a tool with only two optional parameters, this is appropriately sized and efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but with no output schema or annotations, the description leaves ambiguity around the meaning of 'all configurations' and the return format. It is adequate for a basic listing action but lacks the behavioral and edge-case context needed for fuller completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both limit and offset parameters are fully described in the input schema (100% coverage), and the description adds no additional parameter details or constraints. The baseline of 3 applies because the schema carries the full semantic burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 ('all report schedules across all configurations'), which distinguishes it from the scoped sibling list_report_schedules. The scope is explicitly broad, making the tool's intent unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'across all configurations' implies usage for a global overview, but the description does not explicitly state when to prefer this tool over list_report_schedules or any other listing methods. No alternatives or exclusions are mentioned, so guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 available, the description carries the full burden of behavioral disclosure. It only states 'List all archived standard campaigns' without mentioning pagination, sorting, or that limit and offset are required to retrieve all results. This provides minimal insight into how the tool actually 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is easy to parse, with no redundancy or unnecessary details. It effectively front-loads the core purpose of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple and the schema covers parameters, the description lacks context about when to use it versus similar list tools, and does not explain the meaning of 'standard' or pagination behavior. Given no annotations or output schema, this leaves the agent with some ambiguity about the tool's full behavior and appropriate selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents limit and offset with clear descriptions, so the description does not need to restate them. It adds no parameter-specific semantics beyond the tool's scope, but given 100% schema coverage, this is acceptable per the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists archived standard campaigns, with a specific verb and resource. The 'standard' qualifier distinguishes it from VAST-specific archived campaign tools like vast_list_archived_campaigns, and 'archived' distinguishes from list_campaigns. This is specific and not a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its usage through the name and qualifiers, but it does not explicitly state when to choose this tool over list_campaigns, list_all_campaigns, or vast_list_archived_campaigns. No exclusions or alternative recommendations are provided, leaving room for ambiguity 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?
No annotations are provided, so the description carries the full burden. It only states 'List all standard campaigns' and does not disclose pagination behavior, return format, or that it excludes non-standard (e.g., archived) campaigns. The lack of any behavioral detail beyond the verb 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single four-word sentence with no wasted words. It is appropriately sized and front-loads the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with two optional parameters and an output schema absent, the description is somewhat complete but leaves ambiguity around what 'standard' means and does not mention pagination via limit/offset. The schema covers parameters, but the description could clarify the distinction from list_all_campaigns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both limit and offset, so the schema fully documents the parameters. The description adds no parameter-specific meaning, but the baseline of 3 applies since the schema handles the semantic load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all standard campaigns' uses a specific verb and resource, and the qualifier 'standard' distinguishes it from sibling tools like list_all_campaigns and list_archived_campaigns. It clearly indicates 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The qualifier 'standard' implies a subset of campaigns, suggesting when to use this tool versus list_all_campaigns or list_archived_campaigns, but there is no explicit when/when-not guidance or named alternatives. The usage context is implied rather than 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 is fully responsible for disclosing behavioral traits. It only states the list action and does not mention pagination limits, return format, whether archived zones are included or excluded, or any other side effects. This leaves significant behavioral ambiguity for a tool that could interact with a large dataset.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant information. It efficiently conveys the purpose without any fluff, earning a top score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with full schema coverage, the description is minimally adequate. However, it does not mention the output format, default pagination behavior (though the schema does), or how it differs from the many sibling zone tools. More context would help the agent choose this tool confidently, but given its simplicity, a score of 3 is fair.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides complete descriptions for both parameters (limit and offset), achieving 100% schema description coverage. The tool description adds no additional parameter semantics, so the baseline score of 3 is appropriate per the rubric.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'List all catalog zones' with a specific resource type, and the parenthetical 'for product/retail ad serving' adds domain context that helps it stand out from generic zone listing tools like list_zones and vast_list_zones. This is a specific verb+resource pair that satisfies the top score even without an explicit sibling reference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by naming the resource type, but it does not explicitly state when to use this tool versus alternatives, nor does it provide any exclusions. The 'for product/retail ad serving' hint gives limited context, but there is no guidance on when not to use it or which sibling tools might be more appropriate for different zone types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It only states 'List file revisions' without disclosing pagination, ordering, return format, or whether it returns full metadata for each revision.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the verb and resource, and contains no filler. It is appropriately sized for the operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has low complexity (2 params, no nested objects), but there is no output schema or annotations. The description is adequate to identify the operation but does not explain return values or list behavior, leaving notable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters with 100% coverage. The description adds no additional parameter meaning beyond what is in the schema, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('file revisions for a contract document'). It clearly distinguishes from the sibling get_contract_document_file_revision (singular) and download_contract_document_file_revision by indicating a collection 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use guidance or mention of alternatives is provided. The verb 'List' implies it should be used for enumerating revisions, but it doesn't state when to prefer this over getting or downloading a specific revision.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 says 'list', which implies a read operation, but fails to mention any caveats such as pagination behavior, authentication requirements, or whether the response includes full creative objects or just summaries. No context about rate limits or filtering is offered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently conveys the core purpose and scope. This is a model of conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a simple list tool with no output schema, the description is minimally adequate. It clearly states what the tool does, but does not explain what is returned (e.g., array of creative objects or IDs) or how the 'all' scope interacts with pagination. Given the lack of an output schema, more detail would be helpful for an agent to set correct expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has full coverage (100%) with descriptive parameter names and descriptions for limit and offset. The description adds no additional meaning beyond the schema, so the baseline of 3 applies—the schema already documents the parameters adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all image creatives' clearly states the action (list) and the resource (image creatives), and the modifier 'all' indicates the scope. It distinguishes from sibling tools like list_video_creatives and list_all_creatives by explicitly limiting to image creatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for listing image creatives, but it does not explicitly state when to use it over alternatives like list_all_creatives or get_creative. No exclusions or alternative recommendations are provided, leaving the agent to infer usage only from the resource type.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 burden. It states 'List all data keys' but the schema includes limit/offset, implying pagination and a default cap of 100, which is not disclosed. It also does not specify that it is read-only or describe the return format, leaving behavioral traits ambiguous.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero fluff. It conveys the essential action and resource without unnecessary detail, making it highly scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does not explain return values, but the parenthetical clarifies the resource concept. For a simple list tool with only pagination params, this is minimally adequate, though it lacks information about data key structure or any access criteria.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both limit and offset parameters, so the schema fully explains their semantics. The description adds no parameter-specific detail beyond the parenthetical clarification of what data keys are, which is unrelated to params.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') with a clear resource ('data keys') and clarifies the domain ('custom key-value targeting variables'). This distinguishes it from sibling tools like get_data_key (single item) and list_data_key_targets (different resource).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied by the name and description—use to enumerate all data keys, vs. get_data_key for a specific one—but no explicit guidance or alternatives are provided. The description does not mention when to use this over related list operations or mention pagination when many keys 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 only says 'List all demand endpoints' and does not disclose pagination behavior, auth requirements, or any other traits. The word 'all' could be misleading given the presence of limit/offset parameters in the schema, and no additional context is added.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, zero waste, and front-loaded with the action. Every word contributes to the purpose. This is an example of efficient, appropriately sized description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with two optional pagination parameters and no output schema, the description provides the essential purpose but lacks any information about return format, ordering, or the meaning of 'all' relative to pagination. Given the low complexity, this is a minimum viable description, but the lack of annotations and absence of return value details leave some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with limit and offset both having clear descriptions. The tool description does not add any parameter semantics beyond the schema, which is acceptable when coverage is high. The baseline of 3 applies because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and clearly identifies the resource ('demand endpoints') and scope ('all... in your AdButler account'). This distinguishes it from sibling tools like get_demand_endpoint (single fetch) and create_demand_endpoint (mutation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies use for enumerating all demand endpoints, but it does not explicitly mention alternatives or when not to use it. Sibling tool names like get_demand_endpoint suggest a single-item alternative, but no explicit comparison is provided. Context is clear but guidance is implied rather than 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 must carry the full burden of behavioral disclosure. It only states the list action, which implies a read-only operation, but does not disclose pagination behavior, return format, or any limits beyond the schema. This adds little beyond the tool name and 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant information. It efficiently states what the tool does in a way that is immediately understandable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (2 optional parameters, no output schema, no annotations), the description is adequate but leaves gaps. It does not mention pagination or return shape, though the schema covers parameters. The description is sufficient for a simple list tool but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with clear descriptions for both 'limit' and 'offset', including defaults and max. The description adds no parameter-specific information, but the high schema coverage justifies a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'List all demand sources in your AdButler account.' It uses a specific verb ('List') and identifies the resource ('demand sources') with an explicit scope. This distinguishes it from siblings like get_demand_source (single item) and create/update/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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (when you want to list all demand sources) but provides no explicit guidance on when to use this tool versus alternatives, such as get_demand_source for a single source. It does not mention exclusions or alternatives, so the usage guidance is implied rather than 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 providing safety or behavioral hints, the description must disclose behavior itself. It only says 'List all' and does not explain that pagination is involved via limit/offset, nor what happens if there are many targets. The schema hints at pagination, but the description fails to mention it, making the tool's behavior unclear 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant wording. It efficiently conveys the core purpose and includes a helpful parenthetical clarification without any fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with two optional pagination parameters and no output schema, the description covers the basic purpose but omits important behavioral context like pagination semantics and what fields are returned. It is minimally adequate for a straightforward resource, but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents both parameters (limit and offset) with descriptions including default and max values, so schema coverage is 100%. The description adds no additional parameter-level meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (List) and resource (geo targets), with a clarifying parenthetical that defines what geo targets are. This distinguishes it from sibling tools like get_geo_target, create_geo_target, and other list_* target 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear listing purpose but offers no explicit guidance on when to use this tool versus alternatives such as get_geo_target for a single target or list_postal_code_targets for other targeting types. No exclusions or alternative recommendations 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?
With no annotations provided, the description carries full behavioral transparency burden, but it only restates the listing action. It does not disclose that this is a read-only operation, how pagination behaves beyond the schema defaults, or any side effects. The absence of safety or behavior notes is a notable 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero unnecessary words. It states the action and clarifies the domain in a parenthetical, making it concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with two optional pagination parameters, the description is minimally adequate, but it leaves gaps: no output schema means the agent doesn't know the return structure, and there's no mention of whether 'all' means across all scopes (e.g., advertiser, account) or any filtering/ordering behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for limit (default 100, max 100) and offset (pagination offset). The tool description itself adds no parameter-specific semantics, so the baseline of 3 applies as the schema already documents the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 'list targets', with a clarifying parenthetical '(allowlist/blocklist targeting)'. This distinguishes it from sibling tools like get_list_target, create_list_target, and other target-type listers (e.g., list_data_key_targets, list_platform_targets).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied by the name and description: use this to list list targets, presumably when you need the full set rather than a single target (which would use get_list_target). However, there is no explicit when-to-use vs alternatives, no exclusions, and no mention of prerequisites or scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must communicate behavioral traits on its own. It only says 'List all publishers,' giving no detail on whether archived publishers are included, pagination behavior, authentication requirements, or return format, leaving significant ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, direct sentence conveys the purpose without unnecessary words or repetition. Information is front-loaded and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list endpoint with two self-explanatory pagination parameters, the description is minimally sufficient. However, it does not clarify whether 'all' includes archived publishers, and there is no output schema or return-value description, leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for limit and offset. The tool description adds no additional parameter context, so the baseline of 3 applies for schema-driven clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation ('List all publishers') and the resource scope ('in your AdButler account'). It differentiates from sibling tools like get_publisher and list_archived_publishers by emphasizing the complete collection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving all publishers but does not explicitly state when to choose this over alternatives such as get_publisher or list_archived_publishers. No exclusions or alternative tool references 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 must carry the burden of behavioral disclosure. It only restates the action without mentioning pagination behavior, return value structure, ordering, or any side effects. For a listing tool, the lack of these details limits 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no redundant wording. It is front-loaded and concise, earning full marks for structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with four schema-documented parameters, the description is minimally adequate. However, with no output schema or annotations, it would benefit from explaining what 'generated reports' includes (e.g., metadata, file downloads) and any pagination conventions. The current description covers the basic action but not the broader context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline of 3 applies. The description adds only the 'specific schedule' context, which aligns with the required schedule_id and report_config_id parameters, but does not add significant semantic value beyond what the schema already documents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List generated reports for a specific schedule' clearly states the verb (List), resource (generated reports), and scope (for a specific schedule). This distinguishes it from broader list tools like list_all_generated_reports, and the name itself reinforces the schedule-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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for a specific schedule' implies this is for filtering by schedule, but it does not explicitly mention when to prefer this over sibling tools like list_report_generated or list_all_generated_reports. No exclusions or alternative conditions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states 'List all' and does not mention pagination behavior, return format, or any side effects, leaving significant gaps for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action and resource. Every word earns its place with no unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with full parameter schema coverage, but there is no output schema or annotations. The description does not explain what is returned or provide any additional context, leaving some gaps for an agent unfamiliar with the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters (limit and offset) described in the schema. The description does not add additional meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with the resource 'SFTP connections' and scopes it to 'your AdButler account'. It clearly distinguishes from sibling tools like get_sftp_connection, create_sftp_connection, and delete_sftp_connection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving all SFTP connections, but it does not explicitly mention alternatives or when not to use this tool. There is no guidance on when to prefer this over get_sftp_connection or other 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, the description carries the full burden of behavioral disclosure. It only states the basic listing action and does not mention pagination behavior, authentication requirements, or what the response contains. The limit and offset parameters are present in the schema but not referenced in the description, so the description adds no behavioral context beyond the bare function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It immediately states the 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool, the description covers the core purpose. However, with no output schema and no mention of pagination or response format, there are gaps in completeness. It is adequate for a basic list operation but leaves some context unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters (limit and offset) have descriptive text in the input schema, so schema coverage is 100%. The description adds no additional parameter semantics, but the baseline score of 3 is appropriate when the schema already documents both parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and clearly identifies the resource as 'trusted redirect domains' scoped to 'your AdButler account'. This effectively distinguishes it from sibling tools like get_trusted_redirect_domain, create_trusted_redirect_domain, and delete_trusted_redirect_domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'List all' implies usage for enumerating trusted redirect domains, but there is no explicit guidance on when to use this tool versus get_trusted_redirect_domain for a single item, nor any exclusions or alternatives. The usage context is only implied by the action word.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 disclosing behavior. It only states the operation ('Remove values') without noting whether the operation is destructive, whether it affects existing values not in the list, any permission requirements, or the behavior when values are not present. This is a significant transparency 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is well front-loaded. It contains no redundant information and every word contributes to understanding the tool's core purpose. It is appropriately minimal for the simplicity of the operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the schema covers all parameter details, but there are no annotations and no output schema. The description does not explain return values, error conditions, or side effects. While adequate as a minimal baseline, it leaves gaps in behavioral expectations that an agent would need to infer or guess.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters (values, user_id, user_db_id, list_attribute_name) are already described with clear types and meanings in the schema. The description adds no further parameter context, which aligns with the baseline of 3 when the schema carries the weight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Remove values from a list attribute for a user'. It uses a specific verb and resource, and the contrast with the sibling tool 'add_user_list_attribute_values' makes the direction (remove vs add) unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool's use case (removing values from a list attribute) but provides no explicit guidance on when to use it versus alternatives, no prerequisites, and no exclusions. The sibling 'add_user_list_attribute_values' suggests a complementary operation, but no such 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 carries the full burden. It states the primary effect (restoring to active status) but does not disclose prerequisites (e.g., the zone must be archived), potential errors, permission requirements, or the response format. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence that is front-loaded with the action and subject. There is no redundant or extraneous wording; every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema), so the description is minimally viable. However, it lacks usage context and behavioral caveats, making it only partially complete for an agent deciding when and how to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% coverage with a clear description of the 'id' parameter as 'Archived email zone ID'. The description adds no additional parameter details, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Restore'), the resource ('archived email zone'), and the outcome ('back to active status'). It is specific and distinguishes this from sibling tools like unarchive_zone by explicitly mentioning 'email zone'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case (when you need to restore an archived email zone), but does not provide explicit when-to-use or when-not-to-use guidance, nor does it name alternatives. The tool name and sibling context somewhat compensate.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 simply states 'Update an existing rich media creative' and provides no details about whether updates are partial or full replacement, whether permissions are required, whether changes are reversible, or what the response contains. This is a meaningful transparency 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action ('Update') and resource ('existing rich media creative'). There is no wasted text, and it is appropriately sized for a tool with only three parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, the schema covers all parameters, and there is no output schema. However, the description is too sparse for a mutation operation with no annotations: it does not explain return value, partial update semantics, or side effects. It is adequate but leaves clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes all three parameters (id, name, description) with 100% coverage. The description adds no additional parameter semantics, so the baseline of 3 applies: the schema does the heavy lifting, and the description neither helps nor hurts.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Update') with a clear resource ('existing rich media creative'), and it distinguishes this tool from its siblings such as create_rich_media_creative, get_rich_media_creative, and delete_rich_media_creative. The word 'existing' reinforces that this is not a create 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: it updates a rich media creative that already exists, so it should be used after creation. However, it gives no explicit exclusions or alternatives, and it does not mention when to choose this over similar update tools like replace_rich_media_creative_file or vast42_update_creative.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 says 'update', which implies mutation, but does not disclose whether the update is partial or full, what happens to omitted fields, required permissions, or the return format. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence: 'Update an existing ORTB native ad for a standard zone.' Every word contributes meaning, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple CRUD update with a fully documented schema, but it lacks an output schema and annotations. The description does not clarify return value, update semantics (partial vs full), or what 'standard zone' means relative to other zone types, leaving some gaps for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — each parameter (id, name, zone_id, template_id) has a description. The tool description adds no extra parameter-level meaning, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update'), the resource ('an existing ORTB native ad'), and the scope ('for a standard zone'). It distinguishes the tool from its siblings (create_zone_ortb_native_ad, delete_zone_ortb_native_ad, etc.) by specifying 'update' and 'existing'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for modifying an existing ORTB native ad, but it does not explicitly state when to use this tool versus alternatives like create or delete. There is no mention of prerequisites, partial vs full updates, 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 the full burden of behavioral disclosure. It only restates the delete action without adding context such as irreversibility, permissions required, side effects, or whether the file is unlinked or permanently removed. The word 'Delete' conveys basic destructiveness, but no additional useful behavioral traits are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary words. It is appropriately sized for a simple delete operation, earning a high score for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema, so the description is minimally adequate. However, given the absence of annotations, a bit more context about deletion semantics (e.g., permanence, dependency checks) would improve completeness. As is, it meets the minimum viable standard.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the only parameter 'id' already described as 'VAST 4.2 closed caption file ID'. The description adds no extra parameter context, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb (Delete) and resource (VAST 4.2 closed caption file), clearly distinguishing it from sibling tools that delete other VAST entities (e.g., vast42_delete_ad, vast42_delete_creative). It directly states the action and target.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when a VAST 4.2 closed caption file needs to be removed) but does not provide explicit exclusions, prerequisites, or alternatives. Since the action is straightforward, implied usage is acceptable but not fully 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, and the description only says 'Get' without disclosing return format, error handling, permissions, or read-only behavior. It adds no context beyond the obvious verb and resource.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero wasted words. It efficiently states the action and object.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID tool, the description covers the basic action, but it lacks details on return value, error behavior, and usage guidance. The schema is minimal, and no output schema or annotations exist, so the description could compensate more but doesn't.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the 'id' parameter already described as 'VAST 4.2 ad item ID'. The description adds no additional parameter meaning; the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 'VAST 4.2 ad item', with 'single' distinguishing it from bulk list operations. It directly matches the tool name and parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The presence of an 'id' parameter implies use for retrieving a specific item by ID, but the description provides no explicit when-to-use guidance or alternatives. It doesn't mention when to choose this over other getters or the list 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 only states that the tool 'gets' a file, which implies a read operation, but it does not disclose error handling, return format, permission needs, or any other behavioral traits. This is a significant under-disclosure even for a simple read 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence: 'Get a single VAST 4.2 closed caption file'. Every word contributes meaning, and the verb and resource are front-loaded. There is no fluff or irrelevant detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having only one parameter and no output schema, the description is minimally adequate. It states the action and resource but does not specify what the tool returns (file content vs. metadata) or error behavior. For a simple GET tool, this is acceptable but leaves clear gaps that could hinder an agent's expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% description coverage for the only parameter 'id', describing it as 'VAST 4.2 closed caption file ID'. The description adds no additional parameter information, but the schema already defines the parameter meaning, so the description is not required to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses 'Get' as a specific verb and clearly specifies the resource 'VAST 4.2 closed caption file'. The word 'single' distinguishes it from listing tools, and the resource name differentiates it from other get tools for different entities. This strongly clarifies 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives is provided. The description implies it is for fetching a single file by ID, but it does not mention when to use list, create, or update tools, nor any exclusion criteria. Usage is therefore only implied, not clearly 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 only states the action without mentioning that it is a read-only operation, what happens if the creative is not found, or any authentication/error behavior. This is a minimal safety 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is appropriately sized for a simple get-by-ID tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one parameter), high schema coverage, and lack of output schema, the description is minimally complete. However, it does not mention what the tool returns or any side effects, which could help the agent fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the 'id' parameter already described as 'VAST 4.2 creative ID'. The description adds no additional meaning beyond the schema, so it meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a single VAST 4.2 creative' uses a specific verb and resource, clearly indicating a single-item retrieval. It distinguishes from sibling tools like vast42_list_creatives, vast42_create_creative, etc., by specifying 'single' and 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving one creative by ID, but does not explicitly state when to use this tool versus the list or other creative-related tools. No alternatives or exclusions are mentioned, making the guidance implicit rather than 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 of behavioral disclosure. It only states the basic action and object, adding no context about response format, permissions, error conditions, or side effects. This offers minimal transparency beyond the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the action and object with no unnecessary words. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple fetch-by-ID tool with full schema coverage, the description is minimally adequate. However, since there is no output schema, it does not clarify what the returned icon data contains or any possible errors, leaving some gaps for a tool of this simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides full coverage (100%) for the single 'id' parameter with a clear description ('VAST 4.2 icon ID'). The tool description adds no additional parameter semantics, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and a clear resource ('VAST 4.2 icon'), and further specifies 'single', which distinguishes it from list, create, update, and delete siblings. This makes the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The word 'single' and the required 'id' parameter imply this tool is for fetching one specific icon, but the description does not explicitly mention when to use it versus alternatives like vast42_list_icons. There is no stated exclusion or guidance, so usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It discloses the basic retrieval action but omits behavioral details such as what is returned, error behavior (e.g., 404 if not found), or any read-only guarantee. The description adds little beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence containing no redundant words or filler. It efficiently conveys the core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with one well-documented parameter, the description is minimally viable. However, given the absence of an output schema and annotations, it would be more complete if it described the return value or error conditions. Still, the purpose is clear from the name and sibling context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%; the only parameter 'id' is described as 'VAST 4.2 media file ID'. The description does not add further meaning, such as explaining that this ID is obtained from creation or listing operations, but the schema already fully documents the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a single VAST 4.2 media file' uses a specific verb ('Get') and resource ('media file'), clearly distinguishing it from sibling list/create/update/delete operations. The word 'single' differentiates it from vast42_list_media_files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the name and description: use this to retrieve one media file by ID. However, there is no explicit guidance on when to choose this over other media file tools, no exclusion criteria, and no mention of 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 says 'List all' but does not mention that the endpoint actually paginates via limit and offset, nor does it explain the return format or any read-only guarantees. This could mislead an agent into expecting a single non-paginated response.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no filler words. It is front-loaded with the verb and resource, making it immediately scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (two optional params, no output schema), the description is mostly adequate but incomplete. It could clarify that the operation returns a paginated list, and that 'all' refers to the collection of assignments rather than a single non-paginated response. Without annotations or an output schema, a bit more context would help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes both parameters (limit and offset) with clear descriptions, so the schema carries the semantic weight. The description adds no further detail beyond the action, but it does not conflict with the schema. Baseline of 3 is appropriate since schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and clearly identifies the resource as 'VAST 4.2 campaign assignments'. The version qualifier distinguishes it from other list campaign assignment tools, and the verb clarifies the action. It is concise and directly states the tool's primary function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing all campaign assignments in VAST 4.2, but provides no explicit guidance on when to use this tool versus alternatives like vast42_get_campaign_assignment for a single item or create/update/delete operations. It does not mention exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only says 'Get details', which is a minimal read operation statement but does not disclose behaviors such as error handling, whether the channel must be in archived state, permissions, or any side effects. The description adds little beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the verb and resource. Every word is necessary and there is no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema. The description explains the purpose and resource but does not specify what 'details' includes, which would be helpful given the lack of an output schema. It is minimally adequate for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% as the only parameter 'id' is described as 'Archived VAST channel ID'. The description does not add any additional parameter context beyond the schema, so the baseline of 3 is appropriate given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get details') and the resource ('a specific archived VAST channel'). It distinguishes from siblings by explicitly noting 'archived' and 'specific', aligning with the by-id operation implied by the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving a single archived channel by ID, but it does not explicitly state when to use this tool over alternatives such as vast_list_archived_channels or vast_get_channel. No exclusions or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the burden. The verb 'Get' implies a read-only operation and 'details' suggests the full campaign record is returned, but the description does not disclose error behavior, authentication needs, or what fields the details include.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single seven-word sentence, front-loaded with the verb and containing no filler. 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.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with one well-documented parameter, the description is mostly sufficient. However, it does not clarify the distinction from archived campaigns or describe the return structure, which is a notable gap given there is no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'id' is fully described in the schema as 'VAST campaign ID', providing 100% coverage. The description adds no further meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the operation ('Get'), the resource ('VAST campaign'), and the scope ('specific'), which clearly distinguishes it from list, create, update, and delete siblings. The 'VAST' qualifier separates it from the generic get_campaign 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/5Does 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 vast_get_archived_campaign, vast_list_campaigns, or the non-VAST get_campaign. The description only states what it does, leaving contextual decisions entirely to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. The word 'all' contradicts the pagination parameters in the schema (limit/offset), suggesting the tool may not actually return all results in a single call. It does not explicitly state that this is a read-only operation or disclose pagination behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the tool's purpose. No unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with well-documented parameters, but the description lacks information about pagination behavior, return format, or when to use this over similar tools. The 'all' vs pagination ambiguity creates a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes both parameters (limit and offset) with 100% coverage, so the description does not need to add parameter details. The description adds no additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all archived VAST channels' clearly identifies the action (list) and resource (archived VAST channels). It distinguishes from sibling tools like vast_list_channels by explicitly specifying 'archived'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is for listing archived channels but provides no explicit guidance on when to use this tool vs alternatives like vast_list_channels or list_archived_channels. No exclusions or alternative references 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 only says 'List all VAST media' but omits that this is a read-only operation and that results are paginated via limit/offset. The word 'all' is potentially misleading because the schema has a default limit of 100, implying not all items are returned in a single call.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately conveys the tool's purpose. There is no superfluous information, and it is appropriately front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with two optional parameters and no output schema, the description is mostly adequate, but it lacks important contextual details. It does not clarify pagination behavior, what fields are returned, or that 'all' is subject to the default limit. The lack of an output schema makes some of this information more critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the two parameters (limit and offset) with clear descriptions, so the description adds no additional parameter semantics. Baseline of 3 is appropriate given 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 ('VAST media'), and specifies the scope ('linear and non-linear'), which distinguishes it from sibling tools like vast_list_linear_media and vast_list_non_linear_media that focus on individual types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool covers both linear and non-linear media, offering a consolidated listing compared to the type-specific siblings. However, it does not explicitly state when to use this tool over alternatives, nor does it mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 state change (archived to active) but does not disclose any side effects, prerequisites, reversibility, or error conditions. For a mutation tool, this 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence conveying the action and resource without unnecessary words. It is concise and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one parameter, full schema coverage, and no annotations or output schema, the description is adequate for a simple operation. However, it lacks usage guidance, behavioral notes, and clarity on return values, so it is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully documents the sole parameter 'id' with the description 'Archived VAST channel ID' (100% coverage). The description does not add any extra meaning beyond what the schema provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Restore') and clearly identifies the resource ('VAST channel') and the target state ('active status'). It distinguishes from sibling tools like 'vast_archive_channel' and the non-VAST 'unarchive_channel' by explicitly naming 'VAST channel'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (if you have an archived VAST channel and want to restore it, use this tool) but provides no explicit guidance on alternatives or exclusions. It does not mention related tools like 'vast_list_archived_channels' or note when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral context, but it only states the creation action. It does not mention required permissions, side effects, return values, or any constraints beyond what the name implies, leaving the agent without important safety or workflow 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the verb and resource. It contains no filler words and every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 parameters, nested objects, and no output schema, the one-line description is insufficient. It does not explain the zone creation workflow, required fields beyond schema, expected response, or how this zone type integrates with the email serving system.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds no parameter-specific information, relying entirely on the schema for field meanings. It doesn't highlight any parameter relationships or domain-specific interpretation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Create' with the resource 'email zone', making the action unambiguous. It further clarifies the zone's purpose for 'serving ads in email newsletters', which distinguishes it from sibling tools like create_zone or vast_create_zone that target other zone 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'email newsletters' provides clear context for when this tool should be used, differentiating it from general zone creation tools. However, it does not explicitly state when not to use this tool or name alternatives, so it lacks exclusion 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It simply states 'Delete' without indicating whether the deletion is permanent, whether it can be undone, whether any prerequisites exist, or what side effects may occur. Destructive operations require more explicit warnings.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that begins with the action verb. It communicates the purpose efficiently with no unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no annotations and no output schema, the description is too minimal. It lacks important behavioral context such as permanence, reversibility, or any conditions that might cause the deletion to fail. The description only covers the basic action without warning the user about the consequences.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with clear descriptions for both parameters ('Image asset ID' and 'ORTB native template ID'). The description does not add any additional meaning beyond what the schema already states, so it meets the baseline but adds no extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete'), the resource ('image asset'), and the scope ('from an ORTB native template'), making it easy to distinguish from sibling tools like delete_ortb_native_title_asset or update_ortb_native_image_asset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does 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—when an image asset needs to be removed from an ORTB native template. It does not explicitly mention alternatives or exclusions, but the context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the burden of behavioral disclosure. It only says 'update', which implies mutation, but does not explain draft workflow semantics (e.g., changes are staged until saved), whether partial updates are supported, or any permission/reversibility details. This is a significant gap for a mutating 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the verb and resource. There is zero wasted text, and it is appropriately concise for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a nested 'draft' object with additionalProperties allowed, yet no examples or enumeration of valid fields are provided. It also lacks any mention of return values or the draft-save workflow. Given the potential ambiguity and no annotations, the description is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters have descriptions in the schema (id as 'Draft ad item ID', draft as 'Object containing custom HTML ad item fields to update'), so schema coverage is high. The description adds no extra detail about accepted fields or id formats, keeping the score at the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an existing draft custom HTML ad item' clearly states a specific verb ('update') and a specific resource ('draft custom HTML ad item'). It distinguishes itself from siblings like draft_create_custom_html_ad_item, draft_get_custom_html_ad_item, and draft_delete_custom_html_ad_item.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Clear context is provided by the qualifier 'draft'—indicating this tool is for draft ad items. However, it does not explicitly contrast with the non-draft sibling update_custom_html_ad_item or mention when not to use it. This is clear context without exclusions, so a 4 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?
No annotations are provided, so the description carries the full burden of disclosing behavioral traits. It only mentions the HTTP method and that it retrieves an ad, omitting any details about response format, whether it is read-only, authentication requirements, or server-side request constraints. The schema notes some required fields but the description itself adds little 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences: the first states the purpose, the second the key differentiator from serve_ad. Every word earns its place, with no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 16 parameters, no output schema, and no annotations, yet the description provides minimal context. It does not describe the return value, error behavior, or the practical context of ad serving. The referral to serve_ad helps only if the agent already knows serve_ad, but the description is insufficient on its own for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all 16 parameters with descriptions (100% coverage), so the schema already carries the parameter semantics. The description adds no additional parameter-specific meaning beyond a weak cross-reference to serve_ad's parameter set, which does not compensate for any gaps since none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves an ad via a GET request, using a specific verb and resource. It explicitly contrasts with serve_ad ('Same parameters as serve_ad but uses GET instead of POST'), distinguishing it from the most similar sibling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a direct comparison to serve_ad, telling the agent that this tool is the GET variant of serve_ad. This implies when to use it (when GET is needed) and clearly differentiates from serve_ad, though it does not discuss other alternatives or explicit 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 of behavioral disclosure. It only says 'Get details' and does not mention whether the operation is read-only, behavior when the channel doesn't exist, or any permission requirements. It adds no behavioral context beyond the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action ('Get') and the resource ('details of a specific archived channel'). There is no unnecessary text, making it easy to parse and understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID operation with one parameter and no output schema, the description conveys the essential purpose adequately. However, it lacks contextual details such as how the response differs from get_channel or any special considerations for archived channels, leaving it slightly incomplete but still functional.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the single parameter 'id' with a description ('Archived channel ID'), giving 100% schema coverage. The tool description adds no additional parameter information, but the baseline of 3 applies given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and identifies a precise resource ('details of a specific archived channel'), clearly distinguishing it from sibling tools like list_archived_channels (which lists many) and delete_archived_channel (which removes). It unambiguously conveys the operation's scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives such as get_channel for active channels or list_archived_channels. The intended context is implied by the 'archived' qualifier, but no explicit when-to-use or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states 'Get details'; it does not disclose authentication needs, response shape, error behavior, or any other behavioral traits beyond the read-only implication of the 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence communicates the tool's purpose with no redundant or irrelevant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity get-by-id tool with complete parameter coverage, the description is adequate, though the lack of an output schema leaves exact return details unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter 'id' described as 'Creative ID'. The description adds no additional meaning beyond what the schema already provides, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' and identifies the resource 'audio creative', clearly distinguishing it from sibling tools like list_audio_creatives or create_audio_creative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'specific audio creative' implies usage when retrieving one record by ID, but it offers no explicit guidance on when not to use it or mentions alternatives such as list_audio_creatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral burden. It only restates that this is a read operation ('Get') without mentioning permissions, error behavior, side effects, or rate limits, leaving important transparency 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It efficiently conveys the action, target, and selection criterion.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter getter, the description is reasonably complete: it identifies the resource and how to select it. The word 'details' loosely implies the return value, though the exact response structure is not described and no output schema is provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully documents the id parameter with a description and 100% coverage. The tool description adds no extra meaning beyond restating that lookup is 'by ID', so it provides minimal value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the operation ('Get details') and target resource ('specific data list') with the required ID. It distinguishes itself from list_data_lists by focusing on retrieving a single item rather than a collection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by ID' implies this tool is for fetching a single known data list, which is useful context. However, it does not explicitly name alternatives such as list_data_lists or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the transparency burden. The verb 'Get' implies a read operation and 'ad serving tag' hints at the returned artifact, but it does not explicitly state that the operation is safe, what permissions are needed, or what the response format looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded declarative sentence that conveys the action, target resource, and result without any filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter retrieval tool, the description is largely sufficient: it identifies what to fetch (ad serving tag) and from which entity (email zone). However, with no output schema, a brief note about the tag format or usage context would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage for the single parameter is 100% (id: 'Email zone ID'). The description merely repeats 'email zone' and adds no additional meaning or usage details beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and clearly identifies the resource ('email zone') and the object ('ad serving tag'). This distinguishes it from sibling tools like get_email_zone_conversion_tag, get_zone_tag, and get_catalog_zone_tag.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as get_email_zone_conversion_tag or get_zone_tag. There are no prerequisites, exclusions, or context cues about when this tag is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. 'Get details' clearly implies a read-only operation with no side effects, but it does not mention potential 404 errors, permission requirements, or response structure. This is adequate for a simple getter but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the tool's purpose without any fluff. It is appropriately sized for a simple getter and front-loads the key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter getter with no output schema, the description plus fully documented schema parameters provide sufficient context to understand the operation. However, it does not describe the return value details, which could be helpful but is not critical for a basic retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond the schema; it says 'specific data asset' and 'ORTB native template' which broadly maps to the id and template_id parameters, but the schema already documents these as 'Data asset ID' and 'ORTB native template ID'. No extra context is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Get details), the resource (specific data asset), and the context (for an ORTB native template). It distinguishes from sibling tools like get_ortb_native_image_asset and get_ortb_native_title_asset by specifying 'data asset'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that list_ortb_native_data_assets should be used for listing all data assets, or that this tool is for retrieving a single specific asset by ID. No exclusions or alternative tools are 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, the description must carry the behavioral disclosure. The verb 'Get' indicates a read operation, providing some transparency, but it offers no details about the tag's format, required permissions, or any side effects. For a simple getter this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that directly states the action and object. There is no redundant information or filler, making it highly concise and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with one well-documented parameter and no output schema, the description adequately tells the agent what to retrieve and for which entity. It lacks details about the return value structure, but that is not required given the simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (the only parameter 'id' is described as 'Ad item ID'). The description adds no parameter-specific meaning beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and identifies the precise resource 'conversion tracking tag for a rich media ad item'. This clearly distinguishes it from sibling conversion-tag tools for other ad item types (e.g., image, custom HTML, native, vast).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given for when to use this tool versus alternatives. The description only names the resource type, which implies usage context but does not exclude other conversion-tag tools or mention any conditions/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 of behavioral disclosure. It merely states 'List all archived advertisers' without mentioning read-only nature, pagination behavior, authentication, or other traits. It adds no information beyond the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no redundant words. It is perfectly concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with pagination, the description sufficiently conveys the core purpose, and the schema covers the parameters. However, the lack of an output schema and absence of any response format details means the agent must infer return structure, though it is generally predictable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the limit and offset parameters (100% coverage). The description adds no additional parameter semantics, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all archived advertisers' uses a specific verb and resource, clearly indicating it returns archived advertisers. It distinguishes from sibling tools like list_advertisers and list_archived_campaigns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives such as list_advertisers for active advertisers. Usage is implied by the name but not explicitly stated, so it meets the 'implied usage' baseline.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 'List all contacts' without mentioning pagination behavior, response format, authentication needs, or any side-effect-free nature. This leaves significant behavioral traits undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that contains no fluff or redundancy. Every word contributes to the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with only two optional pagination parameters and no output schema, the description is mostly sufficient. It clearly states the resource and scope, and the schema covers parameter details. However, the lack of annotation or explicit mention of pagination limits leaves a small gap, preventing a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters (limit and offset), and the schema already documents their purpose and defaults. The description adds no additional parameter semantics beyond what the schema provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('contacts') with an explicit scope ('in your AdButler account'). It distinguishes itself from sibling tools like get_contact, create_contact, update_contact, and delete_contact by clearly indicating this is the bulk retrieval 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving all contacts in an account, but it does not explicitly state when to use this tool versus get_contact for a single contact or provide any exclusions. The context is clear enough for basic selection, but there is no explicit alternative 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?
With no annotations, the description carries the full burden of behavioral disclosure. It says 'List' which implies a read-only operation, but it does not disclose details like whether this returns a flat list, supports pagination (though limit/offset are in the schema), or includes archived configurations. The description adds minimal behavioral context beyond the name itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the action and resource. No unnecessary words or repetition. It earns its place with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with two optional parameters fully documented in the schema, the description is nearly complete. It does not explain return values, but no output schema exists, and the purpose is clear. The only gap is not clarifying the scope (e.g., non-VAST) given the presence of list_vast_custom_reports as a sibling, but this is a minor omission for a simple listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters (limit and offset). The description adds no additional parameter meaning, so the baseline of 3 applies. The schema already documents the parameters adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 (saved report configurations). It distinguishes itself from related sibling tools like get_custom_report (single fetch) and list_vast_custom_reports (VAST-specific) by focusing on all saved configurations. The verb is specific and the scope is explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: when you need to list saved report configurations, this is the tool. However, it does not explicitly mention alternatives or when not to use it (e.g., for VAST-specific reports, use list_vast_custom_reports). No exclusions or context are provided, leaving the agent to infer from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It indicates a read-only listing operation, but does not disclose behaviors like whether archived or inactive media groups are included, ordering, or potential access restrictions. Minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with a useful parenthetical definition. Every word earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple paginated list operation, the description plus schema is largely sufficient. However, there is no output schema, and the description does not describe the shape of the returned media group objects, so completeness is not a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters (limit, offset) with descriptions, so the baseline is 3. The tool description adds no additional parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List'), identifies the resource ('media groups'), and adds a clarifying parenthetical ('collections of creatives') that defines the domain concept. It clearly distinguishes this tool from get_media_group and the create/update/delete siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 whether to use this instead of get_media_group for a single item, or how it relates to list_creatives, which is a key sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 of behavioral disclosure. It merely says 'Update' without stating whether the operation is a partial or full update, what permissions are required, how errors are reported, or what the response contains. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that directly communicates the tool's purpose without any redundancy or extraneous detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a nested attributes object and no output schema or annotations, yet the description provides no guidance on partial update behavior, how to construct the attributes object, or the expected response. This is insufficient for reliable invocation in all cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all four parameters, including descriptions for id, name, attributes, and user_db_id. The tool description adds no additional semantic context beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Update an existing audience in a user database' with a specific verb and resource. The word 'existing' clearly distinguishes it from create_audience, and 'audience' is an unambiguous resource among the many siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies this tool is for modifying an existing audience, but it does not explicitly mention when to use create_audience for new audiences or get_audience for reading. It provides clear context but lacks explicit alternatives 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 bears the full burden of disclosing behavioral traits. It only states 'Get', which is already implied by the tool name, and provides no additional information about error handling, response structure, authentication, or side effects. This is a significant gap for a tool with zero annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence of six words. It is appropriately sized for a simple getter tool, and the key information ('Get', 'single', 'VAST 4.2 companion') is front-loaded with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter, no output schema, and no annotations, the description is sufficient for basic retrieval but lacks contextual details such as what a 'VAST 4.2 companion' is or what data the response contains. However, the low complexity justifies a high completeness score, as the core purpose is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides a complete description for the single parameter ('VAST 4.2 companion ID'), so schema coverage is 100%. The tool description adds no extra semantic value beyond what the schema already describes, meeting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation ('Get') and the specific resource ('a single VAST 4.2 companion'), distinguishing it from sibling tools like vast42_list_companions (returns multiple) and vast42_create_companion (creates a new one). The scope ('single') indicates retrieval by a specific ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need a specific companion by ID, but it does not explicitly state when to use this tool versus list/get alternatives, nor does it mention exclusions or prerequisites. The guidance is minimal and indirect.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 does not mention what happens for non-existent IDs, response format, authentication needs, or any other behavioral traits beyond the basic retrieval 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no redundant information. It is concise and effective for a simple get-by-ID tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, read-only, no output schema), the description provides sufficient information for an agent to invoke it correctly. It could mention error behavior or prerequisites, but those are minor gaps for this straightforward action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers the only parameter (id) fully with a description 'VAST tracking ID'. The description adds no additional meaning beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 VAST tracking entry), distinguishing it from sibling tools like vast_list_tracking, vast_create_tracking, and vast_delete_tracking. It is precise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The verb 'Get details' implies usage when retrieving a specific tracking entry, but there is no explicit guidance on when to use this tool versus alternatives or any exclusions. The context is implied rather than 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. It states the core state change but does not disclose side effects, permissions, idempotency, failure behavior, or whether the zone must currently be archived. This is minimal for a mutating 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence, no filler, front-loaded with the action. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple tool with one parameter, no output schema, and no annotations. The description, along with the parameter schema, adequately covers the core information a user needs to understand and invoke the operation, though it could note potential errors or response behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description covers 100% of the single parameter 'id' as 'Archived VAST zone ID'. The description adds no additional parameter meaning, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Restore') and clearly identifies the resource ('an archived VAST zone') and the resulting state ('back to active status'). It distinguishes this from related sibling tools like vast_archive_zone, vast_list_archived_zones, and vast_delete_archived_zone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: when you have an archived VAST zone and want to make it active again. However, it does not explicitly state when to prefer this over similar tools (e.g., unarchive_zone for non-VAST zones, or vast_unarchive_campaign) or mention any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description is the sole source of behavioral information. 'Get' clearly indicates a read-only operation, but the description does not disclose return format, null behavior, or error conditions. The simple read nature is clear, but deeper context 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no unnecessary wording. It efficiently communicates the tool's purpose without redundancy or digression.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema and annotations, the description does not fully explain what is returned or what 'active' means. However, for a simple getter with one well-documented parameter, the description is minimally adequate; it could be improved by specifying the return behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'id' is fully described in the schema as 'Contract ID' (100% coverage). The description adds negligible semantic value beyond the schema, only restating that the request is for a contract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and a distinct resource ('the active signature request for a contract'), clearly differentiating it from siblings like get_signature_request and list_signature_requests. It states exactly what the tool does without 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when one needs the active signature request for a given contract, but it does not explicitly mention when to use this tool over alternatives or list any prerequisites. No exclusions or alternative tool names are provided, so guidance is implied rather than 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 of behavioral disclosure. It only says 'Get details' and 'by ID', but does not mention the return format, potential errors, authorization requirements, or any side effects. This is minimal behavioral information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with a clear verb-object structure. It is front-loaded and every word contributes to the meaning, with no filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description is adequate for a basic get-by-ID operation. However, it does not clarify what 'details' means or specify any constraints, leaving some ambiguity about the response content.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single 'id' parameter, and the description simply repeats 'by ID' without adding any new meaning. The baseline of 3 applies because the schema already documents the parameter sufficiently.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get'), names the exact resource ('OpenRTB native template'), and scopes it clearly ('by ID'). It distinguishes well from sibling tools like list_ortb_native_templates, create_ortb_native_template, and get_ortb_native_image_asset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly implies the usage: when you need details of a specific template and have its ID. However, it does not explicitly mention alternatives or when not to use this tool, so it falls short of a 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 the full burden. 'Get details' implies a read-only operation, but the description does not disclose what 'details' includes, error behavior, or any side effects. It adds minimal context beyond the action itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, efficient sentence with the verb front-loaded and no wasted words. It is concise and clearly structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with one required parameter, the description is minimally adequate, but with no annotations and no output schema, it lacks detail on the return structure, error cases, and any special behavior. It is sufficient for basic invocation but leaves gaps for edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the single 'id' parameter with a description ('Platform target ID'), achieving 100% coverage. The description adds no additional meaning about the parameter format, source, or constraints beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 'platform target', and 'specific' indicates retrieval of a single entity by ID. This distinguishes it from list_platform_targets and other get_* target 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when you have a known platform target ID, but it does not explicitly mention when to use this tool vs list_platform_targets or provide any exclusions. No explicit guidance on preconditions or alternatives is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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. The verb 'Get' strongly implies a read-only operation, and no side effects are mentioned, which is a safe profile. However, the description does not explicitly confirm read-only behavior, error handling, or any edge cases. It is minimally transparent but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence of 10 words. It is front-loaded with the action verb and resource, with zero wasted words. Every word contributes to the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two fully documented parameters, but there is no output schema. The description says 'details' without specifying what those details include, which could leave the agent uncertain about the response. For a simple getter, this is adequate but could be richer with a brief mention of return content. The lack of annotations and output schema makes the description the only source of context beyond the request schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of the parameters with descriptions ('ORTB native ad ID' and 'Standard zone ID'). The description does not add additional meaning beyond the schema, which is acceptable given the high schema coverage. The terms 'specific ORTB native ad' and 'standard zone' loosely map to the parameters but add no new semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') with a clear resource ('details of a specific ORTB native ad') and context ('for a standard zone'). This unambiguously distinguishes the tool from sibling list/create/update/delete operations on the same resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving a single ad by ID within a specific zone, but it does not explicitly state when to use this versus alternatives like list_zone_ortb_native_ads, nor does it mention exclusions or prerequisites. The context is clear from the wording but no direct comparison 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 must disclose safety and behavioral traits. It says 'List all' but doesn't confirm read-only status, pagination behavior (the schema includes limit/offset), or response format. The term 'all' is ambiguous given pagination defaults, and no side effects or error conditions are mentioned, leaving a transparency 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to the purpose, making it highly concise and well-structured for a list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema or annotations, the description carries the burden of explaining context. It covers the core purpose but omits pagination nuances, response shape, and validation requirements for template_id. It is adequate for a basic list tool but leaves clear gaps in operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes all three parameters (template_id, limit, offset) with 100% coverage. The description adds no parameter-specific context, but the schema already documents the semantics fully, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'List all title assets for an ORTB native template' – a specific verb (list) with a clear resource (title assets) and scope (per template). This distinguishes it from sibling tools like get_ortb_native_title_asset (single asset) and create/update/delete title asset tools, as well as other asset-type 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'list all' phrasing implies use when multiple title assets are needed for a template, which differentiates it from the single-getter sibling. However, it does not explicitly state alternatives or exclusions (e.g., when to use get_ortb_native_title_asset instead), so it lacks an explicit when-to-use comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It only says 'List all product sources', implying a read-only operation, but does not disclose pagination behavior (limit, offset, max 100), default ordering, or whether archived sources are included. This is a gap given the schema shows pagination 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler or redundancy. It is appropriately concise for the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description provides the core purpose but omits important contextual details such as response shape, pagination defaults, and the relationship to other product-source tools. It is adequate but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all three parameters (publisher_id, limit, offset) with clear descriptions. The tool description adds no additional parameter meaning beyond restating the publisher scoping.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List'), a clear resource ('product sources'), and a scoping phrase ('for a publisher'). It distinguishes itself from siblings like get_product_source (single item) and list_product_source_targets (different 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: use this tool when you need all product sources belonging to a publisher. It does not explicitly name alternatives (e.g., get_product_source for a single source) or exclusions, but the intent is unambiguous.
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 correctly implies a read-only listing operation and specifies the publisher scoping, but it does not disclose pagination behavior, and the word 'all' may overstate results given the limit/offset parameters. It omits details like whether archived targets are included or any permissions/rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to understanding the tool's core purpose, making it highly concise and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple, and the schema covers parameters, but there is no output schema and no description of the return format or pagination behavior. The phrase 'list all' could mislead an agent into expecting a single complete response rather than a paginated list, leaving notable gaps for a robust tool description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are already well-documented. The description adds only minimal context by highlighting 'for a publisher' as the key filter, but it does not provide extra meaning about limit or offset semantics beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List'), a distinct resource ('product source targets'), and a clear scope ('for a publisher'). It distinguishes itself from sibling tools like list_product_sources (different resource) and get_product_source_target (singular retrieval), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you need all product source targets for a publisher) but does not explicitly state when to use it over alternatives such as list_product_sources or get_product_source_target, nor does it mention any exclusions or edge 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 must disclose behavioral traits. It only states 'List generated reports' with no mention of return format, pagination behavior, or any side effects. The read-only nature is implied but not explicit, and there is no information about what constitutes a generated report.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core operation without wasted words. It is 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with no output schema, the description provides the essential scoping but omits context about how generated reports are identified, what fields are returned, and how this tool differs from list_all_generated_reports or get_report_generated. The absence of such details leaves the agent with questions about the response shape and edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema documents all three parameters with descriptions (100% coverage), so the baseline is 3. The description adds minimal reinforcement of report_config_id as the scoping parameter but no additional semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and identifies both the resource ('generated reports') and the scoping constraint ('for a specific report configuration'), clearly distinguishing it from siblings like list_all_generated_reports. It is unambiguous and specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies usage when you have a specific report_config_id and need its generated reports, providing clear context. However, it does not explicitly name alternatives or state when not to use it, so it stops short of a 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?
No annotations are provided, so the description carries the full burden. 'List schedules' indicates a read-only operation, but the description does not disclose behavioral details such as whether it returns only active schedules, pagination behavior, or access requirements. It is not misleading, but it adds limited depth beyond the 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no redundant words. It states the core action and scope efficiently, earning a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the schema covers parameters, but the description does not clarify how it differs from the many similar schedule-related sibling tools (list_all_report_schedules, list_report_schedule_generated, etc.). It lacks any mention of pagination or result scope beyond the config filter, making it minimally adequate but not fully complete for an agent navigating a large sibling list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters (report_config_id, limit, offset) are already documented. The description's 'specific report configuration' echoes the required parameter but does not add additional meaning or clarify the behavior of limit/offset beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List'), identifies the resource ('schedules'), and scopes it ('for a specific report configuration'), which clearly distinguishes it from broader siblings like list_all_report_schedules. The 'specific report configuration' phrasing directly maps to the required report_config_id parameter, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a usage context (querying schedules for a particular configuration) but does not explicitly contrast with alternatives such as list_all_report_schedules or list_report_schedule_generated. It lacks clear when-to-use/when-not-to-use guidance, though the scope is partially implied by 'for a specific report configuration'.
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. The verb 'List' implies a read-only operation, but the description does not disclose potential errors, pagination behavior, or whether special permissions are needed. It is minimally transparent but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise, front-loaded sentence that immediately conveys the action and object. There is zero wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter list operation, the description states the purpose adequately. However, with no output schema or annotations, it lacks details about the return structure, edge cases (e.g., empty recipient list), and the relationship between contract_id and request_id. A bit more context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for both parameters (contract_id and request_id), so the description does not need to explain them. It adds no extra meaning beyond the schema, which is acceptable given the high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all recipients for a signature request', using a specific verb ('List') and resource ('recipients') that distinguishes it from sibling tools like get_signature_request_recipient (singular) and list_signature_requests (lists requests, not recipients). The scope is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when/when-not guidance is given. The phrase 'List all recipients' implies a batch/listing use case versus getting a single recipient, but no alternatives are named. Usage is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It transparently states the tool lists user databases in the account, but it does not disclose pagination behavior despite the limit/offset parameters, which could make 'all' potentially misleading given the max 100 limit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the verb and resource. It contains no fluff or redundant wording, earning every word.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool, the description and schema are mostly sufficient. However, there is no output schema and the description does not clarify pagination or return shape, leaving minor gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides full descriptions for limit and offset (100% coverage). The description adds no additional parameter semantics, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all user databases in your AdButler account' uses a specific verb ('List'), specifies the resource ('user databases'), and scopes it to the account. It clearly distinguishes itself from sibling tools like get_user_db and create_user_db by indicating a collection-listing operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its use case by stating it lists all user databases, so an agent can infer when to call it. However, it provides no explicit guidance on when to use it versus alternatives (e.g., get_user_db for a single database) or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only says 'resend the email verification code' and implies an email is sent, but does not disclose side effects (e.g., whether the previous code is invalidated), prerequisites (e.g., the trial account must exist and be unverified), rate limits, or failure 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the core action and followed by a practical use case. Every word earns its place; there is no repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description covers the basic purpose and usage context. However, it lacks caveats such as whether the email must belong to an existing unverified trial account or what happens if the resend fails, which would be valuable for full contextual completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage for the single parameter, including a clear description ('The email address used to create the trial account'). The tool description adds no additional parameter-level detail, so it does not elevate beyond the baseline provided by the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Resend') and names the exact resource ('email verification code for a trial account'). It clearly distinguishes this tool from sibling tools like verify_trial_email (which verifies the code) and create_trial_account (which creates the account).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'if the user did not receive the code or it expired.' It does not mention when not to use it or name alternatives, but the trigger conditions are clear enough for an agent to select it 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 must carry the full burden. It says only 'Configure AdButler with an existing API key,' but does not disclose what 'configure' entails—e.g., whether it validates the key, persists it, makes network calls, or overwrites existing settings. This leaves behavioral ambiguity for a mutation-like setup 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the purpose, and includes usage context. Every sentence earns its place with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter tool with no output schema or annotations, the description covers the primary use case. However, it omits any mention of what happens after configuration (e.g., key storage, validation, or error handling), leaving an agent to infer the tool's side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with api_key described as 'The AdButler API key.' The description adds no extra semantic detail beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Configure AdButler with an existing API key') and specifies the resource and object. It also distinguishes from account creation tools by noting 'if the user already has an AdButler account and API key,' setting it apart from siblings like create_trial_account.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'if the user already has an AdButler account and API key.' This provides clear context and implies the alternative (e.g., create_trial_account) for users without an account, though it does not name an explicit alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only says 'Update an existing image creative,' which is the operation itself. With no annotations provided, it does not disclose whether it performs a partial or full update, what happens if the creative ID does not exist, or whether changes affect live campaigns. This is insufficient behavioral transparency 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise statement that immediately conveys the tool's function. No filler or redundant information is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-parameter update tool, the description is minimally adequate: it names the resource and operation. However, it lacks contextual guidance on how to obtain the creative ID, whether name and description are both updatable in one call, or how this differs from related replace_* operations. Given the simple nature, this is acceptable but leaves some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents all three parameters with descriptions (Creative ID, name, description), achieving 100% coverage. The tool description adds no additional parameter-level meaning beyond what the schema provides, so it meets the baseline for schema-covered parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates an existing image creative, specifying both the action (update) and the resource type (image creative). This distinguishes it from sibling tools like update_rich_media_creative or update_video_creative, which handle other creative types, and from create_creative/delete_creative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use this tool: for updating an existing image creative. It does not explicitly mention alternatives or exclusions, but the 'image creative' qualifier and the 'existing' phrasing adequately guide selection among the many update_*_creative options. It could be improved by naming alternatives like create_creative or replace_image_creative_file for other scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only says 'List all', which implies read-only, but it doesn't mention pagination behavior, default/max limits, ordering, or any other side effects or constraints. The schema hints at limit/offset, but the description doesn't explain how these affect results or whether all items are returned in one call.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler or redundant information. It is appropriately sized for a simple list operation and every word earns its place. No structural issues.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only two parameters and no output schema, so completeness burden is moderate. The description explains what the tool does, but misses important context: 'all' conflicts with pagination (limit defaults to 100, max 100), which may mislead an agent into thinking all items are returned in one call. No mention of what a mezzanine is in this VAST 4.2 context, though sibling tools provide some inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (limit and offset both have descriptions), so the baseline is 3. The description adds no additional parameter context, such as default values or interaction between limit and offset, but the schema already provides the core semantics. No credit beyond baseline is warranted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all VAST 4.2 mezzanines' uses a specific verb ('List') and clearly identifies the resource ('VAST 4.2 mezzanines'). It distinguishes this tool from sibling tools like vast42_get_mezzanine (single item) and vast42_create_mezzanine (creation), and from other vast42_list_* tools for different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'List all' provides clear context for when to use this tool: when you need to enumerate mezzanines. It doesn't explicitly exclude alternatives, but the scope is evident from the description and sibling names. No explicit when-not-to-use, but clarity is sufficient for a straightforward list operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It discloses that deletion is permanent and targets archived channels, but it does not mention required state (must be archived), side effects on related data (e.g., zone assignments), or permissions. Minimal but non-misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the action and target. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with one parameter, this is minimally complete: it states the action is permanent and targets an archived channel. However, it lacks explicit prerequisites (e.g., 'channel must be archived') and outcome details, which would improve completeness for a destructive operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the single parameter 'id' with the description 'Archived VAST channel ID'. The tool description adds no additional parameter semantics, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('permanently delete') and resource ('archived VAST channel'), clearly distinguishing it from siblings like vast_delete_channel and vast_unarchive_channel. It unambiguously states 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The name and description imply the tool is for archived channels, but there is no explicit guidance on when to use this versus vast_delete_channel or whether the channel must be archived first. Usage context is implicit rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosure. It explicitly states the operation is permanent, which is a critical behavioral trait, but it does not detail any prerequisites (e.g., zone must be archived), potential side effects on associated data, or permission requirements. The disclosure is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly worded sentence that front-loads the action and target. There is no filler or redundant information, earning every word its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with one parameter and no output schema, the description conveys the core purpose. However, it omits important contextual details like the requirement that the zone must already be archived and what happens to any associated entities, which could lead to errors if called in the wrong state. Given the tool's simplicity, slightly more context would make it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage with the parameter description 'Archived VAST zone ID', so the baseline is 3. The tool's description adds no additional parameter semantics beyond what the schema states, such as format or source of the ID.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('delete'), the resource ('archived VAST zone'), and the irreversibility ('permanently'). This distinguishes it from sibling tools like vast_delete_zone (which likely targets active zones) and vast_archive_zone (which archives rather than deletes).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for deleting zones that are already archived, but does not explicitly say when to use it over alternatives such as vast_delete_zone or vast_unarchive_zone. No exclusions or prerequisites are provided, leaving the agent to infer the intended use case from the name and 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?
No annotations are provided, so the description carries the full burden. The verb 'Get' strongly implies a read-only operation, but the description discloses no error behavior, response format, or authentication requirements. It is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, front-loaded with the core purpose. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the description omits key context: it does not clarify that it applies to active zones as opposed to archived ones (vast_get_archived_zone exists as a sibling), and with no output schema, it doesn't indicate what 'details' are returned. It is minimally viable but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the only parameter `id` as 'VAST zone ID' (100% schema coverage). The description adds no extra meaning beyond saying 'specific VAST zone', which doesn't enrich the parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get details of a specific VAST zone' clearly identifies a retrieval operation for a single entity. It distinguishes from sibling list tools (vast_list_zones) and mutation tools (vast_create_zone, vast_update_zone).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The word 'specific' implies this tool is for fetching one zone by ID, but the description provides no explicit guidance on when to use it vs alternatives like vast_get_archived_zone or vast_list_zones. No exclusions or alternative recommendations are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose a key behavioral trait (soft-delete and restorability), which is valuable, but it omits other context such as whether the channel is still visible in active lists, if any side effects occur, or the mechanism for restoration. The disclosure is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with a clarifying parenthetical. It is front-loaded with the action and immediately provides key context about reversibility, with no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description is mostly complete: it states the action and the reversible nature. It does not mention the associated unarchive workflow, but the sibling tool names (unarchive_channel, list_archived_channels) fill that gap. Overall, it is sufficient for the tool's scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes the single parameter 'id' as 'Channel ID' with 100% coverage. The tool description adds no parameter-specific details, but since the schema already covers it, the baseline of 3 is appropriate. There is no need for the description to replicate schema information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Archive a channel') with a specific resource and verb, and the parenthetical 'soft-delete, can be restored later' distinguishes it from a hard delete (delete_channel) and aligns with unarchive_channel. This leaves no ambiguity about 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through 'soft-delete, can be restored later'—suggesting it's for temporary removal rather than permanent deletion—but it does not explicitly name when to use this versus alternatives like delete_channel or unarchive_channel. The guidance is implicit, not explicit.
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. The word 'permanently' clearly communicates irreversibility, which is a critical behavioral trait for a delete operation. However, it does not disclose potential side effects, required permissions, error behavior, or what happens to associated entities; it only states the core destructive nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no superfluous words. It conveys the action, the target resource, and the permanence of the operation efficiently, earning its place fully.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter destructive tool with no annotations and no output schema, the description is sufficiently complete: it names the action, the exact target type, and the key consequence (permanence). It could mention prerequisites more explicitly, but the 'archived' qualifier already implies the primary precondition, and the schema covers the parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes the only parameter ('id' as 'Archived channel ID') with 100% coverage, so the description does not need to add parameter details. The tool description adds no additional semantic value beyond the schema, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Permanently delete') and a specific resource ('an archived channel'), clearly distinguishing it from related tools like archive_channel, unarchive_channel, and delete_channel. The qualifier 'archived' precisely scopes the tool's target.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'archived channel' implies the tool should only be used on channels that are already archived, which is useful contextual guidance. However, it does not explicitly mention alternatives (e.g., unarchive_channel to restore, or delete_channel for active channels) or provide exclusion criteria, so usage guidance remains implied rather than 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It merely states the action without mentioning read-only behavior, response format, error conditions, or any required permissions, offering minimal 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It efficiently communicates the tool's purpose and scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID tool with one fully documented parameter and no output schema, the description sufficiently covers the core functionality. It lacks behavioral details, but the low complexity and clear parameter description make it reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% as the 'id' property includes a clear description ('Draft ad item ID'). The tool description adds no additional parameter semantics beyond what the schema already provides, aligning with the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and identifies the resource as 'a draft ad item of any type by ID'. This clearly distinguishes it from type-specific sibling tools like draft_get_image_ad_item and draft_get_catalog_ad_item, as it explicitly covers any ad item type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'of any type' implies this is the generic getter for draft ad items, providing clear context for when to use it over type-specific getters. However, it does not explicitly name alternatives or state exclusions, so it falls short of the highest tier.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. 'Get details' clearly implies a read-only operation, but the description does not disclose any additional behavioral traits such as error handling, permission requirements, or the meaning of 'draft' in this context. It is honest but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, directly worded sentence with no filler or redundant information. It is appropriately sized for a simple getter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter getter with no output schema, the description is mostly complete. However, it could explicitly distinguish this from the non-draft get_catalog_ad_item or list variants. The name carries much of the context, so the gap is minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes the single parameter 'id' with 'Draft ad item ID' and has 100% coverage. The tool description adds no extra meaning beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' and identifies the resource as 'details of a specific draft catalog ad item'. This clearly distinguishes it from sibling tools like draft_list_catalog_ad_items, draft_create_catalog_ad_item, and the non-draft get_catalog_ad_item.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when you need details of a single draft catalog ad item), but it does not explicitly state when not to use it or mention alternatives like get_catalog_ad_item for non-draft items. Usage is implied rather than guided.
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 burden. 'Get details' indicates a read operation, but it does not disclose what fields are returned, error behavior for invalid IDs, or any other behavioral traits. This is adequate for a simple get-by-id but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-id tool with one parameter and no output schema, the description, combined with the informative name and schema, is reasonably complete. It identifies the resource uniquely, though it does not explain what details are returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the 'id' parameter already described as 'Archived zone ID'. The description adds no additional parameter meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' with the resource 'details of a specific archived standard zone', clearly distinguishing it from the VAST-specific sibling 'vast_get_archived_zone'. It states the resource and scope precisely.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied by the name and the word 'standard' to differentiate from VAST variants, but there is no explicit when-to-use versus alternatives or contextual guidance. It is clear but not explicitly contrasted with list_archived_zones or vast_get_archived_zone.
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 clearly indicates a read operation ('Get details'), but it does not mention behavior on not-found errors or whether the response contains partial or full details. For a simple getter, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. It is front-loaded with the verb and resource, and every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with one parameter and no output schema, the description is mostly complete. It explains the input (by ID) and implies the output (details). However, it could be slightly more explicit about return behavior or error cases, which is not critical for a standard CRUD read.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with the 'id' parameter well-documented as 'Contact ID'. The description reiterates 'by ID' but adds no extra meaning beyond the schema, which is acceptable given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get details of a specific contact by ID' clearly states the action (get), the resource (contact), and the scope (specific by ID). This distinguishes it from list_contacts and other contact-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a specific contact ID and need its details, but it does not explicitly mention when to use this over list_contacts or provide exclusions. The phrase 'specific contact' offers some differentiation, but no alternatives are 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?
No annotations are provided, so the description carries full responsibility. 'List' implies a read-only operation, but the description doesn't disclose additional behavioral details such as return format, pagination, or permissions. It is minimal and adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly conveys the tool's purpose without any filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read operation, the description is largely sufficient, though the lack of output schema means the agent doesn't know the exact return shape. The description covers the core functionality without extra complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents 'id' as 'Contact ID' with 100% coverage, so the description adds no new parameter semantics. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'List' with a specific resource 'report schedules' and scopes it to 'for a contact'. This clearly distinguishes it from generic list_report_schedules or other report schedule tools by indicating the contact 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a contact-related schedule listing is needed, but it doesn't explicitly name alternatives like list_report_schedules or get_report_schedule. No exclusions or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the behavioral transparency burden. It clearly indicates a read-only operation ('get details'), but it does not disclose any potential side effects, auth requirements, rate limits, or the content/format of the returned details. For a simple get operation this is minimal but adequate, though not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler or redundant information. It conveys the essential verb, resource, and type distinction efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one required parameter, no output schema) and the clear type specification ('image creative'), the description is largely complete. It could be slightly improved by mentioning what details are returned or behavior for missing IDs, but that is not essential for this simple getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% coverage for the single 'id' parameter, and the description adds no extra parameter semantics beyond implying that the ID identifies the specific image creative. Since schema coverage is high, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get details of a specific image creative' uses a specific verb ('get details') and identifies the resource ('image creative'), clearly distinguishing it from sibling tools like list_creatives, get_video_creative, or get_rich_media_creative. It is unambiguous and targeted.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by indicating you need a specific creative ID, but it does not explicitly state when to use this tool versus alternatives like list_creatives for browsing or other get_*_creative tools for non-image types. No exclusions or alternative tool references 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?
No annotations are provided, so the description carries the full burden. It only restates the tool name ('Get details') without disclosing read-only nature, response format, authorization needs, or side effects. The verb 'get' implies read-only, but the description adds no extra 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with verb and object, with no filler words. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema. The description sufficiently communicates the operation but could add certainty about the return value (e.g., returns the full configuration object). For its trivial complexity, it is complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: the single required 'id' parameter has a description ('Upload configuration ID'). The description does not mention parameters, but the schema fully documents them, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and a clear resource 'event log upload configuration'. The word 'specific' distinguishes it from list operations in the sibling tools. This is a clear verb+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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (for a specific configuration) but does not explicitly name alternatives like list_event_log_upload_configs. It provides clear context without exclusions or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description relies on 'Get' to imply a read-only operation, which is clear. However, it does not detail response content, potential errors, or any permissions required, leaving some behavioral context 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence with no wasted words directly states the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with one well-documented parameter and no output schema, the description is mostly sufficient. It could mention the source of the ID or the expected return, but the operation is straightforward.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema documents 'id' as 'Upload log ID' with 100% coverage. The description's mention of 'specific entry' aligns with the parameter but adds no additional semantic detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' with a clear resource ('details of a specific event log upload log entry'), distinguishing it from siblings like 'list_event_log_upload_logs' and 'get_event_log_upload_config'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the purpose: use when you need details for a single event log upload log identified by 'id'. However, no explicit guidance is provided about when to prefer this over list_event_log_upload_logs or how to obtain the id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. The word 'Get' implies a safe read operation, but no additional context is given about return behavior, error handling, or permissions. It does not contradict annotations (none exist).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that communicates the tool's purpose with no waste. Every word contributes to clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-id tool, the description is sufficient. It could optionally clarify that this is for live (non-draft) ad items or describe the return format, but the absence of output schema makes this less critical. The single parameter is fully covered by the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the 'id' parameter is already documented as 'Ad item ID'. The description adds no further meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('image ad item') with a clear scope ('specific'), distinguishing it from list operations and other ad item types (e.g., custom HTML, native).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied: use when you need details of a specific image ad item. However, it does not explicitly mention when not to use it or point to alternatives like list_image_ad_items or draft_get_image_ad_item.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the basic read operation without mentioning return format, error behavior (e.g., 404 if not found), or whether sensitive fields like passwords are exposed. This is a minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with 9 words, front-loaded with the action and resource. Zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 1-parameter get operation, the description is mostly complete. It lacks details on the return payload or error scenarios, but given the simplicity and schema coverage, it is adequate for basic selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single 'id' parameter, which is described as 'SFTP connection ID'. The description adds no extra meaning beyond this, but the schema already fully documents the parameter, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get details of a specific SFTP connection by ID', using a specific verb and resource. It distinguishes itself from sibling tools like list_sftp_connections (which lists all) and create/update/delete/test operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by ID' implies usage when a specific SFTP connection ID is known, contrasting with listing all connections. However, it does not explicitly mention alternatives like list_sftp_connections or provide exclusionary guidance, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral disclosure. The verb 'Get' clearly signals a read operation with no side effects, but the description does not expand on return format, error behavior (e.g., not found), or authorization requirements. It provides minimal but unambiguous transparency for a simple read.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence: 'Get a specific recipient for a signature request'. It contains no filler, every word contributes to the meaning, and the structure is clean and immediately understandable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a straightforward retrieval operation with three fully documented parameters. The description clearly states the purpose, and the schema covers all required inputs. However, because there is no output schema, the description could have mentioned the return value (recipient details) or error conditions. Overall, it is sufficiently complete for selection and basic invocation, but slightly thin on contextual details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes all three parameters (request_id, contract_id, recipient_id) with individual descriptions, achieving 100% schema coverage. The tool description adds no additional parameter semantics beyond the word 'specific' aligning with recipient_id. Since schema coverage is high, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' with the resource 'a specific recipient for a signature request', making it clear that this tool retrieves a single recipient. It implicitly distinguishes itself from sibling tools like list_signature_request_recipients (plural) and get_signature_request (the request itself) by specifying 'recipient' and 'specific'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'specific recipient' implies you should use this when you already have the recipient ID, but the description gives no explicit guidance on when to use this versus list_signature_request_recipients or other alternatives. There is no mention of exclusions, prerequisites, or context beyond the core retrieval need.
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 states the core read behavior ('Get details'), but doesn't disclose error handling (e.g., 404 on not found), auth requirements, or return value structure. Adequate but minimal given no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no filler, all words carry meaning. Front-loaded with the primary verb and object. Efficient for a simple get-by-ID tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter tool with no output schema or annotations, the description is complete enough: it states what the tool does and how it identifies the target. Minor gap: no hint about return format, but 'details' implies the response. Acceptable given low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters, with 'id' already described as 'Trusted redirect domain ID'. The description adds no additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb ('Get details') and clearly identifies the resource ('trusted redirect domain') plus the lookup key ('by ID'). It clearly distinguishes from sibling tools like create/update/delete/list variants.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied by the name and description ('get by ID'), but there is no explicit guidance on when to use this vs. list_trusted_redirect_domains or other alternatives. No when-not or exclusion criteria provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the aggregate scope across types, but does not mention pagination behavior, whether archived/draft items are included, or any rate limits. The description is not misleading but leaves important behavioral details unstated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the action and resource, defines the colloquial term 'banners', and lists all relevant types. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with paginated parameters and no output schema, the description adequately conveys the core function and scope. It could benefit from clarifying whether the list includes all advertisers or only a specific context, but it is sufficiently complete for basic selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both 'limit' and 'offset' having descriptions. The description adds no parameter-specific details, but with full schema coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List', the resource 'ad items', and the scope 'across all types' with explicit enumeration of types (image, custom HTML, rich media, native, catalog). This distinguishes it from type-specific sibling tools like list_image_ad_items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'across all types' implies this is the aggregate list tool, but it does not explicitly state when to use it over type-specific alternatives or mention any exclusions. No alternative tools are named, so guidance is only implied rather than 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?
With no annotations, the description carries the full burden. It only restates the action ('list bidders') and adds an account scope, but does not disclose pagination behavior, return format, rate limits, or any side effects. This is minimal beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that directly states the tool's purpose with no filler words. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with fully described pagination parameters and no output schema, the description is largely complete. It could mention what fields are returned or how to get a specific bidder, but the simplicity and schema coverage make it adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'limit' and 'offset' fully described. The description adds no parameter-specific information, but the schema already handles the semantics, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with the resource 'all bidders' and scopes it to the user's AdButler account. This clearly distinguishes it from sibling tools like get_bidder (single bidder), create_bidder, and update_bidder.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving all bidders without filtering, and the context of siblings like get_bidder suggests using that for individual bidders. However, it does not explicitly state when not to use it or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 states the operation (list) but adds no context about pagination, scoping, or read-only nature. The schema covers pagination parameters, so the description is minimally adequate but does not enrich beyond the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence with a clarifying parenthetical. It is front-loaded and contains no filler, earning a perfect score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with two optional pagination parameters and no output schema, the description is nearly complete. It clearly identifies the resource type and the action, and the schema fills in parameter details. It could add a note on return type, but the tool name and description imply a list of platform targets.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents both parameters (limit, offset) with descriptions, so schema coverage is 100%. The tool description adds no additional parameter meaning, which is acceptable given the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') with a clear resource ('platform targets') and clarifies the meaning with '(device/OS/browser targeting)'. This distinguishes it from other list_*_targets tools such as list_geo_targets or list_data_key_targets, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing platform targets but provides no explicit guidance on when to use it versus alternatives like get_platform_target for a single target. It lacks a clear 'when not to use' or reference to sibling tools, leaving the decision to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description is the sole source of behavioral information. It clearly states the state change (archived to active), which is the core behavior. However, it does not disclose potential side effects, idempotency, permissions, or behavior if the advertiser is not currently archived.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence (8 words) that is front-loaded with the action and object. There is no redundant or filler content; every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, no output schema), the description sufficiently conveys the action and its effect. It lacks only minor context such as prerequisites or return value, but the overall purpose is clear and complete for a straightforward state-change operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single 'id' parameter ('Archived advertiser ID'). The description adds no additional meaning beyond the schema, so it meets the baseline for high coverage without enhancing parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Restore') and clearly identifies the resource and target state ('archived advertiser' to 'active status'). This unambiguously distinguishes it from sibling tools like get_archived_advertiser (read-only) or archive_advertiser (opposite 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to reverse an archiving action, but it does not explicitly state when to use it versus alternatives (e.g., list_archived_advertisers to find the ID) or mention any prerequisites. It relies on the tool name and sibling context rather than providing explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states the primary state transition (archived to active), but does not mention edge cases such as what happens if the campaign is already active, permission requirements, or side effects on related entities.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action ('Restore') and the target resource. No filler or redundant information is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple state-change tool with one clearly documented parameter and no output schema, the description is largely complete. It covers the core action and target. It could be enhanced by mentioning the relationship to archive_campaign or noting that this is the inverse operation, but the essential information is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single 'id' parameter, which the schema describes as 'Archived campaign ID'. The description adds the context that the campaign is 'standard', but the parameter meaning is already fully conveyed by the schema, so the description adds minimal additional value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Restore') and resource ('archived standard campaign') with a clear outcome ('back to active status'). It also distinguishes from the sibling vast_unarchive_campaign by specifying 'standard', which differentiates the target campaign 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when a campaign is archived and needs to be reactivated, but it does not explicitly state when to use this over alternatives or note any prerequisites (e.g., retrieving the archived campaign first). No exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 state transition from archived to active, but does not mention idempotency, failure conditions, or side effects on zone settings or assignments. This is minimally adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the verb and object, no redundant information. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple state-change tool with one well-documented parameter and no output schema, the description covers the essential purpose and input. It could mention error handling or related tools but is substantially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes the single parameter id as 'Archived zone ID' (100% coverage). The description adds 'standard zone' context but no additional format or source guidance, so it meets the baseline for covered schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific verb ('Restore') and resource ('archived standard zone') with an outcome ('back to active status'). The qualifier 'standard zone' distinguishes it from sibling tools like vast_unarchive_zone and unarchive_email_zone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case (reactivating an archived standard zone) but does not explicitly state when to choose it over alternatives such as vast_unarchive_zone or unarchive_email_zone. There are no exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description is the sole source of behavioral information. It clearly implies a read operation ('Get'), but adds no details about error handling, auth requirements, or return format. It does not contradict anything, but 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, immediately stating the action and target. No fluff or repetition; it is front-loaded with the verb and clearly structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-id tool with a single well-documented parameter and no output schema, the description covers the essential information. However, it does not mention the distinction from the regular VAST placement tools or note that it returns the full placement object, so it is not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the single 'id' parameter with description 'VAST 4.2 placement ID', giving 100% coverage. The description adds no additional parameter semantics beyond the schema, which meets the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' with a clear resource 'VAST 4.2 placement' and scope 'single', distinguishing it from list tools and the non-4.2 vast_get_placement sibling. It clearly states exactly 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving a single placement by ID, but it does not explicitly mention when to use it over alternatives like vast_get_placement or list tools. No exclusions or alternative tool references are provided, so guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that deletion is permanent, which is a key behavioral trait. However, it does not mention required permissions, preconditions (beyond 'archived'), or consequences beyond deletion.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, clearly stating the action and target. It is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple deletion operation with one parameter and no output schema, the description covers the essential action and permanence. It lacks detail on error conditions or side effects, but for this complexity level, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already includes a single parameter 'id' with a description 'Archived VAST campaign ID' at 100% schema coverage. The tool description adds no additional parameter semantics beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (permanently delete), the resource (archived VAST campaign), and the condition (archived). It distinguishes from siblings like vast_archive_campaign and vast_unarchive_campaign.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives such as vast_delete_campaign or delete_archived_campaign. The intended use is implied by the name and the word 'archived', but no alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden, but it only implies a read-only operation via 'Get'. It does not describe behavior for missing IDs, archived records, or the response shape, leaving notable 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no filler. It front-loads the verb and resource, making it immediately understandable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter getter, the description is mostly adequate, but it does not clarify the relationship with archived advertisers or what 'details' includes, especially given the presence of get_archived_advertiser and the lack of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers the single 'id' parameter fully with the description 'Advertiser ID'. The tool description adds only 'by ID', reinforcing the parameter without providing additional semantic detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get details of a specific advertiser by ID' clearly identifies the verb, resource, and scope. It distinguishes this tool from list_advertisers by specifying 'a specific' and 'by ID'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies use when a single advertiser's details are needed by ID. It does not explicitly mention exclusions such as archived advertisers or alternatives like get_archived_advertiser, so it falls short of a 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?
No annotations are provided, so the description carries the burden of behavioral disclosure. It states the core operation ('List all archived channels') but does not disclose pagination behavior, return format, or side effects. The schema documents limit/offset, but the description adds no additional context about what the response contains or how pagination works. For a standard list operation, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence ('List all archived channels') with no wasted words. It is front-loaded and immediately conveys the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple list tool with two optional parameters and no output schema. The description is minimal but sufficient for a basic list operation. However, it does not explain the return structure or any nuances about what 'all' means with pagination, so it leaves some gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'limit' and 'offset' clearly described in the schema. The description adds no additional meaning beyond what the schema provides, which is acceptable given the high coverage baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all archived channels' uses a specific verb ('List') and resource ('archived channels'), distinguishing it from sibling tools like 'list_channels' (active channels) and 'get_archived_channel' (single archived channel). The scope is clear and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool: when you need to list all archived channels. However, it does not explicitly mention alternatives or exclusions, such as using 'list_channels' for active channels or 'get_archived_channel' for a single archived channel. The context is clear but lacks explicit 'when not to use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 the HTTP method (POST /adserve) and that it returns ads 'that would be served', suggesting it's a simulation. However, it does not mention potential side effects (e.g., whether impressions are logged), authentication requirements, or behavior when no ad is available.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: 'Request ad delivery for a zone' immediately states the action. It includes the return value, use case, and HTTP method in three short sentences with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 16 parameters and no output schema, and the description stays minimal. It explains the core purpose but does not describe the response format or highlight critical parameters like 'type' (json vs jsonr) or the requirements for 'ip' and 'referrer'. This leaves some gaps for an agent trying to invoke it correctly, though the schema provides parameter-level completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all 16 parameters, so the description does not need to repeat parameter details. The text adds no additional parameter semantics beyond the schema, which is acceptable at the baseline level.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Request ad delivery for a zone' and 'Returns the ad(s) that would be served'. This uses a specific verb and resource, distinguishing it from sibling tools like get_ad or vast42_get_ad. The added phrase 'useful for verifying ad setup' clarifies its intended use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case: 'useful for verifying ad setup'. It implies this tool is for testing/diagnosing rather than actual ad serving. While it doesn't explicitly name alternatives or state when not to use it, the context is sufficient given the large sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It usefully reveals that variables use an add/remove format, which is non-obvious from the schema alone. However, it does not disclose whether name/raw_html are partial updates, whether id is required, or what the response looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no wasted words. The first sentence clearly states the action and target, and the second adds the key variable-update behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema covers parameter details well, but there are no annotations and no output schema. The description leaves out return value, error behavior, and whether fields are partially updated. The add/remove hint is helpful, but the overall context is not fully complete for a nested update tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing a solid baseline. The description adds value beyond the schema by clarifying that the variables parameter uses add/remove arrays for updates, which is essential semantic context not fully captured by the property descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Update an existing native template', using a specific verb and resource. This clearly distinguishes it from sibling tools like create_native_template, delete_native_template, and get_native_template.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Update an existing' implies this tool is for modifying existing templates rather than creating new ones, but there is no explicit when-to-use guidance, prerequisites, or mention of alternatives. It does provide a meaningful usage hint about the add/remove format for variables, but not for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. 'Get' indicates a read operation, but it does not describe the response format, error behavior, or side effects. Minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear, front-loaded sentence with no unnecessary words. It effectively communicates the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a simple one-parameter getter, the description adequately states the core purpose, but with no output schema or annotations, it lacks details about return values and error conditions. Some gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the only parameter 'id' as 'VAST 4.2 interactive creative file ID' (100% coverage). The description adds nothing beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation: 'Get a single VAST 4.2 interactive creative file.' It identifies the specific resource and distinguishes itself from list, create, update, and delete siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Get a single' implies it is used to fetch one specific file by ID, contrasting with list operations. However, it does not explicitly mention alternatives or when not to use, though the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Get' implies a read-only operation, but the description does not disclose error handling, permission requirements, or return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence ('Get details of a specific VAST channel zone assignment') that front-loads the verb and contains no redundant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID tool with one required parameter, the description fully conveys the purpose and required input. No output schema exists, but 'get details' successfully implies the return of assignment details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single required parameter 'id' with description 'VAST channel zone assignment ID'. The tool description adds little beyond the schema, except implying specificity via 'specific'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get details of a specific VAST channel zone assignment' clearly states the verb (get), the resource (VAST channel zone assignment), and scope (specific), effectively distinguishing it from sibling tools like list, create, update, and delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: use when you need details of a single assignment by its ID. However, there is no explicit mention of when to use this versus list alternatives or any 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 full burden. It discloses the soft-delete and restore behavior, but does not mention side effects on related entities, permissions required, or the resulting listing in archived endpoints. This is basic but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the action, and includes the most important qualifier. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description is sufficient. It does not need to explain return values since there is no output schema, but it could have pointed to list_archived_advertisers/unarchive_advertiser for lifecycle context. Still, it is complete enough for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: the 'id' parameter is documented as 'Advertiser ID'. The description adds no extra parameter context, but none is necessary—the schema fully defines the single parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action precisely: 'Archive an advertiser' with the clarifying note '(soft-delete, can be restored later)'. This distinguishes it from the sibling delete_advertiser and aligns with unarchive/archive 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'soft-delete, can be restored later' clearly implies the use case of temporarily disabling an advertiser versus a hard delete. While it does not explicitly name alternatives, the context guides the agent to reserve archive for reversible actions.
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 burden of disclosure. It mentions the critical soft-delete and restorable nature, but does not cover permissions, side effects on associated entities, or the restoration path. Basic behavior is disclosed, but important operational details are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately conveys the action and a key attribute (soft-delete/restorable). It is front-loaded and contains no extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (1 parameter, no output schema, no annotations), the description covers the essential purpose and behavior. It could be more complete by explicitly mentioning how restoration occurs (e.g., via unarchive_publisher), but is adequate for a basic operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes 'id' as 'Publisher ID' with 100% coverage. The tool description adds the context that this ID is for the publisher to archive, but does not enrich beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the exact action: 'Archive a publisher' with the key behavior 'soft-delete, can be restored later'. It clearly distinguishes from hard delete (delete_publisher) and restoration (unarchive_publisher), using a specific 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when you want to remove a publisher but keep the ability to restore. It does not explicitly name alternatives like delete_publisher or unarchive_publisher, but the soft-delete/restorable context makes the use case clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It clearly discloses the soft-delete behavior and restorability, which are the most critical behavioral traits. However, it does not detail side effects such as whether the zone stops serving ads immediately or how archived zones are managed, though the existence of list_archived_zones and unarchive_zone siblings fills 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that includes the verb, resource, and key behavioral note. It is concise, front-loaded, and contains no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description covers the essential purpose and behavior. It specifies the zone type and the soft-delete nature. It could optionally reference related tools, but that is not necessary for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the single 'id' parameter with description 'Zone ID', achieving 100% schema coverage. The description adds no additional parameter context beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource ('Archive a standard zone') and adds key behavior ('soft-delete, can be restored later'). It distinguishes from sibling tools like vast_archive_zone and archive_email_zone by specifying 'standard zone', making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for standard zones as opposed to other zone types, but it does not explicitly state when to use this tool vs alternatives. There is no mention of prerequisites or when to prefer archive_zone over delete_zone or unarchive_zone, leaving some ambiguity for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. "Permanently delete" discloses the irreversible, destructive nature of the action, which is meaningful. However, it doesn't mention prerequisites (e.g., campaign must be archived), potential errors, or permissions needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no filler or redundant content. Every word contributes to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter delete operation with no output schema, the description covers the essential action and object. It could mention that the campaign must already be archived or what happens to associated data, but the simplicity of the tool makes the current description sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the single 'id' parameter at 100%, with the description 'Archived campaign ID'. The tool description adds only the word 'standard' to indicate the campaign type, which is marginally useful but doesn't substantially enhance the schema's own description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is specific and unambiguous: "Permanently delete an archived standard campaign" clearly states the verb (delete) and resource (archived standard campaign). It distinguishes itself from related tools like delete_campaign and vast_delete_archived_campaign by specifying "archived" and "standard".
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: use this tool only for archived standard campaigns, not active ones. It doesn't explicitly mention alternatives (e.g., unarchive_campaign to restore), but the 'archived' qualifier and sibling tool names make the intended use clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that deletion is permanent, which is useful behavioral context, but it does not mention preconditions (e.g., contract must be archived), side effects on related data, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It conveys the essential information efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with one parameter, the description is mostly sufficient. It lacks details on return value or behavior on non-archived contracts, but these are minor gaps given the simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description of the 'id' parameter as 'Archived contract ID'. The tool description does not add additional meaning beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Permanently delete an archived contract' has a specific verb (delete), a specific resource (archived contract), and a modifier (permanently) that distinguishes it from related tools like delete_contract, archive_contract, and unarchive_contract.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates the tool is for archived contracts, providing clear context for when to use it. It does not explicitly mention alternatives or exclusions, but the archived contract target is unambiguous enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. The verb 'Get' clearly indicates a read-only operation, and the modifier 'archived standard campaign' clarifies the object's state. It does not disclose error handling, but for a simple retrieval tool, the core behavioral trait (non-mutating read) is sufficiently conveyed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It efficiently communicates the tool's purpose and scope without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read operation, the description is largely complete. It specifies the object type ('standard' vs. VAST) and archived status. It does not describe the return structure, but the absence of an output schema makes this less critical. Minor gap: it doesn't state what 'details' includes or how errors are returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with the description 'Archived campaign ID' for the only parameter. The tool description adds no extra semantic detail beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get details') and the resource ('a specific archived standard campaign'), distinguishing it from sibling tools like list_archived_campaigns (enumerating) and vast_get_archived_campaign (VAST-specific). This leaves no ambiguity about 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving one archived standard campaign, and the word 'specific' indicates it is for a single entity. However, it does not explicitly mention when to prefer this over get_campaign (active) or list_archived_campaigns (listing), nor does it name alternatives. Clear context but no explicit exclusion or comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. 'Get details' clearly implies a read operation, but it does not mention potential errors (e.g., 404 if not archived), authentication requirements, or the response shape. It is adequate but not deeply transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word earns its place, and it is appropriately sized for a simple get-by-id tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description is largely complete: it identifies the target resource and the action. It slightly lacks context about how this differs from get_contract, but sibling naming helps bridge that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage for the single parameter 'id' with the description 'Archived contract ID'. The tool description adds no further parameter semantics, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('archived contract'), clearly distinguishing it from sibling 'get_contract' (active contracts) and 'list_archived_contracts' (list vs. single item). It unambiguously states the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'archived contract' implicitly signals the tool is for archived contracts, differentiating it from get_contract. However, it does not explicitly state when not to use it or point to alternatives, so it falls short of a 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?
No annotations are provided, so the description carries the burden. The verb 'Get' indicates a read-only operation, but the description does not disclose additional behavioral traits such as return format, required permissions, or side effects. This is a minimal but acceptable level of transparency for a simple getter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no filler or redundancy. It effectively communicates the core purpose in a concise, front-loaded manner.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema. The description conveys the core purpose and implies that the return value is the conversion tracking tag. It does not detail the exact response format or preconditions, but for this level of complexity it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the single 'id' parameter with a clear description ('VAST ad item ID'), providing 100% schema coverage. The tool description adds no extra parameter semantics beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and precisely identifies the resource ('conversion tracking tag') scoped to 'VAST ad item'. This clearly distinguishes it from sibling tools like get_vast_zone_conversion_tag or get_campaign_conversion_tag.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the context: use this tool when you need the conversion tracking tag for a VAST ad item. It does not explicitly list alternatives or exclusions, but the alignment with the tool's name and the presence of other entity-specific tag getters makes the usage context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It clearly indicates a read operation ('List') and the scope (all types), but does not disclose pagination behavior, ordering, or what fields are returned. The schema mentions limit/offset, but the description itself adds minimal behavioral context beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that is concise and information-dense. It includes the key scope and types with no filler words, earning a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with only two optional params and no output schema, the description is mostly complete. It covers the core behavior and scope, but it does not explicitly mention that results are paginated or that this is a read-only operation. Still, the schema supplies enough context, so only a slight deduction is warranted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% as both 'limit' and 'offset' have descriptions. The tool description does not add any additional meaning to the parameters, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 'creatives', and explicitly scopes it to 'all types (image, rich media, video, audio)'. This distinguishes it from type-specific siblings like list_video_creatives and list_audio_creatives, as well as from the more general list_creatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is the tool to use when you need creatives across multiple types, but it does not explicitly name alternatives or state when not to use it. It provides clear context but no exclusions or direct comparison with sibling tools, so it falls short of a 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, the description carries the full burden. It discloses the core behavior (listing all zones across types) but does not state whether archived zones are included, the default ordering, or whether pagination is fully supported. It adds minimal context beyond what the schema already provides for limit/offset.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly conveys the tool's purpose without any waste or extraneous detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with two well-documented parameters and no output schema, the description is mostly complete. However, it could benefit from clarifying whether archived zones are included, since sibling tools like list_archived_zones exist.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both limit and offset, so the baseline is 3. The description adds no additional meaning about parameters beyond what the schema states (default limit, pagination offset).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 'zones', and specifies the full scope across all types (standard, email, catalog). This distinguishes it from sibling tools like list_zones, list_email_zones, and list_catalog_zones, which are type-specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'across all types' implies this is the aggregate tool and that type-specific tools exist for narrower queries. However, it does not explicitly say 'use list_zones for standard zones only' or mention any exclusions, so it falls short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It correctly indicates a read operation ('List all'), which is safe, but it does not disclose additional behavioral details such as pagination, ordering, or account scoping. The parenthetical adds domain context but not operational 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that is front-loaded with the verb and resource, plus a concise parenthetical. There are no wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with full schema coverage and no output schema, the description adequately states its purpose and what it returns (a list of all day parting rules). It could be slightly more explicit about the response format or scope, but the simplicity of the tool and sibling context make it sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with clear descriptions for both limit and offset parameters. The tool description does not add parameter-specific meaning beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and resource 'day parting rules', with a clarifying parenthetical 'time-of-day targeting'. It clearly distinguishes from sibling tools like get_day_parting (which retrieves a single rule) and create/update/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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'List all' implies the primary use case is to retrieve every day parting rule. While it does not explicitly name alternatives, the sibling tool names and the 'all' scope make the context clear. No exclusions are stated, but explicit comparison to get_day_parting would have pushed it to a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It indicates a read operation via 'list' and scopes to a contract, but does not disclose pagination behavior, whether all statuses are included, or other behavioral traits. It provides only basic scope, not richer 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence with no filler. It front-loads the verb and resource, making it immediately understandable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with a well-described schema, the description is adequate. There is no output schema, but the return type (a list) is implied by the operation. It could mention pagination behavior, but the schema covers limit/offset.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters (contract_id, limit, offset) already have descriptions. The tool description adds no parameter-specific details beyond what the schema provides, thus the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'list' and clearly identifies the resource ('signature requests') scoped by 'for a contract'. This distinguishes it from singular get_signature_request and create/update/delete siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context that this is for listing requests per contract, but does not explicitly mention alternatives or when-not-to-use. It implies the use case well enough without naming sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden. It discloses the core state change (archived → active) but adds no detail about prerequisites, side effects, permissions, or reversibility. The statement is accurate and gives a basic understanding, but lacks the richer behavioral context expected in the absence of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that is front-loaded with the action and outcome. Every word earns its place, with no redundant details or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple state-transition tool with one parameter and no output schema, the description covers the essential purpose. It could be more thorough by noting that the channel must already be archived or mentioning the expected response, but it is sufficiently complete for a straightforward operation given the simplicity of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with the parameter 'id' described as 'Archived channel ID'. The description does not add further parameter nuance beyond this, but it does align with the schema by reinforcing that the channel is archived. Baseline of 3 applies due to high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Restore') and resource ('archived channel') with an explicit outcome ('back to active status'). This clearly distinguishes it from sibling tools like archive_channel, delete_archived_channel, or list_archived_channels.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly communicates when to use it: for channels that are archived and need to become active again. While it doesn't explicitly name alternatives, the context of the sibling tools (archive_channel, delete_archived_channel) makes the appropriate usage clear without 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 states the state change but does not disclose whether the operation is reversible, idempotent, or requires special permissions. It also does not mention side effects or error conditions, which is a gap for a mutating 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It efficiently conveys the action and the target entity, 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.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description and schema fully cover the essential information for this simple tool: what it does and the parameter it requires. It lacks explicit mention of return values or preconditions, but given the simplicity and the schema description, it is sufficiently complete for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'id' has a schema description 'Archived publisher ID', which provides clear meaning. The tool description adds no additional parameter context, so with 100% schema coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Restore' and identifies the resource ('an archived publisher') and the outcome ('back to active status'). This clearly differentiates it from sibling tools like archive_publisher, get_archived_publisher, and delete_publisher.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it is used to change an archived publisher to active status. However, it does not explicitly state when-not-to-use or mention alternatives, though the intended usage is clearly implied by the action and sibling naming conventions.
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 transparency burden. 'Get details' clearly implies a read operation, and the tool is simple, but the description does not mention any additional behaviors such as error handling (e.g., what if the campaign doesn't exist) or whether the returned details match a specific schema. It covers the core behavior but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no redundancy. It front-loads the core functionality and wastes no words, making it highly scannable for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter retrieval tool with no output schema, the description conveys the essential purpose. It does not explain the return structure, but 'details' implies a representation of the campaign. Given the tool's low complexity and complete schema coverage, the description is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage: the 'id' parameter is described as 'Archived VAST campaign ID', which fully conveys its meaning. The description does not add any parameter-level detail beyond the schema, but the schema is sufficient, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Get details of a specific archived VAST campaign' with a specific verb ('Get'), resource ('details of ... campaign'), and scope ('archived', 'specific'). It distinguishes itself from siblings like vast_list_archived_campaigns and vast_delete_archived_campaign by naming the single-resource retrieval purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by specifying 'archived' and 'specific', implying the tool is for retrieving one archived campaign by ID. It does not explicitly name alternatives (e.g., vast_get_campaign for active campaigns), but the context is sufficient given the sibling list. No exclusion guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It explicitly states the key behavioral trait: the operation is a reversible soft-delete. It does not detail side effects like how archived contracts appear in listings, but for a single-parameter tool, this is sufficient disclosure of the primary 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the action and clarifies its non-destructive nature. Every word contributes meaning, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple: one ID parameter, no output schema, and no nested objects. The description adequately explains what the tool does and the crucial reversibility context. It does not discuss return values or permissions, but these are less critical given the simplicity and the presence of sibling tools for restoration and listing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter with full description coverage (100%) for 'id' as 'Contract ID'. The tool description adds no additional parameter-level information beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Archive') and resource ('contract'), and immediately clarifies the operation is a soft-delete that is reversible. This distinguishes it clearly from the sibling tool 'delete_contract' (permanent deletion) and pairs naturally with 'unarchive_contract'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
By stating 'soft-delete, can be restored later', the description implies it should be used when the contract may be needed again, as opposed to hard deletion. It does not explicitly name an alternative, but the contrast with permanent deletion is clear from the context and sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the critical behavioral trait that archiving is reversible (soft-delete), which is essential for an agent to understand the consequences. It could add more context about side effects or state changes, but the core behavior is clearly communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the essential information without any filler. Every word adds value, making it an model of concise writing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description explains what it does and the key reversible behavior, which is sufficient for basic usage. It does not mention what happens to associated entities (e.g., schedules, assignments) upon archiving, but that may be outside the intended scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% description coverage for the only parameter, defining 'id' as 'VAST campaign ID'. The description does not add any additional meaning or usage nuance beyond that, so it does not improve upon the schema in this regard.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Archive' and the resource 'VAST campaign', and explicitly explains the behavior as a soft-delete that can be restored. This distinguishes it from hard-delete tools like vast_delete_campaign and from the opposite unarchive tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
By defining 'soft-delete, can be restored later', the description implies when to use this tool (when reversible deletion is desired) and hints at alternatives (permanent deletion or unarchiving). However, it does not explicitly name the alternative tools or list when-not-to-use conditions, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explicitly discloses that the operation is a soft-delete and reversible ('can be restored later'), which is the most critical behavioral trait. It does not mention permissions or response format, but for a simple one-parameter archive, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with a helpful parenthetical. Every word earns its place and the key nuance (soft-delete) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, no-output-schema tool, the description is sufficient. It covers the operational effect (soft-delete) and reversibility. It could mention prerequisites or follow-up actions, but given the simplicity of the tool, the missing details are not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with 'id' described as 'VAST channel ID'. The description adds no additional parameter context, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb (Archive) and resource (VAST channel), and clarifies it's a soft-delete that can be restored. This clearly distinguishes it from hard-delete siblings like vast_delete_channel and restore operations like vast_unarchive_channel.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this is a soft-delete (non-destructive) operation, implying it should be used over permanent deletion. However, it does not explicitly name alternatives or state when not to use it, so it falls short of a full 5.
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 burden. It discloses the key behavior: the operation is reversible ('can be restored later') and non-destructive in the sense of soft-delete. This adds meaningful context beyond what the schema provides, though it stops short of describing side effects or authorization requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that conveys both the action and the key nuance (soft-delete, restorable). Every word earns its place, and it is front-loaded with the primary verb and object.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description provides sufficient context: it explains what 'archive' means in this domain and notes the reversibility. It does not mention return values, but that is a minor gap given the simplicity of the operation and the presence of sibling tools that illustrate lifecycle.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the only parameter 'id' as 'VAST zone ID', providing 100% coverage. The description adds no additional meaning or usage guidance for this parameter, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Archive' with resource 'VAST zone' and clarifies it's a soft-delete that can be restored. This distinguishes it from permanent delete operations among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'soft-delete, can be restored later' implies the appropriate context compared to hard-delete alternatives, but does not explicitly name alternatives like vast_delete_zone or vast_unarchive_zone. Clear context is provided, but exclusions are not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses the key side effect: 'On success, the API key is automatically configured.' It also implies a prerequisite (code from email) and a state change (verification). It does not detail failure behaviors, but for a simple verification step, this is valuable and beyond what the name alone suggests.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences and every sentence earns its place: what the tool does, when to call it, and what happens on success. It is front-loaded with the main action and contains no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two well-documented parameters, no output schema, and no annotations, the description provides the essential context: the workflow position (after create_trial_account), the prerequisite (user's code), and the outcome (API key configuration). It does not mention the response format, but in the absence of an output schema this is not a critical gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: both email and verification_code have descriptions in the input schema. The description adds minimal parameter-specific meaning beyond the schema, only contextualizing that the code comes from the user's email. Baseline 3 is appropriate since the schema already fully documents parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Verify a trial account email with the verification code sent to the user.' It uses a specific verb ('verify') and resource ('trial account email'), and explicitly references the preceding step in the workflow (create_trial_account), which distinguishes it from sibling tools like resend_verification_code.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'Call this after create_trial_account' and notes that the user must provide the code from their email. It does not explicitly mention when not to use it or alternatives, but the sequencing guidance is sufficient for a straightforward workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the most important behavioral trait: this is a soft-delete and the campaign can be restored later. This exceeds a bare 'Archive campaign' and gives the agent essential knowledge about reversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that packs key facts: action, resource type, and behavioral effect. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, one-parameter operation with no output schema, the description is complete. It specifies the resource type ('standard' vs. sibling vast variants), the soft-delete semantics, and restore possibility, giving an agent sufficient context to select and use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'id' is fully described in the schema ('Campaign ID'), so schema coverage is 100%. The description does not add extra parameter context, but none is needed given the simple schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Archive'), the target ('a standard campaign'), and the crucial distinction from hard delete via 'soft-delete, can be restored later'. It implicitly differentiates from sibling tools like 'delete_campaign' and 'vast_archive_campaign' by specifying 'standard'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for reversible deletion, suggesting use when you want to temporarily deactivate a campaign rather than permanently remove it. It does not explicitly name alternatives or state when not to use it, but the soft-delete clarification provides clear context for typical usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It discloses an important behavioral trait: the account requires email verification after creation, with the user needing a verification code. This goes beyond a simple 'create' and helps the agent anticipate the follow-up.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, then usage condition, then next step. Every sentence adds value with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides purpose, when to use, and the critical post-creation step (email verification). While there is no output schema, the description does not detail response/error handling, but for a workflow-oriented create tool, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description only generically says 'Collects their info' without adding specific parameter semantics, but the schema already fully documents each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Create a free AdButler trial account', a specific verb+resource statement. It clearly distinguishes from siblings by stating 'Use this when the user does NOT have an AdButler account yet', and even names the follow-up tool verify_trial_email.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage condition: 'Use this when the user does NOT have an AdButler account yet.' It also provides the necessary next step, directing the user to verify_trial_email, which serves as a clear workflow guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations were provided, so the description must carry the burden of behavioral disclosure. It discloses what the tool returns (full schema with parameters, request body, response shape) and implies this is a non-mutating metadata operation. While it doesn't explicitly state 'read-only' or 'does not invoke the endpoint,' the wording and purpose make this clear enough for a schema retrieval 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences: the first states the core purpose, the second provides workflow context. Every word earns its place, and it is front-loaded with the most important information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 parameters, no output schema, no nested objects), and the description fully covers its purpose, output, and usage in context with sibling tools. It also explains what the expected output looks like (full schema), which is sufficient for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The schema already documents method and path with clear descriptions, including an example with placeholder syntax and the requirement to match search_adbutler_api results. The description adds no additional parameter semantics beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 full schema (parameters, request body shape, response shape) for one AdButler API endpoint.' This is a specific verb+resource combination that distinguishes it from sibling tools like search_adbutler_api (which finds endpoints) and call_adbutler_api (which invokes them).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly provides usage context: 'Use after search_adbutler_api to understand exactly what to send when you call it.' This tells the agent when to use it relative to its sibling tools, establishing a clear workflow: search, describe, then call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It discloses that the session's API key is applied automatically and forbids passing an api_key, and it demonstrates how path_params are interpolated into the path. However, it does not state what the tool returns (raw JSON, response status) or mention error/rate-limit behavior, leaving some behavioral aspects undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, front-loaded with purpose and usage, followed by a compact example. No redundant text or repetition of schema details; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a generic raw API caller, the description covers what it does, when to use it, how to substitute path params, and the auth setup. The absence of a return format or error handling note is a minor gap, but the tool's generic nature and the existence of sibling wrappers make the description reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides complete (100%) descriptions for all five parameters, so the baseline is 3. The description adds value by explaining the relationship between path and path_params with an example, and clarifying that api_key should not be passed even though it isn't a schema parameter. This pushes it above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Call any AdButler API endpoint directly,' clearly stating the tool's function as a raw HTTP client for any AdButler endpoint. It distinguishes itself from the many sibling wrapper tools by adding 'Use this only when no specific tool wraps the endpoint you need,' making its 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 Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit usage condition: only when no specific tool wraps the endpoint, which differentiates it from the extensive wrapper list. It also provides a concrete example of path placeholder substitution and warns against passing an api_key, clarifying setup expectations.
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 burden. It clearly discloses the observable behavior: searches by keyword, returns matching endpoints with HTTP method, path, and brief summary. It also implies a read-only discovery operation via 'find' and 'returns', and sets expectations for the follow-up calls. It does not explicitly mention side-effect-free behavior, but the language strongly indicates a lookup-only 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four concise sentences: purpose, return value, usage context with examples, and a clear workflow chain. Every sentence earns its place, with no redundant words and the key action front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description comprehensively covers what the tool returns, when to use it, what types of queries to issue, and how to proceed with results via sibling tools. The parameter semantics are fully covered by the schema, and the workflow is explicitly chained, leaving no major gaps in understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, covering both query and limit with descriptions. The description adds value by giving concrete field-concept examples ('priority', 'pacing', 'frequency cap', 'metadata', 'tracking pixel') that clarify what types of keywords are appropriate for the query parameter. Limit is self-explanatory from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Find AdButler API endpoints by keyword,' a specific verb + resource + modifier. It distinguishes itself from sibling tools by stating 'when no specific tool matches what you need' and clarifies it returns endpoint metadata (HTTP method, path, summary), separating it from resource-specific tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use: 'when no specific tool matches what you need' and when the query is about a *field* rather than a resource, with concrete examples like 'priority' and 'pacing'. It also provides the full follow-up workflow: 'Then call describe_adbutler_api on the most promising hit, then call_adbutler_api to invoke it.' This is clear guidance on alternatives and sequencing.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/adbutler/mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server