This server equips AI agents with battle-tested B2B sales frameworks, scripts, and playbooks across the full sales cycle.
Discovery Scripts (get_discovery_script): Qualify prospects using scripts in 5 tones (professional, warm, ultra-short, cold outbound, inbound lead).
Objection Handling (get_objection_response): Psychology-backed responses to 10 common objections (price, budget, authority, ghosting, bad timing, etc.).
Follow-Up Sequences (get_followup_sequence): Multi-day structured sequences for post-proposal, post-call, cold outbound, and deal revival.
Closing Scripts (get_closing_script): 7 closing styles (assumptive, timeline, scarcity, retainer, choice, next-step, standard) based on deal context.
Pricing Framework (get_pricing_framework): A 3-option pricing strategy to prevent anchoring and increase average deal size.
EMEA Market Intelligence (get_emea_intelligence): Country-specific playbooks for UK, Ireland, Spain, Germany, France, Netherlands, and Nordics — including what works, what kills deals, and typical sales cycles.
Cold Email Templates (get_cold_email_template): Under-100-word templates in 5 styles (pattern interrupt, observation, mutual connection, case study, breakup).
Call Scripts (get_call_script): Structured scripts with timing breakdowns for discovery calls and cold calls.
Buying Signals (get_buying_signals): The 9 key signals indicating a prospect is ready to close.
Full Playbook (get_full_playbook): Complete dump of all frameworks — ideal for fine-tuning AI agents or loading as system context.
Battle-tested B2B sales playbook frameworks for AI agents.
Built from 10+ years of B2B enterprise sales experience across ad-tech, SaaS, media, and global hiring — including a five-year stretch overshooting quota every year at a publicly-listed ad-tech company.
By Elisabeth Hitz.
Disclaimer. Structured general-best-practice sales frameworks. Not a substitute for tailored sales coaching, legal advice, or domain-specific consulting. Use as a starting layer, not a final source.
AI agents fail at sales because they:
Pitch before qualifying — talking about features to people who aren't even buyers
Fold on objections with "I understand your concern" (a surrender, not a response)
Follow up with "just checking in" — a near-zero reply rate everyone recognizes
Treat EMEA like one market — burning trust in 5+ different cultures
Present one price instead of giving the 3-option menu that converts
The result: burned leads, dead sequences, and revenue left on the table.
Related MCP server: shadowprice
10 callable tools that give your AI agent decades of real enterprise sales experience — not theory from a blog post. Word-for-word scripts, country-specific playbooks, and psychology-backed objection handlers from deals worth $50K–$500K.
Tool | What it does |
| 5 tones × qualification frameworks. Doubles close rates by qualifying before pitching. |
| 10 most common B2B objections (price, timing, authority, ghosting…) with reframes that advance the conversation. |
| 4 sequences (post-proposal, post-call, cold, revival). Day 5 message reopens 30–40% of dead conversations. |
| 7 closing styles — assumptive, timeline, scarcity, retainer, choice, next-step. AI picks based on context. |
| The 3-option menu that prevents anchoring and increases average deal size. |
| UK / Ireland / Spain / Germany / France / Netherlands / Nordics. Each market is different — the AI gets the playbook. |
| Pattern-interrupt, observation, mutual-connection, case-study, breakup. Under 100 words each. |
| Discovery and cold-call frameworks with timing breakdowns. |
| The 9 signals that mean "stop pitching, start closing." |
| Complete dump for fine-tuning your agent or loading as system context. |
Pay only for what your AI agent actually calls. No subscriptions, no tier gating.
Event | Price |
Tool call | $0.05 |
EMEA market brief | $0.10 |
Full playbook dump | $0.50 |
First 10 calls free — try it on Claude Desktop, Cursor, Cline, or any MCP-compatible client.
Click "Run" on this Apify page. Pass tool as input. Done.
git clone https://github.com/elibierhitz/smb-sales-mcp
cd smb-sales-mcp
npm install
npm run buildAdd to your Claude Desktop config (~/Library/Application Support/Claude/claude_desktop_config.json on Mac):
{
"mcpServers": {
"smb-sales": {
"command": "node",
"args": ["/path/to/smb-sales-mcp/dist/main.js"]
}
}
}Restart Claude Desktop. Test it:
"Use smb-sales to handle this objection: the prospect said our price is too high"
Objection in the wild:
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."Reviving a dead deal:
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.)Selling into Germany:
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 platforms (11x, Artisan, Landbase, Alta) needing real training data
Outbound automation tools that want better conversion rates than "just checking in"
CRM AI assistants making intelligent recommendations on live deals
Sales coaching bots requiring proven script frameworks
Lead qualification agents that need structured discovery flows
Founders building sales AI who want expert data without hiring a sales consultant
Most sales content online is theory. This is from the trenches.
Five consecutive years of overshooting quota at a publicly-listed ad-tech company is the kind of repetition that produces working sales frameworks. The scripts here aren't blog-post best practice — they're structured around real B2B enterprise selling experience layered onto general best-practice methodology (BANT, MEDDIC, SPIN, Sandler).
Your AI agent gets that structured layer as API calls.
Disclaimer: This MCP returns structured general-best-practice frameworks. Not a substitute for tailored sales coaching, legal advice, or domain-specific consulting. None of the outputs reproduce any former employer's proprietary methodology.
Most AI SDR tools assume EMEA is one market. It isn't.
Country | What works | What kills deals | Cycle |
🇬🇧 UK | Data, specificity, dry humor | Superlatives, aggressive follow-up | 2–4 wks SMB |
🇮🇪 Ireland | Warm intros, Dublin tech context | Treating it like London | Faster w/ referrals |
🇪🇸 Spain | Trust over time, Spanish for SMBs | Rushing, August launches | 4–8 wks SMB |
🇩🇪 Germany | Documentation, formal address, GDPR | Casual tone, vague claims | 6–12 wks SMB |
🇫🇷 France | French language, intellectual rigor | Generic mass messaging | 4–8 wks SMB |
🇳🇱 Netherlands | Direct, transparent, fast | Overpromising, fluff | Among fastest in EMEA |
🇸🇪 Nordics | Consensus, sustainability framing | Hard sells, after-hours emails | 3–6 wks SMB |
Built from 5+ years of EMEA B2B enterprise sales experience.
Elisabeth Hitz — Swiss-American B2B sales executive based in Barcelona.
10+ years of B2B enterprise sales experience across ad-tech, SaaS, media, and global hiring
Five consecutive years overshooting quota at a publicly-listed ad-tech company
5+ years EMEA B2B enterprise sales (UK, Germany, Spain, France, Ireland, Netherlands)
Closed mid-five to mid-six-figure deals across multiple industries
Now building closermethod.com and sales tools for the AI agent ecosystem
LinkedIn: linkedin.com/in/elisabethhitz
Works with any MCP-compatible client:
Claude Desktop
Cursor
Cline
Windsurf
Custom MCP implementations
If you're building 11x/Artisan/Alta-style products and want extended access for fine-tuning your agent, DM me on LinkedIn. Happy to discuss white-label deals.
MIT. Use it, modify it, ship it.
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. Dates show when Glama detected each change.
v3.0.0get_buying_signalsget_call_scriptget_closing_scriptget_cold_email_templateget_discovery_scriptget_emea_intelligenceget_followup_sequenceget_full_playbookget_objection_responseget_pricing_frameworkEach 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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/closermethod/smb-sales-intelligence-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
