Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds valuable context beyond annotations: 'Free to use; no Profitlee API token required' and details about returned metrics (per-unit fees, margins, monthly P&L). No contradictions with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences: the first states the core action and scope, the second lists outputs and the free access. It is front-loaded, contains no redundant information, and every sentence contributes meaningful information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is complex (26 parameters, 15 required, output schema present), but the description provides a concise high-level overview including platforms and return values. Schema covers all parameter details and the output schema explains return data, so the description is sufficiently complete without restating structured data.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage for all 26 parameters, so the schema already documents each parameter's meaning. The tool description does not add additional parameter-level detail beyond what the schema provides, but no compensation is needed because coverage is complete.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool calculates ecommerce profit for a single product across specified platforms (Amazon FBA/FBM, TikTok Shop FBT/self-fulfilled). It uses specific verbs and resources, and the sibling tools (list_scenarios, save_scenario, etc.) are scenario-management, making this calculator distinct.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use the tool (for profit calculation on supported marketplaces and modes) and explicitly mentions the output types, giving clear context. It does not name alternative tools or exclusions, but the sibling toolset is clearly different, so the usage context is well understood.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description adds valuable behavioral context: the copy recomputes outputs from current fee tables, counts against the saved-scenario limit, and requires PROFITLEE_API_TOKEN. This fully discloses the tool's side effects and constraints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is four sentences, each earning its place: purpose, behavioral effect, naming rule, limit and auth requirement. No fluff or redundancy; front-loaded with the core action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 2 parameters and an output schema, the description is complete. It covers purpose, side effects, naming, limits, auth, and the server-side recomputation behavior. The sibling context further clarifies its role among other scenario operations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already documents both parameters thoroughly with descriptions (id and name, including default behavior). The description adds no new parameter-level information beyond what the schema provides, so the baseline score 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.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool duplicates an existing Profitlee scenario into a new one. The verb 'Duplicate' and resource 'Profitlee scenario' are specific, and it distinguishes from siblings like save_scenario (create) and update_scenario (modify).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use the tool (duplicating an existing scenario) and provides important context (server-side recompute, current fee tables, default naming, saved-scenario limit, token requirement). It does not explicitly name alternatives or exclusions, but the context is 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already include destructiveHint: true and readOnlyHint: false, so the destructive nature is known. The description adds valuable context by stating 'permanently removes' and 'Requires PROFITLEE_API_TOKEN', giving the agent important behavioral and authentication details beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is exceptionally concise, consisting of two sentences that immediately state the action and key constraints. There is no fluff or redundant details, 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.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a simple one-parameter tool with a clear description, comprehensive annotations, and an output schema. The description covers the purpose, permanence, account requirement, and authentication. There is nothing missing for an agent to correctly invoke this tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema fully describes the only parameter 'id' with a rich description of its provenance (returned by list_scenarios or save_scenario). The tool description adds no additional parameter semantics beyond echoing 'by id', so the schema carries the information, meriting a baseline score of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Delete'), the resource ('one saved Profitlee scenario'), and the method ('by id'). This distinguishes it from sibling tools like list_scenarios, get_scenario, and update_scenario, which have different verbs or purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context: it is for permanently removing a scenario from the authenticated Pro account, and it requires PROFITLEE_API_TOKEN. While it does not explicitly mention alternatives or exclusions, the purpose is unambiguous enough for an agent to know when 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior. The description adds value beyond annotations by specifying the required PROFITLEE_API_TOKEN, which is an authentication constraint, and by detailing the return content (inputs and profit output). No contradictions with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences: the first states the core action, the second adds the auth requirement. It is front-loaded, has no redundant words, and every sentence contributes meaningful information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple (one parameter, few annotations, output schema present) and the description covers purpose, auth, and return content. Sibling tools provide context for alternatives. No significant gaps remain.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the 'id' parameter is well-documented as a saved scenario id from list_scenarios or save_scenario. The description's mention of 'original calculator inputs and computed profit output' adds context about what the id refers to, but does not provide additional syntax or format details beyond the schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Fetch') and identifies the resource ('one saved Profitlee scenario by id') along with what it includes ('original calculator inputs and computed profit output'). This clearly distinguishes it from siblings like list_scenarios (fetch all) and save_scenario/update_scenario/delete_scenario (mutations).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description makes clear that this tool retrieves a single scenario by id, and the schema's parameter description adds that the id comes from list_scenarios or save_scenario, implying a workflow. It does not explicitly state when not to use it or name alternatives, but the context is strong 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description adds value by specifying the authenticated Pro account scope and the requirement for PROFITLEE_API_TOKEN. This is useful context beyond structured annotations, though it doesn't discuss potential limitations like pagination or rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no redundancy, and the key information is front-loaded. The first sentence states the purpose, the second adds usage context and prerequisites. Every word contributes value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (no parameters, output schema present, rich annotations), the description covers purpose, usage context, and auth requirement. The output schema handles return value details, so nothing else is needed for a complete understanding.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the baseline is 4 per the rubric. The description appropriately does not attempt to explain parameter details; it merely notes that the tool provides a scenario id for subsequent operations, which relates to output rather than parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists saved Profitlee profit scenarios, using a specific verb and resource. It is distinct from sibling tools like get_scenario, update_scenario, and delete_scenario, which operate on individual scenarios.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly advises using this tool before get_scenario, update_scenario, or delete_scenario when a scenario id is needed, and notes the authentication requirement. This provides clear when-to-use guidance and differentiates from alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate a non-read-only operation, but the description adds valuable behavioral context: 'Profitlee validates the inputs and computes outputs server-side' and 'Requires PROFITLEE_API_TOKEN.' This goes beyond the structured hints by disclosing server-side processing and 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is only two sentences, front-loaded with the main action ('Create a saved Profitlee scenario'). Every word earns its place, covering purpose, behavior, and auth in a compact, readable format.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complex nested input schema, presence of output schema, and annotations, the description is sufficient. It covers the key aspects (creation, validation, server-side computation, auth). A slight gap is not detailing idempotency or duplicate-name behavior, but this is not critical with openWorldHint=true and a comprehensive schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with detailed descriptions for all parameters. The description adds cross-reference value by stating 'calculator inputs using the same field meanings and units as calculate_profit,' which helps the agent reuse known semantics without re-deriving them. This justifies a score above the baseline of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the function: 'Create a saved Profitlee scenario' with a specific verb and resource. It distinguishes itself from siblings like calculate_profit (which likely doesn't save), update_scenario, and delete_scenario by emphasizing the 'saved' scenario creation aspect.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for creating and saving a scenario ('Create a saved Profitlee scenario') but does not explicitly mention alternatives or when not to use it. It lacks comparison to calculate_profit for preview cases or update_scenario for modifications, so usage is inferred rather than directly stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Despite annotations already indicating mutation and destructiveness, the description adds valuable context: it requires PROFITLEE_API_TOKEN and states that passing inputs triggers recomputation of outputs. This goes beyond the structured annotations, though it does not detail edge cases like partial updates or irreversible changes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the main purpose, and then elaborates on parameter usage and authentication. Every clause earns its place with no redundancy, making it highly efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the core usage (update by id with optional name/inputs), authentication, and recomputation behavior. With a rich input schema and an output schema present, it doesn't need to explain return values; however, it omits what happens if neither name nor inputs is provided, which is a minor gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description enhances parameter meaning by explaining the effect of passing `name` (rename) vs `inputs` (replace and recompute) and noting they can be used together. This connects the parameters to their intended outcomes, adding value beyond individual field descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description starts with 'Update an existing Profitlee scenario by id', clearly identifying the verb (update), resource (Profitlee scenario), and key qualifier (by id). It differentiates from siblings like save_scenario (create) and delete_scenario by focusing on modification of an existing entity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use the tool (for existing scenarios) and how to use it: 'Pass name to rename it, inputs to replace calculator inputs and recompute outputs, or both.' It gives clear context, though it does not explicitly contrast with alternatives like save_scenario.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.