あなたのAI SDRは推測で動いています。私のAIは成約させます。
Criteo（達成率268%）、Deel（120億ドル）、HBO、Bloomberg、Autodesk、Levi'sでの10年間にわたるエンタープライズ取引から構築された、実戦済みのB2Bセールス・プレイブックをAIエージェントに提供します。
作成者: Elisabeth Hitz
AIエージェントがセールスで失敗する理由：
ヒアリング前に売り込む — 購入者ですらない相手に機能の話をする
反論に対して「お気持ちは分かります」と引き下がる（対応ではなく降伏）
「状況確認です」というフォローアップを送る — 誰もが知っている、返信率がほぼゼロの定型文
EMEA（欧州・中東・アフリカ）を一つの市場として扱う — 5つ以上の異なる文化圏で信頼を損なう
単一の価格を提示する — 成約率を高める3つの選択肢メニューを提示しない
結果：リードの浪費、停滞した商談、取りこぼした収益。
Related MCP server: shadowprice
AIエージェントに、ブログ記事の理論ではない、数十年にわたる実際のエンタープライズ・セールスの経験を与える10個の呼び出し可能なツール。5万ドル〜50万ドルの取引から得られた、一言一句そのまま使えるスクリプト、国別のプレイブック、心理学に基づいた反論処理を提供します。
ツール | 機能 |
| 5つのトーン × ヒアリングフレームワーク。売り込む前にヒアリングを行うことで成約率を倍増させます。 |
| 最も一般的な10のB2B反論（価格、タイミング、決裁権、音信不通など）に対し、会話を前進させるための言い換えを提供します。 |
| 4つのシーケンス（提案後、通話後、コールド、掘り起こし）。5日目のメッセージで、死んだ商談の30〜40%を再開させます。 |
| 7つのクロージングスタイル（前提型、期限型、希少性型、リテイナー型、選択型、ネクストステップ型）。AIが文脈に応じて選択します。 |
| アンカリングを防ぎ、平均取引額を向上させる3つの選択肢メニュー。 |
| 英国 / アイルランド / スペイン / ドイツ / フランス / オランダ / 北欧。市場ごとに異なる戦略を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 buildClaude 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を一つの市場と見なしています。しかし、実際は違います。
国 | 有効な手法 | 商談を台無しにする手法 | サイクル |
🇬🇧 英国 | データ、具体性、ドライなユーモア | 最上級表現、強引なフォローアップ | SMB 2〜4週間 |
🇮🇪 アイルランド | 温かい紹介、ダブリンのテック事情 | ロンドンと同じ扱い | 紹介経由でより高速 |
🇪🇸 スペイン | 時間をかけた信頼構築、SMB向けスペイン語 | 急かすこと、8月のローンチ | SMB 4〜8週間 |
🇩🇪 ドイツ | ドキュメント、正式な宛名、GDPR | カジュアルなトーン、曖昧な主張 | SMB 6〜12週間 |
🇫🇷 フランス | フランス語、知的厳密さ | 一般的な大量メッセージ | SMB 4〜8週間 |
🇳🇱 オランダ | 直接的、透明性、迅速さ | 過剰な約束、中身のない言葉 | EMEAで最も高速 |
🇸🇪 北欧 | 合意形成、持続可能性のフレームワーク | 強引な売り込み、営業時間外のメール | SMB 3〜6週間 |
Deel、Autodesk、Criteo、Red Pointsでの5年以上にわたるEMEAエンタープライズ・セールスの経験から構築。
Elisabeth Hitz — バルセロナを拠点とするスイス系アメリカ人のB2Bセールスエグゼクティブ。
Criteoで達成率268%
Deel（評価額120億ドル）で達成率167%
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でDMをください。ホワイトラベル契約についても喜んで相談に応じます。
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.
