Revenue Enablement: 12 deal and sales enablement tools by Helix GTM Consulting
Scored across 12 tools
Each tool maps to a distinct sales artifact (demo script, discovery questions, ROI case, mutual action plan, win/loss review), so an agent can usually pick correctly from the name alone. There is mild overlap in the 'planning/strategy' cluster (account_plan_builder, deal_strategy_coach, mutual_action_plan_generator) and in the 'written asset' cluster (champion_enablement_kit, proposal_section_writer, email_sequence_generator), but the descriptions clarify scope and time horizon well enough to resolve it.
All twelve names follow the same predictable snake_case '<object>_<builder|generator|coach|guide|analyzer|kit|bank|setter>' pattern. The convention is uniform and each name telegraphs the deliverable type.
Twelve tools is squarely in the well-scoped range, and each one covers a discrete stage of the revenue cycle (discovery, demo, proposal, negotiation, close, post-mortem). No tool looks like a duplicate or a leftover.
The surface covers most of the seller's lifecycle: account planning, discovery, demo, champion assets, proposals, ROI, negotiation, mutual action plans, and win/loss. Gaps exist around data retrieval (account_plan_builder explicitly does not look the account up; there is no CRM/pipeline or forecast tool) and post-sale motions like onboarding, QBR, or renewal/expansion planning, but core pre-sale workflows are covered.
Helps you decide how to grow an account in the next 90 days. You give the account name, plus contacts, products, threats and notes if you have them. You get a strategic account plan: a power map with one row per contact you name, whitespace analysis, competitive questions, an answer for each objection and a 90 day plan. It does not look the account up.
| Name | Required | Description | Default |
|---|---|---|---|
| industry | No | Industry vertical | |
| current_arr | No | Current ARR with this account (0 for prospects) | |
| your_sector | No | Optional: your company's own industry (not your customers'). When given, it decides the sector notes; when left out, the tool reads it from your words and stays neutral if they are unclear. | |
| account_name | Yes | Company/account name | |
| account_notes | No | Any additional context about the account | |
| your_solution | No | Your product/service offering | |
| known_contacts | No | Known contacts and their roles, one per line or separated by semicolons, for example: Head of RevOps (champion); CFO. Each entry becomes one row, so put other notes in account notes | |
| current_products | No | Products/services they currently use from you | |
| competitive_threats | No | Known competitors in the account | |
| expansion_opportunities | No | Potential expansion areas or whitespace |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description goes beyond them by clarifying that the tool performs no account lookup and operates purely on user-supplied input, which is a real behavioral constraint an agent could otherwise get wrong, and it previews the shape of the generated plan. It stops short of discussing length limits, determinism, or what happens with sparse inputs.
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?
Front-loaded with the outcome, then input expectations, then output contents, then the key limitation. It is efficient and free of filler, though the middle sentence is a long comma-separated inventory that is slightly harder to scan than a short list would be.
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 ten-parameter generation tool with no output schema, the description does the work that matters: it tells the agent what inputs are expected and optional, previews the returned plan's components, and states that no external lookup occurs. An agent could call this correctly without further information.
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 explains all ten parameters, including the one-row-per-contact rule and the sector enum fallback behavior. The description reinforces optionality ('if you have them') and names four of the ten inputs, but omits industry, ARR, your_sector, your_solution and expansion_opportunities, so it adds only marginal meaning over 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?
The description states a concrete verb and resource: it builds a strategic account plan for growing an account over the next 90 days, and it enumerates the artifacts produced (power map, whitespace analysis, competitive questions, objection answers, 90-day plan). It is clearly distinguishable from a mutual action plan or ROI case by that artifact list, though it never names a sibling tool 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?
Usage is only implied: you invoke it when you want a forward-looking growth plan and you already have account context to supply. The sentence 'It does not look the account up' usefully rules out a class of misuse (expecting enrichment) but there is no explicit when-to-use or when-to-prefer-an-alternative guidance relative to deal_strategy_coach or mutual_action_plan_generator.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Helps you give your champion what they need to sell internally. You give the asset you need (an executive brief, internal business case, objection responses or presentation talking points), your solution, the customer's situation and the objections you expect. You get the asset in the champion's voice with the recommendation, answers to likely questions, the decision requested, a note on the reader and sector notes. It invents no figure or quote.
| Name | Required | Description | Default |
|---|---|---|---|
| asset_type | Yes | Type of enablement asset | |
| your_sector | No | Optional: your company's own industry (not your customers'). When given, it decides the sector notes; when left out, the tool reads it from your words and stays neutral if they are unclear. | |
| champion_name | No | Champion name | |
| champion_role | No | Champion role/title | |
| champion_wins | No | How this makes the champion look good | |
| your_solution | Yes | Your product/solution | |
| budget_context | No | Budget situation and pricing | |
| urgency_drivers | No | Why act now | |
| key_value_points | No | Key value points to emphasize | |
| known_objections | No | Expected objections from stakeholders | |
| target_stakeholder | No | Who the champion needs to convince | |
| competitive_context | No | Competitive alternatives being considered |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered; the description adds genuinely new behavioral context by disclosing the output shape (whose voice it writes in, which sections appear) and a grounding constraint: 'It invents no figure or quote.' That tells the agent the tool will not fabricate numbers, which is decision-relevant. It does not state length limits or what happens when inputs are sparse.
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?
Three sentences, front-loaded with the purpose followed by inputs and outputs; there is no filler or marketing padding. The only mild inefficiency is the repeated 'you give / you get' construction, which is still readable and purposeful.
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 12-parameter generator with no output schema, the description does the needed work: it explains what the agent supplies, what it receives, and that grounding is enforced. The one gap is that only 4 of the 8 enum asset types are named, and it never clarifies that the remaining 10 parameters are optional and inferred when absent, leaving the agent to rely on the schema alone.
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 some meaning by grouping the inputs into a narrative (the asset, your solution, the customer's situation, the objections you expect) and by implying that the omitted optional fields are inferred from 'your words.' However, with 12 parameters it does not add semantics for fields like budget_context, urgency_drivers, competitive_context or champion_wins beyond what the schema already says.
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 framing ('give your champion what they need to sell internally') and then concretely enumerates the deliverable types (executive brief, internal business case, objection responses, talking points), plus what comes back (recommendation, Q&A, decision requested, reader note, sector notes). It is clearly distinguishable from most siblings, though it does not acknowledge overlap with roi_business_case_builder despite supporting an 'internal_business_case' asset type.
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?
It implies the usage context (equipping a champion ahead of an internal sale) and lists the inputs it expects, which hints at when to reach for it. But it gives no explicit when-to-use/when-not guidance and never names the alternative tools for adjacent jobs such as roi_business_case_builder or proposal_section_writer, so the agent must infer selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Helps you decide which questions expose the gaps in your main competitor, without negative selling. You give the named competitor, your solution, your strengths and its weak points as you know them. You get the set up, discovery questions, criteria to establish, reference call questions, requirement and scenario traps, commercial terms and tactics for your stage, with sector notes. Every line comes from your inputs and the sector, and none from an invented fact about the competitor.
| Name | Required | Description | Default |
|---|---|---|---|
| trap_type | No | Type of competitive positioning | |
| competitor | Yes | Primary competitor to position against | |
| your_sector | No | Optional: your company's own industry (not your customers'). When given, it decides the sector notes; when left out, the tool reads it from your words and stays neutral if they are unclear. | |
| buyer_persona | No | Role of key evaluator | |
| your_solution | Yes | Your product/solution | |
| business_model | No | Optional: how you charge (software subscription, services, connectivity, per transaction, marketplace, hardware plus software, or investment management). Read from your other inputs when left out | |
| your_strengths | No | Your key differentiators | |
| buyer_priorities | No | What the buyer cares most about | |
| evaluation_stage | No | Stage of competitive evaluation | |
| competitor_weaknesses | No | Known competitor weaknesses |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavioral guarantees beyond that: no invented facts about the competitor ('every line comes from your inputs and the sector') and an ethical constraint ('without negative selling'). It does not discuss output length or formatting, but the core behavioral promise is unusually well stated.
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?
Three sentences, front-loaded with the value proposition, then inputs, then outputs. Dense but every clause carries information; the final sentence about not inventing competitor facts is the most valuable and is placed last, which slightly buries it. No filler or repetition.
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 10 parameters and no output schema, the description compensates by enumerating the returned components (set up, discovery questions, criteria, reference call questions, requirement and scenario traps, commercial terms, tactics, sector notes). The schema also fully documents parameters and enums. Remaining gap is output structure or volume, which an agent would still have to discover by calling.
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 reinforces the meaning of competitor, your_solution, your_strengths, and competitor_weaknesses as user-supplied rather than inferred, but it says nothing about trap_type, evaluation_stage, buyer_persona, or business_model beyond what the schema already documents. It adds emphasis rather than new semantics.
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: it decides which questions expose gaps in a named competitor and returns a defined set of positioning artifacts. It implicitly separates itself from generic siblings like discovery_question_bank by naming competitor-specific outputs (requirement and scenario traps, commercial terms). It stops short of naming a sibling or an explicit exclusion, 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It describes what inputs to supply ('the named competitor, your solution, your strengths and its weak points') and the constraint 'without negative selling', which implies a pre-deal competitive positioning context. There is no explicit when-to-use versus deal_strategy_coach, discovery_question_bank, or win_loss_analyzer, and no stated preconditions such as needing a known competitor already selected.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Helps you decide what to do next to move a deal. You give the deal name and stage, plus competitors, stakeholder positions and blockers. You get a deal health score, a strategy for the stage, next steps and risks to handle. Ask the user to confirm blocker status, economic buyer engagement, incumbent status and project status when those facts affect the score; typed facts take precedence over text.
| Name | Required | Description | Default |
|---|---|---|---|
| blockers | No | Known blockers or objections | |
| deal_name | Yes | Deal/opportunity name | |
| close_date | No | Target close date | |
| deal_stage | Yes | Current deal stage | |
| deal_value | No | Deal value in dollars | |
| next_steps | No | Currently planned next steps | |
| competitors | No | Competitors in the deal and their position | |
| your_sector | No | Optional: your company's own industry (not your customers'). When given, it decides the sector notes; when left out, the tool reads it from your words and stays neutral if they are unclear. | |
| days_in_stage | No | Days the deal has been in current stage | |
| your_solution | No | What you are selling | |
| blocker_status | No | Ask whether any blocker is present. A confirmed typed fact overrides word reading. | |
| economic_buyer | No | Economic buyer name and engagement level | |
| project_status | No | Ask whether the project is still active. A cancelled project is held, without a close plan. | |
| champion_status | No | Champion identification status | |
| incumbent_status | No | Ask whether the buyer already uses a competing supplier. Overrides word reading. | |
| economic_buyer_engagement | No | Ask whether the budget holder actively participates in this decision. Overrides word reading. |
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 is covered. The description adds genuine value beyond that: it names the return contents (health score, strategy, next steps, risks) and the conflict-resolution rule that 'typed facts take precedence over text', which an agent needs to know before calling.
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?
Four tight sentences: purpose first, then inputs, then outputs, then interaction caveat. No filler, though the final sentence is dense and packs four distinct facts into one clause.
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 16 parameters and no output schema, the description needs to carry the return-value burden, and it does by naming the four artifacts returned. The mutation/permission story is moot for a read-only tool, and only explicit sibling differentiation is missing.
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 every parameter already carries its own description, including the enum-level notes that typed facts override word reading. The description adds only a light procedural layer by grouping the four facts worth confirming with the user, so the 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?
States a specific verb and resource ('decide what to do next to move a deal') and enumerates both the inputs (deal name, stage, competitors, stakeholders, blockers) and outputs (health score, stage strategy, next steps, risks). It does not explicitly distinguish itself from adjacent siblings like mutual_action_plan_generator or win_loss_analyzer, so an agent must 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?
Guidance is about interaction protocol rather than tool selection: 'Ask the user to confirm blocker status, economic buyer engagement, incumbent status and project status when those facts affect the score.' That is useful in-conversation direction, but there is no statement of when this tool is the right choice versus the 11 sibling generators.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Helps you decide what to show in a demo, and in what order. You give the demo type, the persona and the use case, plus the features you must show and the pains you name. You get a timed run from opening to close, with spoken lines and a step for each feature tied to the pains, then discussion, close and follow up lines and sector notes. The answer says where each step came from and what it did not get.
| Name | Required | Description | Default |
|---|---|---|---|
| attendees | No | Other attendees and their roles | |
| demo_type | Yes | Type of demo | |
| your_sector | No | Optional: your company's own industry (not your customers'). When given, it decides the sector notes; when left out, the tool reads it from your words and stays neutral if they are unclear. | |
| demo_duration | No | Demo duration in minutes | |
| your_solution | Yes | Your product/solution | |
| desired_outcome | No | What you want to achieve from this demo | |
| key_pain_points | No | Pain points to address in demo | |
| known_objections | No | Known objections to address | |
| primary_audience | No | Primary demo audience (role/persona) | |
| customer_industry | No | Customer industry | |
| competitor_context | No | Competitor being displaced or compared | |
| must_show_features | No | Features that must be demonstrated |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish this is a non-destructive, read-only, closed-world tool, so the safety profile is covered. The description adds genuine value by describing the output shape — a timed run with spoken lines, pain-tied feature steps, discussion, close, follow-up, sector notes, and provenance about what it did not receive. With no output schema, that output detail is the description's main contribution, but it omits practical traits such as response length or how missing optional inputs 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose and required inputs are front-loaded in the first two sentences, with output detail following. The prose is a bit meandering — phrasing like 'what it did not get' is awkward — but every sentence carries information rather than filler.
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 12-parameter, no-output-schema generation tool, the definition covers the essential contract: what to supply and what comes back, including sector-note and provenance behavior. Only minor gaps remain, such as guidance on which of the nine optional parameters materially change the result.
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; the description goes slightly beyond by explaining how inputs are used — pains drive feature steps, features are tied to pains, and demo type plus persona shape the run. It still does not clarify optional-versus-required behavior or the role of duration, attendees, objections, or competitor context.
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 opening sentence states a specific objective — deciding what to show in a demo and in what order — which effectively means producing a demo run-of-show. That distinguishes it from siblings like proposal_section_writer or discovery_question_bank, 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?
The description tells the agent what inputs to supply (demo type, persona, use case, must-show features, pains), which implies the context in which the tool fits. But it gives no explicit when-to-use/when-not-to-use rule and no routing guidance against the eleven sibling builders.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Helps you decide what to ask on a discovery call. You give the framework you use (MEDDPICC, BANT, SPICED, Challenger, Gap Selling or all five) and what you already know about the prospect. You get an opening for the conversation, questions in the language of the prospect's sector and on what your solution covers, questions for each part of the framework, a closing and what to say to an objection. It uses only the inputs you give and says which it did not get.
| Name | Required | Description | Default |
|---|---|---|---|
| framework | Yes | Discovery framework to use | |
| deal_stage | No | Stage of conversation | |
| your_sector | No | Optional: your company's own industry (not your customers'). When given, it decides the sector notes; when left out, the tool reads it from your words and stays neutral if they are unclear. | |
| gaps_to_fill | No | Specific information gaps to address | |
| known_metrics | No | Metrics/KPIs already discussed | |
| prospect_role | No | Role of person you are meeting with | |
| your_solution | No | Your product/solution for relevant questions | |
| known_pain_points | No | Pain points already identified | |
| prospect_industry | No | Prospect industry for context | |
| contact_permission | No | Optional confirmed fact. Ask whether this person permits further contact; this answer overrides contact-refusal wording in the notes. |
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 goes beyond that by enumerating the returned sections and by stating it uses only supplied inputs and reports which it did not get — a genuinely useful behavioral trait for a prompt-assembly tool.
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?
Three sentences, front-loaded with the purpose and followed by input and output contracts, with no filler. Minor redundancy in the long parenthetical framework list and slightly chatty second-person phrasing, but nothing that wastes the agent's attention.
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 no output schema, the description supplies both the input expectation and the shape of the returned content, which is what an agent needs to select and call it. The remaining gap is routing guidance relative to its many siblings, which is a selection concern rather than a completeness one.
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%, including the useful note on your_sector versus prospect_industry and the contact_permission override, so the schema carries the semantic load. The description's only addition is enumerating the framework choices, which merely repeats the enum; it adds no new meaning about deal_stage, gaps_to_fill, or known_metrics.
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 output: it decides what to ask on a discovery call and returns an opening, framework-mapped questions, a closing, and objection handling. This distinguishes it from siblings like demo_script_builder or deal_strategy_coach without naming them, so it is clear but lacks explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies usage context ('Helps you decide what to ask on a discovery call') and tells the agent which inputs to supply, but gives no explicit when-not-to-use guidance and never mentions an alternative among the eleven sibling tools. The routing decision is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Helps you decide what to send, and when, to open or restart a conversation. You give the persona, stage and objective (prospecting, nurture, follow up or re engagement), plus your solution, the pain point, value proposition, proof and ask. You get each email with its subject, send day and body, and a note on what you did not give. No placeholder is left in a body, and no result or statistic is invented.
| Name | Required | Description | Default |
|---|---|---|---|
| tone | No | Email tone | |
| num_emails | No | Accepted but not used yet: each sequence type has a fixed number of emails | |
| your_sector | No | Optional: your company's own industry (not your customers'). When given, it decides the sector notes; when left out, the tool reads it from your words and stays neutral if they are unclear. | |
| social_proof | No | Customer names, stats, or proof points | |
| sequence_type | Yes | Type of email sequence. cold_outreach, warm_follow_up, post_demo and re_engagement have their own templates; the other types return a general outline | |
| your_solution | Yes | Your product/solution | |
| call_to_action | No | Desired action (meeting, demo, reply) | |
| key_value_prop | No | Primary value proposition | |
| sender_context | No | Context about sender (role, shared connections, etc.) | |
| target_persona | Yes | Target persona (e.g., VP Sales, CTO, CFO) | |
| target_industry | No | Target industry for context | |
| specific_pain_point | No | Specific pain point to address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly, non-destructive and closed-world, so the bar is lower. The description adds real behavioral value beyond them: every email comes with subject, send day and body, a note on inputs the caller omitted is returned, no placeholder is left in a body, and no statistic is fabricated. It does not say whether output is persisted or how long sequences run, which keeps it short of a 5.
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?
Three sentences, front-loaded with the purpose, then the inputs, then the output shape and guarantees. Every clause carries information; nothing repeats the schema verbatim or pads the definition.
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 12 parameters, 3 required and no output schema, the description needs to sketch the return shape, and it does so (subject, send day, body, omission note). It is complete enough to call correctly, though it leaves open whether sequence length varies by type and how tone interacts with the generated copy.
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 meaning by grouping the inputs into what you supply (persona, stage/objective, solution, pain point, value proposition, proof, ask) and by implying the tool reports back what was not given. Tone, sender_context and your_sector are not addressed in prose, so the gain over the schema is modest rather than 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 states a concrete verb+resource: it produces an email sequence, with each email's subject, send day and body. It also scopes the purpose to opening or restarting a conversation, which separates it from siblings like proposal_section_writer or discovery_question_bank. It never names a sibling explicitly, so differentiation is inferred rather than stated.
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?
It gives clear context for use: prospecting, nurture, follow-up or re-engagement conversations, and lists the inputs that select the right sequence. There are no explicit exclusions or named alternatives for adjacent tasks such as post-demo or proposal follow-up, so the agent must infer boundaries from the schema enum.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Helps you decide what has to happen, by whom and when, for a deal to sign on time. You give the deal name and the target close date, plus the current stage, the buyer's champion, economic buyer and evaluators, known requirements and process steps if you have them. You get a close plan both sides can work from, with milestones, owners and dates.
| Name | Required | Description | Default |
|---|---|---|---|
| blockers | No | Known blockers or concerns | |
| deal_name | Yes | Deal/opportunity name | |
| your_sector | No | Optional: your company's own industry (not your customers'). When given, it decides the sector notes; when left out, the tool reads it from your words and stays neutral if they are unclear. | |
| current_stage | No | Current deal stage | |
| your_solution | No | What you are selling | |
| buyer_champion | No | Champion name and title | |
| economic_buyer | No | Economic buyer name and title | |
| target_close_date | Yes | Target close date (YYYY-MM-DD). A Saturday or Sunday date moves to the Friday before, and the plan says so | |
| known_requirements | No | Known requirements or evaluation criteria | |
| known_process_steps | No | Known steps in their buying process, separated by semicolons or new lines (for example: Pilot; security review; procurement). Each step becomes its own milestone | |
| procurement_contact | No | Procurement contact if known | |
| technical_evaluators | No | Technical evaluators involved |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, non-destructive and closed-world, so safety is covered. The description adds real context on top: what the output artifact is ('a close plan both sides can work from, with milestones, owners and dates') and that weekend close dates roll back to the preceding Friday with the change flagged.
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?
Front-loaded with the purpose, followed by inputs and then the returned artifact, in three clean sentences. The middle sentence is a laundry list that largely duplicates the schema, but the overall length is proportionate to a 12-parameter tool.
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 12-parameter generator with no output schema and read-only annotations, the description covers purpose, minimum required inputs, optional enrichment and the shape of the result. It stops short of explaining what happens with sparse input or how milestones are prioritized, but nothing essential to calling it is missing.
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 12 parameters is already documented in structured form, including the sector inference fallback and the semicolon/newline format for process steps. The description only restates which inputs are needed versus optional, adding little beyond the schema; 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 concrete verb-and-artifact: it produces a close plan with milestones, owners and dates for a deal to sign on time. That is distinguishable from siblings like account_plan_builder or deal_strategy_coach, though the description never names an alternative to sharpen 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?
Usage is implied rather than stated: you invoke it when you need a mutual close plan and have at least a deal name and target close date. It notes that stage, buyer roles and process steps are optional ('if you have them'), but there is no explicit when-not guidance or comparison to the other planning tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Helps you decide how to answer a discount request without giving away margin. You give the negotiation scenario, plus deal value, the discount asked, each side's leverage and who approves. You get a leverage assessment, a value based negotiation strategy, answers to common pushback and a discount approval framework. Ask whether the user has authority to approve the proposed terms.
| Name | Required | Description | Default |
|---|---|---|---|
| scenario | Yes | Negotiation scenario | |
| deal_value | No | Current deal value | |
| your_sector | No | Optional: your company's own industry (not your customers'). When given, it decides the sector notes; when left out, the tool reads it from your words and stays neutral if they are unclear. | |
| your_leverage | No | Your leverage points (unique features, timeline, etc.) | |
| your_solution | No | Your product/solution. Named in the guide and used, with your leverage, to read the sector and how you charge | |
| business_model | No | Optional: how you charge (software subscription, services, connectivity, per transaction, marketplace, hardware plus software, or investment management). Read from your other inputs when left out | |
| buyer_leverage | No | Buyer leverage points (size, reference potential, etc.) | |
| value_delivered | No | Quantified value your solution delivers. Used in the value reframe, word for word; the guide adds no value figure of its own | |
| competitor_price | No | Competitor pricing if known | |
| decision_timeline | No | When decision needs to be made | |
| approval_authority | No | Who has final approval on pricing | |
| discount_requested | No | Discount percentage requested | |
| pricing_authority_status | No | Optional confirmed fact. Ask whether the user can approve this price or discount. Free-text role titles do not establish authority; unconfirmed authority holds commitment to terms. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and no destruction, so the bar is lower, yet the description still adds value by disclosing the output shape: leverage assessment, value-based strategy, pushback answers, and a discount approval framework. It does not discuss length, format, or any limits, which keeps it below a 5.
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 outcome and margin constraint are front-loaded, followed by inputs and outputs in a compact three-sentence flow. The trailing instruction about approval authority is somewhat disjointed from the descriptive framing but is short and actionable.
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 13-parameter advisory tool with no output schema, the description covers purpose, required inputs, and the returned artifacts well enough to call it correctly. The fallback and inference behaviors are carried by the schema rather than the description, which is acceptable but leaves the description near rather than fully complete.
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 schema descriptions are unusually rich, including inference behavior for your_sector, business_model, and pricing_authority_status. The description only restates a subset of the inputs, so it adds little semantic meaning beyond the schema; 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 states a specific purpose with a clear outcome ("decide how to answer a discount request without giving away margin") and enumerates what the tool returns. It does not name any sibling such as deal_strategy_coach or competitive_trap_setter, so an agent must infer the boundary from the scenario enum rather than from the text.
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?
It tells the agent what to supply ("You give the negotiation scenario, plus deal value, the discount asked, each side's leverage and who approves"), which implies usage, and adds one procedural instruction about confirming approval authority. There is no explicit when-not-to-use guidance and no routing to the obviously overlapping siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Helps you write one section of a proposal for a named buyer. You give the section you need (such as an executive summary, solution overview or pricing justification), your solution, the buyer's challenges, your differentiators, pricing and success measures. You get that section in sentences built from your inputs, with sector notes. It invents no figure, customer or date, and says once which inputs were not given.
| Name | Required | Description | Default |
|---|---|---|---|
| tone | No | Tone for the proposal (changes only the opening of the executive summary) | |
| pricing | No | Pricing details if relevant | |
| your_sector | No | Optional: your company's own industry (not your customers'). When given, it decides the sector notes; when left out, the tool reads it from your words and stays neutral if they are unclear. | |
| section_type | Yes | Proposal section to generate | |
| customer_name | No | Customer name | |
| your_solution | Yes | Your product/solution | |
| success_metrics | No | Expected outcomes/metrics | |
| primary_audience | No | Adds a one-line note at the top of the executive summary on what this audience looks for | |
| customer_industry | No | Customer industry | |
| customer_challenges | No | Key challenges identified | |
| key_differentiators | No | Why you vs alternatives | |
| implementation_approach | No | How you will implement |
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 non-obvious behavior beyond that: it invents no figure, customer or date, it appends sector notes, and it reports missing inputs exactly once — all useful for trusting the output. It does not describe length or formatting of the returned section, which keeps it below a 5.
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?
Three sentences, front-loaded with the core action and then the input/output contract, with no filler or marketing language. The middle sentence is a dense comma list, but every item maps to a real parameter, so it earns its space.
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 12 parameters, full schema coverage and no output schema, the description does the necessary work: it describes the shape of the return (prose built from the inputs plus sector notes) and the missing-input disclosure. What remains unstated is output length, structure, and whether the section is returned alone or with surrounding context — minor for a read-only generator.
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 12 parameters including enum values and the note that tone affects only the executive summary opening. The description's input list largely restates those fields; its only added semantic value is that omitted sector input is inferred from the user's words and stays neutral when unclear, which is also present in the schema. 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 — 'write one section of a proposal for a named buyer' — and enumerates example section types (executive summary, solution overview, pricing justification), which separates it from siblings like roi_business_case_builder or demo_script_builder. It stops short of explicitly naming an alternative tool, so it is clear but not maximally differentiated.
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 the usage context by listing the inputs to supply (section, solution, buyer challenges, differentiators, pricing, success measures), which tells an agent roughly when the tool applies. It never states when NOT to use it or points to a sibling for adjacent jobs such as a full business case or a demo script, so routing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Helps you build an ROI case the buyer's finance team can check. You give your solution, its main value driver and the buyer's own figures: an annual value estimate, or current annual cost with the expected improvement percent. With them you get the ROI, payback, three year value and sensitivity. Without them it shows no ROI: it names the inputs to add and gives the structure of the case (the cost lines to price, your quoted results as reference points, the questions to ask). Ask finance for the cash-only annual benefit when an investment decision depends on cash.
| Name | Required | Description | Default |
|---|---|---|---|
| industry | No | The customer's industry, in any words. Used for wording and sector notes only: no industry figure is applied to the calculation. A return needs the buyer's own figures (annual value estimate, or current annual cost with expected improvement percent) | |
| your_sector | No | Optional: your company's own industry (not your customers'). When given, it decides the sector notes; when left out, the tool reads it from your words and stays neutral if they are unclear. | |
| company_size | No | Company size tier | |
| customer_name | No | Customer/prospect name | |
| known_metrics | No | Metrics the prospect shared, or results you can quote. Listed as reference points, never as the buyer's figures; to turn the buyer's figures into the value, give current annual cost and expected improvement percent, or annual value estimate | |
| your_solution | Yes | Your product/solution | |
| annual_revenue | No | Customer annual revenue. Shown as your input; it is not turned into a value | |
| employee_count | No | Number of employees. Shown as your input; it is not turned into a value | |
| solution_price | No | Annual cost of your solution | |
| current_process | No | How they do it today. Separate the ways of working with a semicolon: each becomes a cost line to price. Not used in the calculation | |
| annual_cash_benefit | No | Optional buyer-confirmed annual cash benefit in US dollars, excluding staff time without a cash release. Ask finance to separate cash from non-cash value. Compared with the annual solution price; a cash deficit holds the investment decision. | |
| current_annual_cost | No | Optional: what the problem or the current process costs the buyer a year, in dollars (their figure) | |
| primary_value_driver | Yes | Primary value category | |
| annual_value_estimate | No | Optional: the buyer's own estimate of the annual value in dollars; used as the value when given | |
| implementation_timeline | No | Expected implementation time. Shown in the output; not used in the calculation | |
| expected_improvement_percent | No | Optional: the share of that annual cost the buyer expects to save, in percent (their figure) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, non-destructive, closed-world behavior, so the description earns credit for disclosing the degraded path: with no buyer figures it returns no ROI, instead naming the missing inputs and laying out the case structure. It also enumerates the computed outputs (ROI, payback, three-year value, sensitivity), which is real behavioral context the annotations cannot convey.
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 paragraph is front-loaded with the purpose and the two operating modes, then closes with a conditional data-gathering tip. Sentences are dense but each carries information; the finance/cash sentence is the only one that reads slightly tangential and could be folded into the figures sentence.
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 16-parameter tool with only 2 required fields and no output schema, the description covers what is needed: required inputs, the fallback when figures are absent, and the shape of the returned analysis. It stops short of stating units or formatting expectations for the computed outputs, but nothing essential to invoking it correctly is missing.
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 already 100%, so the baseline would be 3, but the description adds a cross-parameter rule the schema only states piecemeal: value comes either from an annual value estimate or from current annual cost combined with expected improvement percent. It also reinforces the buyer-figure vs. reference-point distinction that governs several optional fields, which is the key semantic trap in this 16-parameter 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?
The description names a specific verb and artifact ('build an ROI case') and states the two required ingredients (solution, primary value driver) plus the buyer figures needed to produce numbers. It is clearly distinguishable from the sibling builders, which cover plans, demos, and proposals rather than financial justification, though it never explicitly contrasts itself with them.
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?
It gives a clear when-to-use condition by splitting the two modes: with buyer figures you get computed ROI, without them you get an input checklist and case structure. It adds a situational instruction ('Ask finance for the cash-only annual benefit when an investment decision depends on cash'), but does not name any alternative tool or state when a different builder is the better choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Helps you decide why you won or lost and what to change. You give the details of one deal, a competitor pattern or a set of deals. You get a short write up that names the outcome, the stated reason in the buyer's words, what the reason points to and what the buyer weighed, then questions for the review call and sector notes. It adds no figure or reason you did not give, and says what a missing outcome or reason would add.
| Name | Required | Description | Default |
|---|---|---|---|
| deal_value | No | Deal value | |
| loss_reason | No | Stated loss reason (for lost deals) | |
| your_sector | No | Optional: your company's own industry (not your customers'). When given, it decides the sector notes; when left out, the tool reads it from your words and stays neutral if they are unclear. | |
| deal_details | No | Deal details, can be rough notes, CRM export, or structured data | |
| deal_outcome | No | Deal outcome for single deal analysis | |
| analysis_type | Yes | Type of analysis | |
| your_solution | No | What you were selling | |
| competitor_won | No | Competitor who won (if applicable) | |
| multiple_deals | No | For portfolio analysis: summary of multiple deals | |
| sales_cycle_days | No | Length of sales cycle | |
| stakeholders_involved | No | Key stakeholders and their positions |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as a read-only, non-destructive, closed-world tool. Beyond that, the description adds meaningful behavioral context: it says the write-up will not invent figures or reasons, and it explains how missing outcomes or reasons 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the purpose and then explains input and output expectations in a compact way. It is dense but avoids repetition and unnecessary filler.
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 analytical tool with full schema coverage and annotations, the description is largely complete. It explains the output content in lieu of an output schema and clarifies non-fabrication behavior, though it could say more about when to use this tool versus its siblings.
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 parameter definitions already carry most semantic weight. The description adds useful framing about the types of deal inputs and the output structure, but it does not add specific meaning to individual parameters beyond what the schema provides.
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 analytical purpose: explain why a deal was won or lost and what to change. It covers the scope of inputs (one deal, competitor pattern, or set of deals) and the kind of write-up produced, though it does not explicitly position itself against sibling tools such as 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?
It gives implied usage contexts by naming single deals, competitor patterns, and deal sets, which map to the analysis_type enum. However, it does not state when to choose this tool over related siblings or provide exclusions for when it is inappropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
account_plan_builder1 field changedInput schema / properties / known_contacts / descriptionPrevious value: -"Known contacts and their roles, one per line or separated by semicolons, for example: Head of RevOps (champion); CFO. Each entry becomes one row, so put other notes in account_notes"New value: +"Known contacts and their roles, one per line or separated by semicolons, for example: Head of RevOps (champion); CFO. Each entry becomes one row, so put other notes in account notes"deal_strategy_coach4 fields changedInput schema / properties / blocker_statusAdded value: +{
+ "description": "Ask whether any blocker is present. A confirmed typed fact overrides word reading.",
+ "enum": [
+ "none",
+ "present",
+ "unknown"
+ ],
+ "type": "string"
+}Input schema / properties / economic_buyer_engagementAdded value: +{
+ "description": "Ask whether the budget holder actively participates in this decision. Overrides word reading.",
+ "enum": [
+ "engaged",
+ "not_engaged",
+ "unknown"
+ ],
+ "type": "string"
+}Input schema / properties / incumbent_statusAdded value: +{
+ "description": "Ask whether the buyer already uses a competing supplier. Overrides word reading.",
+ "enum": [
+ "present",
+ "none",
+ "unknown"
+ ],
+ "type": "string"
+}Input schema / properties / project_statusAdded value: +{
+ "description": "Ask whether the project is still active. A cancelled project is held, without a close plan.",
+ "enum": [
+ "active",
+ "cancelled",
+ "unknown"
+ ],
+ "type": "string"
+}discovery_question_bank1 field changedInput schema / properties / contact_permissionAdded value: +{
+ "description": "Optional confirmed fact. Ask whether this person permits further contact; this answer overrides contact-refusal wording in the notes.",
+ "enum": [
+ "allowed",
+ "declined",
+ "unknown"
+ ],
+ "type": "string"
+}pricing_negotiation_guide1 field changedInput schema / properties / pricing_authority_statusAdded value: +{
+ "description": "Optional confirmed fact. Ask whether the user can approve this price or discount. Free-text role titles do not establish authority; unconfirmed authority holds commitment to terms.",
+ "enum": [
+ "authorized",
+ "not_authorized",
+ "unknown"
+ ],
+ "type": "string"
+}roi_business_case_builder3 fields changedInput schema / properties / annual_cash_benefitAdded value: +{
+ "description": "Optional buyer-confirmed annual cash benefit in US dollars, excluding staff time without a cash release. Ask finance to separate cash from non-cash value. Compared with the annual solution price; a cash deficit holds the investment decision.",
+ "minimum": 0,
+ "type": "number"
+}Input schema / properties / industry / descriptionPrevious value: -"The customer's industry, in any words. Used for wording and sector notes only: no industry figure is applied to the calculation. A return needs the buyer's own figures (annual_value_estimate, or current_annual_cost with expected_improvement_percent)"New value: +"The customer's industry, in any words. Used for wording and sector notes only: no industry figure is applied to the calculation. A return needs the buyer's own figures (annual value estimate, or current annual cost with expected improvement percent)"Input schema / properties / known_metrics / descriptionPrevious value: -"Metrics the prospect shared, or results you can quote. Listed as reference points, never as the buyer's figures; to turn the buyer's figures into the value, give current_annual_cost and expected_improvement_percent, or annual_value_estimate"New value: +"Metrics the prospect shared, or results you can quote. Listed as reference points, never as the buyer's figures; to turn the buyer's figures into the value, give current annual cost and expected improvement percent, or annual value estimate"account_plan_builder1 field changedInput schema / properties / known_contacts / descriptionPrevious value: -"Known contacts and their roles (can be rough notes)"New value: +"Known contacts and their roles, one per line or separated by semicolons, for example: Head of RevOps (champion); CFO. Each entry becomes one row, so put other notes in account_notes"mutual_action_plan_generator2 fields changedInput schema / properties / known_process_steps / descriptionPrevious value: -"Known steps in their buying process"New value: +"Known steps in their buying process, separated by semicolons or new lines (for example: Pilot; security review; procurement). Each step becomes its own milestone"Input schema / properties / target_close_date / descriptionPrevious value: -"Target close date (YYYY-MM-DD)"New value: +"Target close date (YYYY-MM-DD). A Saturday or Sunday date moves to the Friday before, and the plan says so"account_plan_builder1 field changedInput schema / properties / your_sectorAdded value: +{
+ "description": "Optional: your company's own industry (not your customers'). When given, it decides the sector notes; when left out, the tool reads it from your words and stays neutral if they are unclear.",
+ "enum": [
+ "logistics_tech",
+ "fintech",
+ "saas",
+ "vertical_saas",
+ "ai_native",
+ "ites",
+ "telecom",
+ "software",
+ "cybersecurity",
+ "other"
+ ],
+ "type": "string"
+}champion_enablement_kit1 field changedInput schema / properties / your_sectorAdded value: +{
+ "description": "Optional: your company's own industry (not your customers'). When given, it decides the sector notes; when left out, the tool reads it from your words and stays neutral if they are unclear.",
+ "enum": [
+ "logistics_tech",
+ "fintech",
+ "saas",
+ "vertical_saas",
+ "ai_native",
+ "ites",
+ "telecom",
+ "software",
+ "cybersecurity",
+ "other"
+ ],
+ "type": "string"
+}competitive_trap_setter1 field changedInput schema / properties / your_sectorAdded value: +{
+ "description": "Optional: your company's own industry (not your customers'). When given, it decides the sector notes; when left out, the tool reads it from your words and stays neutral if they are unclear.",
+ "enum": [
+ "logistics_tech",
+ "fintech",
+ "saas",
+ "vertical_saas",
+ "ai_native",
+ "ites",
+ "telecom",
+ "software",
+ "cybersecurity",
+ "other"
+ ],
+ "type": "string"
+}deal_strategy_coach1 field changedInput schema / properties / your_sectorAdded value: +{
+ "description": "Optional: your company's own industry (not your customers'). When given, it decides the sector notes; when left out, the tool reads it from your words and stays neutral if they are unclear.",
+ "enum": [
+ "logistics_tech",
+ "fintech",
+ "saas",
+ "vertical_saas",
+ "ai_native",
+ "ites",
+ "telecom",
+ "software",
+ "cybersecurity",
+ "other"
+ ],
+ "type": "string"
+}demo_script_builder1 field changedInput schema / properties / your_sectorAdded value: +{
+ "description": "Optional: your company's own industry (not your customers'). When given, it decides the sector notes; when left out, the tool reads it from your words and stays neutral if they are unclear.",
+ "enum": [
+ "logistics_tech",
+ "fintech",
+ "saas",
+ "vertical_saas",
+ "ai_native",
+ "ites",
+ "telecom",
+ "software",
+ "cybersecurity",
+ "other"
+ ],
+ "type": "string"
+}discovery_question_bank1 field changedInput schema / properties / your_sectorAdded value: +{
+ "description": "Optional: your company's own industry (not your customers'). When given, it decides the sector notes; when left out, the tool reads it from your words and stays neutral if they are unclear.",
+ "enum": [
+ "logistics_tech",
+ "fintech",
+ "saas",
+ "vertical_saas",
+ "ai_native",
+ "ites",
+ "telecom",
+ "software",
+ "cybersecurity",
+ "other"
+ ],
+ "type": "string"
+}email_sequence_generator1 field changedInput schema / properties / your_sectorAdded value: +{
+ "description": "Optional: your company's own industry (not your customers'). When given, it decides the sector notes; when left out, the tool reads it from your words and stays neutral if they are unclear.",
+ "enum": [
+ "logistics_tech",
+ "fintech",
+ "saas",
+ "vertical_saas",
+ "ai_native",
+ "ites",
+ "telecom",
+ "software",
+ "cybersecurity",
+ "other"
+ ],
+ "type": "string"
+}mutual_action_plan_generator1 field changedInput schema / properties / your_sectorAdded value: +{
+ "description": "Optional: your company's own industry (not your customers'). When given, it decides the sector notes; when left out, the tool reads it from your words and stays neutral if they are unclear.",
+ "enum": [
+ "logistics_tech",
+ "fintech",
+ "saas",
+ "vertical_saas",
+ "ai_native",
+ "ites",
+ "telecom",
+ "software",
+ "cybersecurity",
+ "other"
+ ],
+ "type": "string"
+}pricing_negotiation_guide3 fields changedInput schema / properties / value_delivered / descriptionPrevious value: -"Quantified value your solution delivers. Shown in the output; the value example does not use it"New value: +"Quantified value your solution delivers. Used in the value reframe, word for word; the guide adds no value figure of its own"Input schema / properties / your_sectorAdded value: +{
+ "description": "Optional: your company's own industry (not your customers'). When given, it decides the sector notes; when left out, the tool reads it from your words and stays neutral if they are unclear.",
+ "enum": [
+ "logistics_tech",
+ "fintech",
+ "saas",
+ "vertical_saas",
+ "ai_native",
+ "ites",
+ "telecom",
+ "software",
+ "cybersecurity",
+ "other"
+ ],
+ "type": "string"
+}Input schema / properties / your_solution / descriptionPrevious value: -"Accepted but not used yet by this tool"New value: +"Your product/solution. Named in the guide and used, with your leverage, to read the sector and how you charge"proposal_section_writer2 fields changedInput schema / properties / primary_audience / descriptionPrevious value: -"Accepted but not used yet: the text is the same for every audience"New value: +"Adds a one-line note at the top of the executive summary on what this audience looks for"Input schema / properties / your_sectorAdded value: +{
+ "description": "Optional: your company's own industry (not your customers'). When given, it decides the sector notes; when left out, the tool reads it from your words and stays neutral if they are unclear.",
+ "enum": [
+ "logistics_tech",
+ "fintech",
+ "saas",
+ "vertical_saas",
+ "ai_native",
+ "ites",
+ "telecom",
+ "software",
+ "cybersecurity",
+ "other"
+ ],
+ "type": "string"
+}roi_business_case_builder6 fields changedInput schema / properties / annual_revenue / descriptionPrevious value: -"Customer annual revenue"New value: +"Customer annual revenue. Shown as your input; it is not turned into a value"Input schema / properties / current_process / descriptionPrevious value: -"How they do it today. Shown in the output; not used in the calculation"New value: +"How they do it today. Separate the ways of working with a semicolon: each becomes a cost line to price. Not used in the calculation"Input schema / properties / employee_count / descriptionPrevious value: -"Number of employees"New value: +"Number of employees. Shown as your input; it is not turned into a value"Input schema / properties / industry / descriptionPrevious value: -"Industry for the example benchmarks: Technology, Financial_Services, Healthcare, Manufacturing or Retail (exact spelling). Any other value uses Technology"New value: +"The customer's industry, in any words. Used for wording and sector notes only: no industry figure is applied to the calculation. A return needs the buyer's own figures (annual_value_estimate, or current_annual_cost with expected_improvement_percent)"Input schema / properties / known_metrics / descriptionPrevious value: -"Metrics the prospect shared. Shown in the output; to turn them into the value, give current_annual_cost and expected_improvement_percent, or annual_value_estimate"New value: +"Metrics the prospect shared, or results you can quote. Listed as reference points, never as the buyer's figures; to turn the buyer's figures into the value, give current_annual_cost and expected_improvement_percent, or annual_value_estimate"Input schema / properties / your_sectorAdded value: +{
+ "description": "Optional: your company's own industry (not your customers'). When given, it decides the sector notes; when left out, the tool reads it from your words and stays neutral if they are unclear.",
+ "enum": [
+ "logistics_tech",
+ "fintech",
+ "saas",
+ "vertical_saas",
+ "ai_native",
+ "ites",
+ "telecom",
+ "software",
+ "cybersecurity",
+ "other"
+ ],
+ "type": "string"
+}win_loss_analyzer1 field changedInput schema / properties / your_sectorAdded value: +{
+ "description": "Optional: your company's own industry (not your customers'). When given, it decides the sector notes; when left out, the tool reads it from your words and stays neutral if they are unclear.",
+ "enum": [
+ "logistics_tech",
+ "fintech",
+ "saas",
+ "vertical_saas",
+ "ai_native",
+ "ites",
+ "telecom",
+ "software",
+ "cybersecurity",
+ "other"
+ ],
+ "type": "string"
+}account_plan_builderchampion_enablement_kitcompetitive_trap_setterdeal_strategy_coachdemo_script_builderdiscovery_question_bankemail_sequence_generatormutual_action_plan_generatorpricing_negotiation_guideproposal_section_writerroi_business_case_builderwin_loss_analyzerCRAFT GTM: 8 go to market strategy tools by Helix GTM Consulting
ICP Intelligence: 9 ideal customer profile tools by Helix GTM Consulting
IMPACT: 8 B2B positioning and messaging tools by Helix GTM Consulting
15 AI revenue intelligence tools for Salesforce — pipeline, deals, coaching, competitors.
Add one secure layer between your agents and this server.