revenue-enablement-mcp

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description usefully adds that the output is an actionable 90-day plan with power mapping and whitespace analysis, but says nothing about length, format, or that inputs like known_contacts may be rough notes — modest added value above 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?

Two tight sentences that front-load the deliverable and its components; "based on account intelligence" is mildly redundant but the rest earns its place. No bloat, no burying of key 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?

For a nine-parameter generation tool with no output schema, the description omits how the returned plan is structured or sized, and does not note that only account_name is required while eight inputs are optional enrichment. Adequate but leaves real gaps an agent would want filled.

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 description coverage is 100% across all nine parameters with clear labels (e.g., current_arr "0 for prospects", known_contacts "can be rough notes"), so the schema carries the semantic load. The description adds nothing about how these inputs shape the plan, which is the baseline case for high 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 gives a specific verb ("Generate") and resource ("strategic account plans") and enumerates the plan's contents: power mapping, whitespace analysis, expansion strategies, 90-day plan. It is clearly a planning deliverable, but it never differentiates itself from the closest sibling, mutual_action_plan_generator, leaving overlap unresolved.

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?

There is no explicit when-to-use guidance, no prerequisites, and no mention of alternatives among the eleven sibling tools. The only usage signal is implied by the resource name (account plan), so an agent must infer the routing decision on its own.

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 declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, and the description's 'Create/Generates' wording is consistent with a pure generation tool that persists nothing. Beyond that, it adds no context on output format, length, or whether generation is templated or LLM-driven.

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 tight sentences with the core action front-loaded and the output examples immediately following. No filler, though the sample list is partly redundant with the enum.

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?

Adequate for a read-only generator with a fully documented schema, but the description names only four of the eight enum asset types and gives no hint about output shape or depth, which is notable since there is no output schema.

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

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

Schema description coverage is 100%, so all 11 parameters are already documented in the schema. The description adds no parameter-level meaning beyond what is structured, making the baseline 3 the correct score here.

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?

States a specific verb+resource ('Create internal selling tools for your champion') and enumerates representative outputs, so the agent knows this is a content-generation tool for champion enablement. However, it does not distinguish itself from the overlapping sibling roi_business_case_builder, which also produces a business case.

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?

No when-to-use guidance, no prerequisites, and no mention of alternatives despite the crowded sibling set (roi_business_case_builder, proposal_section_writer, demo_script_builder all overlap). The agent must infer selection criteria on its own.

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 the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the bar is lower. The description adds one meaningful behavioral constraint — that output must not be negative — but says nothing about return format, length, or how the generated tactics are structured.

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 with no wasted words, and the core deliverable is front-loaded. The jargon 'landmine questions' is immediately clarified by the following phrase, keeping it readable.

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 nine-parameter generation tool with no output schema, the description does not describe what is returned (format, number of tactics, structure), which leaves the agent to infer the response shape. Annotations cover safety, but the return contract is unaddressed.

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 description coverage is 100%, so the schema already documents all nine parameters including enums, defaults, and fallback behavior for business_model. The description's mention of questions and positioning tactics loosely maps to trap_type but adds no syntax or format detail beyond the schema.

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?

States a specific verb ('Generate') and resource ('landmine questions and competitive positioning tactics'), so the agent knows the deliverable. It is distinguishable from most siblings, though it doesn't explicitly contrast itself with the overlapping discovery_question_bank or deal_strategy_coach.

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 phrase 'during evaluation' gives an implied context for use, and 'without being negative' hints at an ethical boundary. However, there is no explicit when-to-use vs when-not guidance and no alternative tools are named to route the agent.

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=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds that the output is advisory — 'tactical next steps and risk mitigation' — which is mildly useful, but says nothing about determinism, latency, or whether the advice is generated versus retrieved.

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 short sentences with zero filler; the capability is front-loaded and the output nature follows immediately. Nothing is repeated from the title or schema.

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 an 11-parameter tool with no output schema, the description is thin: it does not sketch what the strategy output contains beyond 'next steps and risk mitigation,' nor note that only deal_name and deal_stage are required. Annotations cover the safety side, but the return-value gap leaves the agent with modest uncertainty.

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 description coverage is 100%, so every one of the 11 parameters is already documented, including the two enums (deal_stage, champion_status). The description only loosely gestures at which inputs matter ('competitive dynamics, stakeholder positions') without adding format or usage detail, so baseline 3 applies.

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 gives a specific verb ('Get') and resource ('deal-specific winning strategies') and names the inputs that drive it (deal stage, competitive dynamics, stakeholder positions). It is clearly distinguishable from artifact-producing siblings like proposal_section_writer or roi_business_case_builder, though it never names an alternative explicitly.

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?

There is no guidance on when to invoke this versus siblings such as competitive_trap_setter, pricing_negotiation_guide, or mutual_action_plan_generator, and no exclusions or prerequisites stated. The agent must infer usage purely from the tool name and sibling names.

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=true, destructiveHint=false and openWorldHint=false, so the safety and closed-world profile is covered. The description adds the output composition (discovery questions, feature-to-value mapping, objection handling), which is useful context, but says nothing about permissions, length limits, or how inputs shape the output.

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 tight sentences with no filler, front-loaded on the outcome-focused purpose followed by the included components. Nothing is redundant, though it is brief relative to the size of the parameter set.

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 an eleven-parameter generator with full schema coverage and no output schema, the description names the purpose and output components but omits the required-input distinction and any sibling routing. It is adequate but leaves clear gaps an agent would want filled.

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 description coverage is 100%, so all eleven parameters, including the demo_type enum, are already documented in the schema. The description adds no syntax or format detail beyond that, so baseline 3 applies.

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?

States a specific verb (Create) and resource (demo scripts) and names the tailoring dimensions (personas, use cases). It also lists the deliverable components (discovery questions, feature-to-value mapping, objection handling). However, it does not differentiate from siblings like discovery_question_bank or deal_strategy_coach, which overlap on discovery questions and objection handling.

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?

There is no statement of when to use this tool versus alternatives, and no prerequisites or exclusions. In a family of twelve sales-enablement generators, the absence of routing guidance leaves the agent to infer that this is the pre-demo preparation 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 readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds useful behavioral context that output is dynamically tailored to supplied context, but says nothing about what the returned question set looks like or how many questions to expect.

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, zero waste, with the capability and the framework list front-loaded before the adaptive-behavior note. Nothing redundant.

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 read-only generator with full schema coverage and simple annotations, the definition covers purpose and framework scope adequately. The one gap is that no output schema exists, so the description could briefly characterize the returned question set (e.g. grouping by framework), which an agent might want.

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 description coverage is 100% with 8 parameters, so the schema already documents each field. The phrase 'what you already know about the prospect' loosely signals that fields like known_pain_points, known_metrics and prospect_role drive adaptation, but it adds no format or usage detail beyond the schema baseline.

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 states a specific verb and resource ('Get contextual discovery questions') and enumerates the supported frameworks (MEDDPICC, BANT, SPICED, Challenger, Gap Selling, all five). This is clearly distinct from sibling tools like deal_strategy_coach or demo_script_builder, though no sibling is named explicitly to route the agent.

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?

'Questions adapt based on what you already know about the prospect' implies this is used ahead of or during discovery calls, and the framework enum implies selection by methodology. However there is no explicit when-to-use, when-not-to-use, or named alternative among the many siblings.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds that sequences are multi-touch and categorizes them, but says nothing about what a generated sequence contains (subjects, bodies, timing) or that inputs like num_emails are ignored.

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 short sentences, front-loaded with the core action. The second sentence largely restates sequence categories already present in the schema enum, a minor redundancy.

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?

With 11 parameters and no output schema, the description should at least indicate what a returned sequence looks like or how the sequence_type templates differ in output. It covers the input side adequately but leaves the return shape entirely unspecified.

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 description coverage is 100% and the enum values and the num_emails 'accepted but not used' caveat are already documented in the schema. The description adds no parameter meaning beyond that, so the baseline 3 applies.

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?

States a specific verb and resource ('Generate multi-touch email sequences') plus the driving dimensions (persona, stage, objective). It is clearly distinguishable from siblings like demo_script_builder or roi_business_case_builder, though it never names or contrasts a sibling directly.

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?

No when-to-use or when-not-to-use guidance, and no mention of alternatives among the many adjacent sales-content tools. The agent must infer usage purely from the purpose statement.

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=true, destructiveHint=false and openWorldHint=false, so safety behavior is covered. The description adds useful substance by naming the output artifacts (milestones, owners, dates) and the buyer/seller alignment intent, but says nothing about how it treats the many optional inputs or what the generated plan 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.

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

Two tight sentences with no waste, front-loading the core action and outputs. Slightly under-developed rather than padded, but structurally clean.

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?

With no output schema and 11 inputs (only 2 required), the description should ideally clarify how it behaves when optional context like champion, economic buyer, or blockers is omitted. It conveys the deliverable but omits that behavioral nuance, leaving it merely adequate.

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 description coverage is 100% across 11 parameters, so field meanings are fully documented in the schema and the description does not need to repeat them. It adds no syntax, format, or dependency detail beyond that baseline.

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?

States a specific verb (generate) and resource (collaborative/mutual close plans) and lists the produced artifacts (milestones, owners, dates). It is clear what the tool does, but it never distinguishes itself from nearby siblings such as deal_strategy_coach or account_plan_builder, leaving the agent to infer the boundary.

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?

There is no explicit when-to-use guidance and no alternative tool is named. The phrase 'path to decision' implies late-stage deal planning, but the agent gets no condition telling it to pick this over proposal_section_writer or pricing_negotiation_guide.

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=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds that the output is defensive strategy/tactics content rather than raw data, but says nothing about output shape, determinism, or how the 11 inputs shape the result. Adequate but shallow against a fully-covered annotation set.

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 tight sentences with the primary purpose front-loaded and no filler. It is appropriately sized for the message it delivers, though it stops short of carrying the weight a tool this complex needs.

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 complex tool: 11 parameters, 2 enums, and no output schema. The description ignores the scenario taxonomy, the interplay of deal_value/leverage/buyer_leverage inputs, and the schema's own caveats (e.g., your_solution being accepted but unused). For this level of complexity, the definition leaves substantial gaps.

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 description coverage is 100%, so all eleven parameters are already documented, including the notable notes that your_solution is 'Accepted but not used yet' and value_delivered is 'Shown in the output.' The description adds nothing 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.

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

States a specific verb and resource pair: 'Get value-based pricing defense strategies and negotiation tactics,' with a scope note about maintaining deal value against discount requests. This is clear on what it produces, but it never distinguishes itself from close siblings like deal_strategy_coach or competitive_trap_setter.

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 phrase 'while addressing discount requests' implies a usage context, but the description gives no explicit when-to-use guidance, no prerequisites, and no naming of alternatives among the eleven sibling tools. The agent can infer a scenario but nothing routes it decisively.

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=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds no further behavioral context such as length, determinism, or the fact that inputs like primary_audience are accepted but ignored. Its claim of 'customized'/'tailored' output is arguably overstated given the schema notes that audience-specific text is never produced.

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 short sentences, front-loaded with the core action and followed by illustrative outputs. No filler or redundancy, though the second sentence is close to restating the enum.

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 an 11-parameter generation tool with only 2 required params and no output schema, the description is minimal but the schema carries most of the load. It never explains which two parameters are required or what the generated section looks like, leaving a real gap around intended usage and expected output.

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 description coverage is 100%, so the schema already documents all 11 parameters, including the enum values and the tone caveat. The description adds only the examples of section types, which duplicate the section_type enum, so 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 states a specific verb+resource ('Generate customized proposal sections') and names concrete section types (executive summaries, solution overviews, pricing justifications). It is clearly distinguishable from most siblings like win_loss_analyzer or discovery_question_bank, but it never explicitly differentiates itself from the adjacent sales-asset generators (roi_business_case_builder, demo_script_builder).

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?

There is no when-to-use guidance, no prerequisites, and no reference to any alternative tool. The phrase 'tailored to specific buyers' hints at context but stops short of telling an agent when this tool should be selected over its many siblings. The agent must infer selection criteria entirely.

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=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavior: that fallback numbers are example assumptions explicitly labelled for replacement, and that the calculation is driven by specific input pairs. It does not mention rate limits or output format beyond naming the sections.

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, front-loaded with the action, then the value-derivation rule, then the deliverables. Dense but each clause carries information; only mild awkwardness ('when you give them', 'labelled for you to replace') slightly hurts readability.

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 14-parameter, no-output-schema tool, the description supplies the key missing glue: how inputs map to the value calculation, what happens with incomplete input, and what sections come back. It does not describe the shape or size of the returned case, which would help an agent set expectations.

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%, so the baseline is 3, but the description adds cross-parameter precedence logic the schema states only in isolation: annual_value_estimate takes priority, with current_annual_cost + expected_improvement_percent as the alternative path. That precedence rule is real added meaning beyond the per-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?

States a specific verb and artifact ('Build an ROI business case') and immediately names the outputs produced (ROI, payback, executive summary). The resource is unique among siblings (all other tools are coaching, scripting or writing tools), so an agent can distinguish it without opening the schema.

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?

Gives clear conditional guidance on when the value figure is buyer-supplied versus when benchmark/example assumptions are used, including the exact parameter combinations that trigger each path. It does not explicitly compare itself to sibling tools or state prerequisites, but the context of use is unambiguous.

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=true, destructiveHint=false, openWorldHint=false, so the safety profile is covered by structured data. The description adds one genuinely useful behavioral fact — the tool returns 'factors and questions to investigate' rather than verdicts — but says nothing about handling of missing inputs, partial data, or scope 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?

A single front-loaded sentence with no filler; the purpose leads and the return note trails. The colon-joined construction is slightly dense but every clause earns its place.

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 10-parameter tool with 1 required field and no output schema, the description gives only a one-line account of what comes back. It leaves the mode-selection semantics of analysis_type unexplained and gives no sense of what input is mandatory versus optional, so an agent must infer call shape entirely from the 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 description coverage is 100%, so the baseline is 3; the description adds no parameter-level meaning beyond the schema. Notably it does not explain what the four analysis_type modes (single_deal, deal_portfolio, competitor_analysis, loss_pattern) actually do, which is the single highest-value thing it could have clarified.

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?

States a specific verb+resource ('Structure a win/loss review') and scopes it to 'one deal or a set of deals', which is concrete and actionable. It does not differentiate itself from the eleven sibling tools (e.g. deal_strategy_coach, loss_pattern-adjacent tools), 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.

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

Usage context is implied: you run this when you want to review a deal or a portfolio of deals, and the 'one deal or a set of deals' phrasing hints at the analysis_type choice. However, there is no explicit when-to-use, no when-not-to-use, and no named alternative among the many sibling deal tools.

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