您的 AI SDR 还在盲目猜测？我的 AI 正在完成成交。
为 AI 智能体打造的实战型 B2B 销售手册——基于在 Criteo（268% 配额达成）、Deel（120 亿美元估值）、HBO、Bloomberg、Autodesk 和 Levi's 积累的 10 年企业级交易经验。
作者：Elisabeth Hitz。
AI 智能体在销售中表现不佳，因为它们：
未挖掘需求就急于推销 —— 向根本不是买家的人推销功能
面对异议时退缩，只会说“我理解您的顾虑”（这是投降，而非回应）
使用“只是跟进一下”进行回访 —— 这种每个人都能识别的套路，回复率几乎为零
将 EMEA（欧洲、中东和非洲）视为单一市场 —— 在 5 个以上不同的文化中透支信任
只提供单一价格，而不是提供能提高转化率的“三选一”菜单
结果：线索被浪费、销售序列失效、营收流失。
Related MCP server: shadowprice
10 个可调用的工具，为您的 AI 智能体提供数十年的真实企业销售经验——而非博客文章中的理论。包含逐字脚本、特定国家/地区的销售手册，以及价值 5 万至 50 万美元交易中经过心理学验证的异议处理方案。
工具 | 功能 |
| 5 种语调 × 需求挖掘框架。通过在推销前进行需求挖掘，使成交率翻倍。 |
| 10 种最常见的 B2B 异议（价格、时机、决策权、被冷落等），提供能推动对话进展的重构话术。 |
| 4 种序列（提案后、通话后、冷启动、激活）。第 5 天的消息可重新激活 30–40% 的死线索。 |
| 7 种成交风格——假设成交、时间线、稀缺性、留存、选择、下一步。AI 根据上下文进行选择。 |
| 防止锚定效应并提高平均交易额的“三选一”菜单框架。 |
| 英国 / 爱尔兰 / 西班牙 / 德国 / 法国 / 荷兰 / 北欧。每个市场各不相同——AI 将获得专属手册。 |
| 模式中断、观察、共同联系人、案例研究、分手信。每篇均在 100 字以内。 |
| 包含时间分配的挖掘和冷呼叫框架。 |
| 9 种意味着“停止推销，开始成交”的信号。 |
| 用于微调您的智能体或加载为系统上下文的完整数据包。 |
仅为您 AI 智能体实际调用的内容付费。无订阅，无分级限制。
事件 | 价格 |
工具调用 | $0.05 |
EMEA 市场简报 | $0.10 |
完整手册导出 | $0.50 |
前 10 次调用免费 —— 在 Claude Desktop、Cursor、Cline 或任何兼容 MCP 的客户端上试用。
点击此 Apify 页面上的“Run”。将 tool 作为输入传入。完成。
git clone https://github.com/elibierhitz/smb-sales-mcp
cd smb-sales-mcp
npm install
npm run build添加到您的 Claude Desktop 配置中（Mac 上位于 ~/Library/Application Support/Claude/claude_desktop_config.json）：
{
"mcpServers": {
"smb-sales": {
"command": "node",
"args": ["/path/to/smb-sales-mcp/dist/main.js"]
}
}
}重启 Claude Desktop。测试一下：
"使用 smb-sales 处理这个异议：潜在客户说我们的价格太高了"
实战中的异议：
Prospect: "Your price is too high"
→ get_objection_response({ objection_type: "too_expensive" })
→ "Fair point — let me ask: is it the total investment that feels off,
or the value relative to what you're getting? Because I can usually
solve one of those."激活死线索：
Prospect went silent 5 days after proposal
→ get_followup_sequence({ sequence_type: "post_proposal" })
→ Day 5 message: "Had a thought for your [product]: [specific idea].
Want me to build that into Option B?"
(Reopens 30–40% of dead conversations.)向德国销售：
First touch with German prospect
→ get_emea_intelligence({ country: "germany" })
→ "Most process-oriented market in EMEA. Lead with data and detailed
proposals. Use formal address (Herr/Frau Last Name). Expect 6–12 week
cycles for SMB. GDPR compliance non-negotiable. Don't be casual."AI SDR 平台（11x, Artisan, Landbase, Alta），需要真实的训练数据
外呼自动化工具，希望获得比“只是跟进一下”更高的转化率
CRM AI 助手，对实时交易做出智能建议
销售辅导机器人，需要经过验证的脚本框架
线索挖掘智能体，需要结构化的挖掘流程
构建销售 AI 的创始人，希望在不聘请销售顾问的情况下获得专家数据
网上大多数销售内容都是理论。这些内容来自实战一线。
268% 的配额意味着持续达成超过 2.5 倍的目标。 此 MCP 服务器中的脚本不是博客文章中的最佳实践，而是 HBO、Bloomberg 和 Autodesk 价值 5 万至 50 万美元交易中真正有效的经验。
您的 AI 智能体可以通过 API 调用获得这些经验。
大多数 AI SDR 工具假设 EMEA 是一个单一市场。事实并非如此。
国家 | 有效策略 | 致命错误 | 周期 |
🇬🇧 英国 | 数据、具体性、冷幽默 | 夸张词汇、激进跟进 | 2–4 周 SMB |
🇮🇪 爱尔兰 | 温暖的介绍、都柏林科技背景 | 将其视为伦敦 | 推荐下更快 |
🇪🇸 西班牙 | 长期建立信任、针对 SMB 使用西班牙语 | 催促、8 月份发布 | 4–8 周 SMB |
🇩🇪 德国 | 文档、正式称呼、GDPR | 随意语调、模糊声明 | 6–12 周 SMB |
🇫🇷 法国 | 法语、知识严谨性 | 通用群发消息 | 4–8 周 SMB |
🇳🇱 荷兰 | 直接、透明、快速 | 过度承诺、废话 | EMEA 最快之一 |
🇸🇪 北欧 | 共识、可持续性框架 | 硬推销、下班后邮件 | 3–6 周 SMB |
基于在 Deel、Autodesk、Criteo、Red Points 超过 5 年的 EMEA 企业销售经验构建。
Elisabeth Hitz — 驻巴塞罗那的瑞士裔美国 B2B 销售高管。
Criteo 268% 配额达成
Deel 167% 配额达成（120 亿美元估值）
在 HBO、Bloomberg、Autodesk、Levi's、Rolling Stone、McCann、VML 完成企业级交易
5 年以上在英国、德国、西班牙、法国、爱尔兰的 EMEA 销售经验
目前正在构建 closermethod.com 以及为 AI 智能体生态系统提供销售工具
LinkedIn: linkedin.com/in/elisabethhitz
适用于任何兼容 MCP 的客户端：
Claude Desktop
Cursor
Cline
Windsurf
自定义 MCP 实现
如果您正在构建 11x/Artisan/Alta 风格的产品，并希望获得扩展访问权限以微调您的智能体，请在 LinkedIn 上私信我。很高兴讨论白标合作。
MIT。使用它，修改它，发布它。
Get a list of buying signals to watch for during sales conversations.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates the tool returns a list, which is a read operation. With no annotations provided, this is adequate for a simple retrieval tool, but it does not disclose any potential side effects, data freshness, or authorization requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that immediately conveys the tool's purpose. It is efficiently front-loaded with no superfluous words.
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 zero-parameter tool with no output schema, the description is nearly complete. It could explain what a 'buying signal' entails, but the context from sibling tools (sales materials) makes it sufficient for an agent in that domain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters and is fully described. The description adds no parameter information, which is acceptable given the schema coverage is 100% and there is nothing to add. Baseline score 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?
The description clearly states the tool retrieves a list of buying signals for sales conversations. The verb 'Get' and noun 'buying signals' are specific and distinguish it from sibling tools that retrieve specific scripts or templates.
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 guidance is provided on when to use this tool versus alternatives. There is no mention of context, prerequisites, or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a call script for discovery calls or cold calls.
| Name | Required | Description | Default |
|---|---|---|---|
| call_type | Yes | The type of call script needed |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as whether the operation is read-only, required permissions, or what the output format is. This leaves the agent with minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no extraneous information. It is appropriately sized for the tool's simplicity, though it could be more structured with additional context. No wasted content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks information about the output (e.g., format, structure). Given the absence of an output schema, the description should clarify what the agent can expect to receive. It also does not explain how 'call script' is defined, leaving ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the single parameter 'call_type' with full description and enum values. The description does not add extra meaning beyond restating the enum options. Baseline score of 3 is appropriate given 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves a call script for discovery or cold calls. It specifies the resource and type, distinguishing it from unrelated tools, but does not explicitly differentiate from the sibling tool 'get_discovery_script' which may overlap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing a script for discovery or cold calls, but provides no guidance on when to use this tool instead of siblings like 'get_discovery_script' or 'get_closing_script'. No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a closing script based on the situation.
| Name | Required | Description | Default |
|---|---|---|---|
| style | Yes | The closing style to use |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It only says 'Get a closing script,' which implies a read operation but does not describe any side effects, required permissions, or output format.
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 a single short sentence, which is concise but lacks structure. It front-loads the purpose but omits any additional details that would be helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one parameter, no output schema, no annotations), the description is incomplete. It does not explain the return format, the meaning of 'situation,' or how to choose a style. Provides minimal context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters and includes an enum for 'style.' However, the description adds no additional meaning beyond the schema; it does not explain how each style maps to different situations. Baseline 3 is appropriate for full schema coverage with no added value.
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 'Get a closing script based on the situation,' which clearly indicates the verb (get) and resource (closing script). However, it lacks specificity about what 'situation' means and does not distinguish from sibling tools like get_call_script or get_discovery_script.
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 guidance is provided on when to use this tool versus alternatives such as get_call_script or get_discovery_script. The phrase 'based on the situation' is vague and does not offer clear decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a cold email template for outbound.
| Name | Required | Description | Default |
|---|---|---|---|
| template_type | Yes | The type of cold email template |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure but only states the action. No mention of side effects, permissions, or read-only nature (though inferred from name). Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no superfluous words. It is front-loaded and efficient, though could include more detail without becoming verbose.
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 simple tool with one parameter and no output schema, the description provides basic purpose. However, it does not explain what the returned template looks like or any return value context, which could be helpful but is not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides a clear description for the single parameter, and enum values are self-explanatory. Schema coverage is 100%, so the description adds no additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a cold email template for outbound use. It is specific with verb and resource, and distinguishes from sibling tools like get_call_script or get_closing_script which target other communication materials.
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 lacks any guidance on when to use this tool versus alternatives. No explicit context, exclusions, or mention of appropriate scenarios beyond the implicit purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a discovery script to qualify prospects before pitching. Always ask questions first.
| Name | Required | Description | Default |
|---|---|---|---|
| tone | Yes | professional=email/linkedin, warm=existing relationship, ultra_short=DM, cold_outbound=first contact, inbound_lead=they reached out |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description should disclose behavioral traits like whether the script is static or dynamic, any side effects, or required context. It only states the purpose and a general rule, which is insufficient for a tool that likely influences sales behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise with two sentences that are front-loaded and waste no words, efficiently delivering the core message.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema, so the description covers the minimum necessary for a basic understanding. However, it lacks details on the script's structure or behavior, which could be improved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all parameters with detailed enum descriptions, so the description adds no extra meaning beyond the schema. The general advice 'Always ask questions first' does not relate directly to the 'tone' parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a discovery script for qualifying prospects before pitching, which differentiates it from siblings like get_call_script or get_closing_script that serve different stages.
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 instruction 'Always ask questions first' provides some usage context, but there is no explicit guidance on when to use this versus alternative tools, nor any mention of prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get market intelligence for selling to a specific European country.
| Name | Required | Description | Default |
|---|---|---|---|
| country | Yes | The EMEA market to get intelligence for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It only says 'get market intelligence,' without disclosing whether the operation is read-only, data freshness, format, or any constraints. This is insufficient for an agent to understand behavioral implications.
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 a single short sentence that conveys the essential purpose without any extraneous words. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's simplicity (one parameter, no output schema), the description lacks details about the nature of the intelligence, expected output format, or usage context. It feels incomplete for an agent to fully understand what the tool returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with a description for 'country'. The description adds the context 'for selling,' which slightly enriches understanding but does not significantly expand beyond the schema. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'get' and the resource 'market intelligence for selling to a specific European country'. It is specific with a verb and resource, and distinguishes from sibling tools which cover different sales content like buying signals or call scripts.
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 tool is for obtaining market intelligence for European countries, but does not explicitly state when to use it vs. alternatives. There are no exclusions or references to sibling tools, leaving the decision to the agent's inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a follow-up sequence for different situations (post-proposal, post-call, cold outbound, revival).
| Name | Required | Description | Default |
|---|---|---|---|
| sequence_type | Yes | The type of follow-up sequence needed |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description only restates purpose without disclosing behavioral traits (e.g., read-only, side effects, authentication needs, rate limits).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single efficient sentence with no wasted words, clearly conveying the tool's purpose and scope.
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 simple one-parameter tool: states purpose and enumerates types. Lacks explanation of return format (no output schema) but sufficient given low complexity.
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 has 100% coverage with enum descriptions; description adds no new meaning beyond 'different situations', which is already in 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?
Clearly states verb 'Get' and resource 'follow-up sequence', enumerates four specific situations in parentheses, distinguishing it from siblings like get_call_script or get_closing_script.
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?
Implies usage when a follow-up sequence is needed for listed situations, but provides no explicit when-not or alternative tools like get_cold_email_template for cold outbound.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the complete sales playbook with all modules.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Description only states what it gets, with no mention of behavioral traits like caching, rate limits, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, direct and to the point, no unnecessary words. Front-loaded with key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description is adequate for its simplicity. Could add context about what 'modules' includes or the format, but not essential.
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?
Input schema has zero parameters, and schema description coverage is 100%. Baseline of 4 applies; description adds no parameter info but none is needed.
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?
Description clearly states the tool retrieves the complete sales playbook with all modules. Name and description are specific enough to distinguish from sibling tools like get_call_script or get_discovery_script, though no explicit 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?
No guidance on when to use this tool versus alternatives. The description does not mention any prerequisites, exclusions, or context where this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Handle a specific sales objection with psychology-backed responses.
| Name | Required | Description | Default |
|---|---|---|---|
| objection_type | Yes | The type of objection to handle |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions 'psychology-backed' but does not disclose return format, side effects, or any special behavior. For a simple lookup tool, this is minimally adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence efficiently conveys the purpose. There is no wasted text, though it could potentially include more detail without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one required enum parameter and no output schema, the description is complete enough to understand its function. The lack of usage guidelines prevents a higher score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage with enum descriptions. The description adds no further meaning beyond what the schema already provides, warranting the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it handles a sales objection with psychology-backed responses, which distinguishes it from sibling tools like call scripts or email templates. The verb 'handle' is slightly vague but sufficient given the context of the enum parameter.
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 guidance is provided on when to use this tool versus alternatives like get_call_script or get_closing_script. The description implies usage when encountering an objection, but lacks explicit when-not-to-use or comparisons with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the 3-option pricing framework and templates.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states it 'gets' data, implying a read-only operation. It does not disclose any behavioral traits such as authentication requirements, potential errors, or what happens if the framework is unavailable.
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 a single, clear sentence with no superfluous words. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (no parameters, no output schema), the description is minimally adequate—it explains what the tool retrieves. However, it could be more helpful by mentioning the format or structure of the returned data (e.g., types of templates).
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?
There are no parameters in the input schema, so the description does not need to explain parameter behavior. The baseline for zero parameters is 4, and the description adds no additional parameter information, which is acceptable.
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 the verb 'Get' and clearly specifies 'pricing framework and templates' with '3-option' detail. While it distinguishes from sibling tools by focusing on pricing, it does not explicitly differentiate from similar content retrieval tools like get_full_playbook.
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 context is provided on when to use this tool versus alternatives among the many 'get_*' siblings. There is no guidance on prerequisites, typical use cases, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v3.0.0get_buying_signalsget_call_scriptget_closing_scriptget_cold_email_templateget_discovery_scriptget_emea_intelligenceget_followup_sequenceget_full_playbookget_objection_responseget_pricing_frameworkScored across 10 tools
Each tool targets a distinct aspect of sales (e.g., call scripts, email templates, objection responses). There is no overlap; an agent can clearly select the appropriate tool for a specific task.
All tools follow a consistent 'get_' prefix followed by a descriptive noun phrase (e.g., get_call_script, get_buying_signals). No mixed conventions or irregularities.
10 tools cover a comprehensive range of sales intelligence needs without being excessive. The count is well-scoped for a focused domain like SMB sales.
The tool set covers the full sales lifecycle: prospecting (cold email, discovery), calls (scripts, objections), closing (scripts, pricing), follow-ups, and market intelligence. No obvious gaps for the stated purpose.
Run B2B outreach from your AI agent: 250+ tools for campaigns, leads, LinkedIn and email workflows.
Agent-native CRM. 25 tools — contacts, deals, sequences, enrichment waterfall, audit log.
Free execution-focused playbooks. Brainstorm with other agents. Tip if helpful.
Human-in-the-loop LinkedIn outreach and a built-in sales CRM for AI agents. Safety-gated, anti-spam.
