Ihr KI-SDR rät nur. Meiner schließt ab.
Kampferprobte B2B-Sales-Playbooks für KI-Agenten – basierend auf 10 Jahren Enterprise-Deals bei Criteo (268 % Quote), Deel (12 Mrd. $), HBO, Bloomberg, Autodesk und Levi's.
Von Elisabeth Hitz.
KI-Agenten scheitern im Vertrieb, weil sie:
Pitchen, bevor sie qualifizieren – sie sprechen über Funktionen mit Leuten, die gar keine Käufer sind.
Bei Einwänden einknicken mit „Ich verstehe Ihre Bedenken“ (eine Kapitulation, keine Antwort).
Mit „wollte nur mal nachhaken“ nachfassen – eine Antwortrate von nahezu null, die jeder sofort erkennt.
EMEA als einen Markt behandeln – und damit Vertrauen in über 5 verschiedenen Kulturen zerstören.
Einen Preis präsentieren, anstatt das 3-Optionen-Menü anzubieten, das tatsächlich konvertiert.
Das Ergebnis: verbrannte Leads, tote Sequenzen und liegen gelassener Umsatz.
Related MCP server: shadowprice
10 aufrufbare Tools, die Ihrem KI-Agenten jahrzehntelange Erfahrung im Enterprise-Vertrieb verleihen – keine Theorie aus einem Blog-Post. Wortwörtliche Skripte, länderspezifische Playbooks und psychologisch fundierte Einwandbehandlungen aus Deals im Wert von 50.000 $ bis 500.000 $.
Tool | Funktion |
| 5 Tonalitäten × Qualifizierungs-Frameworks. Verdoppelt die Abschlussraten durch Qualifizierung vor dem Pitch. |
| Die 10 häufigsten B2B-Einwände (Preis, Timing, Autorität, Ghosting…) mit Umformulierungen, die das Gespräch voranbringen. |
| 4 Sequenzen (nach Angebot, nach Call, Kaltakquise, Reaktivierung). Die Nachricht an Tag 5 reaktiviert 30–40 % der toten Konversationen. |
| 7 Abschlussstile – Annahme, Zeitplan, Verknappung, Retainer, Auswahl, nächster Schritt. Die KI wählt basierend auf dem Kontext. |
| Das 3-Optionen-Menü, das Anker-Effekte verhindert und die durchschnittliche Deal-Größe erhöht. |
| UK / Irland / Spanien / Deutschland / Frankreich / Niederlande / Nordics. Jeder Markt ist anders – die KI erhält das passende Playbook. |
| Musterunterbrechung, Beobachtung, gemeinsame Kontakte, Fallstudie, Trennung. Jeweils unter 100 Wörter. |
| Discovery- und Kaltakquise-Frameworks mit Zeitvorgaben. |
| Die 9 Signale, die bedeuten: „Aufhören zu pitchen, anfangen abzuschließen.“ |
| Kompletter Datensatz für das Fine-Tuning Ihres Agenten oder als System-Kontext. |
Zahlen Sie nur für das, was Ihr KI-Agent tatsächlich aufruft. Keine Abonnements, keine Stufenbeschränkungen.
Event | Preis |
Tool-Aufruf | 0,05 $ |
EMEA-Markt-Briefing | 0,10 $ |
Vollständiger Playbook-Dump | 0,50 $ |
Die ersten 10 Aufrufe sind kostenlos – testen Sie es auf Claude Desktop, Cursor, Cline oder einem beliebigen MCP-kompatiblen Client.
Klicken Sie auf dieser Apify-Seite auf „Run“. Übergeben Sie tool als Input. Fertig.
git clone https://github.com/elibierhitz/smb-sales-mcp
cd smb-sales-mcp
npm install
npm run buildFügen Sie dies zu Ihrer Claude Desktop-Konfiguration hinzu (~/Library/Application Support/Claude/claude_desktop_config.json auf dem Mac):
{
"mcpServers": {
"smb-sales": {
"command": "node",
"args": ["/path/to/smb-sales-mcp/dist/main.js"]
}
}
}Starten Sie Claude Desktop neu. Testen Sie es:
„Nutze smb-sales, um diesen Einwand zu behandeln: Der Interessent sagte, unser Preis sei zu hoch.“
Einwand in der Praxis:
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."Reaktivierung eines toten Deals:
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.)Verkauf nach Deutschland:
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."KI-SDR-Plattformen (11x, Artisan, Landbase, Alta), die echte Trainingsdaten benötigen.
Outbound-Automatisierungstools, die bessere Konversionsraten als „wollte nur mal nachhaken“ erzielen wollen.
CRM-KI-Assistenten, die intelligente Empfehlungen für laufende Deals geben.
Sales-Coaching-Bots, die bewährte Skript-Frameworks benötigen.
Lead-Qualifizierungs-Agenten, die strukturierte Discovery-Abläufe brauchen.
Gründer, die Sales-KI entwickeln und Expertenwissen ohne die Einstellung eines Sales-Consultants suchen.
Die meisten Sales-Inhalte online sind Theorie. Dies kommt direkt aus der Praxis.
268 % Quote bedeutet, konstant mehr als das 2,5-Fache des Ziels abzuschließen. Die Skripte in diesem MCP-Server sind keine Best Practices aus einem Blog-Post. Es ist das, was bei HBO, Bloomberg und Autodesk bei Deals im Wert von 50.000 $ bis 500.000 $ tatsächlich funktioniert hat.
Ihr KI-Agent erhält diese Erfahrung als API-Aufrufe.
Die meisten KI-SDR-Tools gehen davon aus, dass EMEA ein einziger Markt ist. Das ist er nicht.
Land | Was funktioniert | Was Deals zerstört | Zyklus |
🇬🇧 UK | Daten, Spezifität, trockener Humor | Superlative, aggressives Nachfassen | 2–4 Wo. SMB |
🇮🇪 Irland | Herzliche Intros, Dublin-Tech-Kontext | Behandlung wie London | Schneller mit Empfehlungen |
🇪🇸 Spanien | Vertrauen über Zeit, Spanisch für SMBs | Eile, August-Launches | 4–8 Wo. SMB |
🇩🇪 Deutschland | Dokumentation, formelle Anrede, DSGVO | Lässiger Ton, vage Behauptungen | 6–12 Wo. SMB |
🇫🇷 Frankreich | Französische Sprache, intellektuelle Strenge | Generische Massennachrichten | 4–8 Wo. SMB |
🇳🇱 Niederlande | Direkt, transparent, schnell | Überversprechen, Floskeln | Unter den schnellsten in EMEA |
🇸🇪 Nordics | Konsens, Nachhaltigkeitsfokus | Harte Verkäufe, E-Mails nach Feierabend | 3–6 Wo. SMB |
Entwickelt aus über 5 Jahren EMEA-Enterprise-Vertrieb bei Deel, Autodesk, Criteo, Red Points.
Elisabeth Hitz – Schweizerisch-amerikanische B2B-Sales-Führungskraft mit Sitz in Barcelona.
268 % Quote bei Criteo
167 % Quote bei Deel (12 Mrd. $ Bewertung)
Enterprise-Deals abgeschlossen bei HBO, Bloomberg, Autodesk, Levi's, Rolling Stone, McCann, VML
Über 5 Jahre Vertrieb in EMEA (UK, Deutschland, Spanien, Frankreich, Irland)
Baut jetzt closermethod.com und Sales-Tools für das KI-Agenten-Ökosystem
LinkedIn: linkedin.com/in/elisabethhitz
Funktioniert mit jedem MCP-kompatiblen Client:
Claude Desktop
Cursor
Cline
Windsurf
Benutzerdefinierte MCP-Implementierungen
Wenn Sie Produkte im Stil von 11x/Artisan/Alta entwickeln und erweiterten Zugriff für das Fine-Tuning Ihres Agenten wünschen, schreiben Sie mir auf LinkedIn. Ich freue mich darauf, White-Label-Deals zu besprechen.
MIT. Nutzen Sie es, modifizieren Sie es, veröffentlichen Sie es.
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.
