당신의 AI SDR은 추측하고 있습니다. 제 AI는 계약을 성사시킵니다.
Criteo(할당량 268% 달성), Deel($12B), HBO, Bloomberg, Autodesk, Levi's에서 10년간 엔터프라이즈 거래를 통해 검증된 B2B 영업 플레이북을 AI 에이전트에 제공합니다.
제작: Elisabeth Hitz
AI 에이전트가 영업에 실패하는 이유는 다음과 같습니다:
자격 확인 전 피칭 — 구매 의사가 없는 사람에게 기능만 나열함
이의 제기에 굴복 — "걱정하시는 부분 이해합니다"와 같은 대응(대응이 아닌 항복)
"그냥 확인차 연락드립니다" 식의 후속 조치 — 누구나 아는, 응답률이 거의 0에 가까운 방식
EMEA를 하나의 시장으로 취급 — 5개 이상의 서로 다른 문화권에서 신뢰를 잃음
단일 가격 제시 — 전환율을 높이는 3가지 옵션 메뉴를 제공하지 않음
결과: 리드 소진, 시퀀스 중단, 놓쳐버린 수익.
Related MCP server: shadowprice
블로그 포스트의 이론이 아닌, 수십 년간의 실제 엔터프라이즈 영업 경험을 AI 에이전트가 호출할 수 있는 10가지 도구로 제공합니다. $50K~$500K 규모의 거래에서 검증된 단어 단위 스크립트, 국가별 플레이북, 심리학 기반의 이의 제기 대응법을 포함합니다.
도구 | 기능 |
| 5가지 톤 × 자격 확인 프레임워크. 피칭 전 자격 확인을 통해 클로징 비율을 2배로 높입니다. |
| 가장 흔한 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 설정(~/Library/Application Support/Claude/claude_desktop_config.json, Mac 기준)에 추가하세요:
{
"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에서 $50K~$500K 규모의 거래를 성사시킨 실제 성공 사례입니다.
당신의 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($12B 가치) 할당량 167% 달성
HBO, Bloomberg, Autodesk, Levi's, Rolling Stone, McCann, VML에서 엔터프라이즈 거래 성사
영국, 독일, 스페인, 프랑스, 아일랜드 등 EMEA 지역에서 5년 이상 영업
현재 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.
