AI 영업 에이전트를 위한 의도 계층 — 데이터 스크래핑이 아닌 구조화된 신호 해석.
10년 이상의 B2B 엔터프라이즈 영업 경험을 바탕으로 구축되었습니다.
면책 조항. 출력물은 공개적으로 문서화된 B2B 영업 관행에 기반한 구조화된 신호 해석 프레임워크입니다. 투자, 재무 또는 법률 자문이 아닙니다. 인간의 자격 검증을 대체할 수 없습니다. 아웃리치 전에 기업, 개인 또는 이벤트에 대한 특정 주장을 1차 출처를 통해 확인하십시오.
오늘날 모든 AI SDR 및 영업 에이전트는 동일한 구조적 격차를 가지고 있습니다. 즉, 신호 데이터(Apollo, Clay, Crunchbase, 스크래퍼, 유료 API 등)는 가지고 있지만 일관된 해석 계층이 없습니다. 타겟 기업이 영업 총괄(Head of Sales)을 채용한 사실은 알지만, 그 정보를 어떻게 활용해야 할지는 모릅니다.
이 MCP는 그 간극을 메워줍니다. 신호 페이로드를 제공하면 구조화된 아웃리치 시사점을 받을 수 있습니다.
데이터 소스를 직접 스크래핑하지 않습니다. 업스트림 수집을 위해서는 Apify / Clay / Apollo / Crunchbase / LinkedIn 생태계를 사용하십시오. 이 MCP는 해석 엔진입니다.
Related MCP server: Sales Signals MCP Server
도구 | 반환 내용 |
| 채용 이벤트(신규 임원, 팀 확장)에 대한 신호 강도, 아웃리치 타이밍, 피치 각도, 주의사항, 의사결정 기간 |
| 투자 이벤트(시드 → IPO, 다운 라운드)에 대한 동일 정보(예산 범위 및 일반적인 구매자 포함) |
| 기술 스택 변경(경쟁사 추가/제거, 데이터 웨어하우스 도입, 규정 준수 도구 등)에 대한 동일 정보 |
| C-레벨 변경(CEO/CFO/CTO/CMO/창업자 퇴사)에 대한 동일 정보 |
| 시장 확장(해외 지사, 수직적 확장, 제품 출시)에 대한 동일 정보 |
| 여러 신호를 고려한 복합 의도 점수(0-100) — 우선순위 지정용 |
// AI agent observes: "Acme just hired a new Head of Sales last week + announced Series B"
// Calls:
mcp.call("interpret_hiring_signal", { signal_type: "head_of_sales" });
mcp.call("interpret_funding_signal", { funding_stage: "series_b" });
mcp.call("score_buyer_intent", { signals: ["head_of_sales", "series_b"] });
// Returns: tier, recommended action, pitch angle, decision windowApify 이벤트당 결제: 도구 호출당 $0.05
액터당 처음 10회 호출 무료
이번 v1.0은 해석 계층입니다. 향후 버전:
v1.1: 다중 신호 상관관계 패턴 (예: "30일 이내 head_of_sales + sdr_team_expansion = 시리즈 A 이전 신호")
v1.2: 산업별 가중치 (SaaS, 핀테크, 헬스케어는 신호 유효 기간이 다름)
v1.3: 시간 감쇠 점수 (신호의 오래된 정도가 가중치에 영향을 미침)
v2.0: Clay / Apify 스크래퍼 / Crunchbase API를 위한 선택적 데이터 연동 어댑터
Elisabeth Hitz — 광고 기술, SaaS, 미디어 및 글로벌 채용 분야에서 10년 이상의 B2B 엔터프라이즈 영업 경험 보유. 상장된 광고 기술 기업에서 5년간 할당량을 초과 달성함. 현재 AI 에이전트 생태계를 위한 MCP 서버를 구축 중.
라이선스: MIT
Returns the complete signal-interpretation library + metadata. Useful for fine-tuning or full agent context.
| 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 what is returned, not behavioral aspects like read-only nature, size, or performance 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?
Two concise sentences, front-loaded with purpose, no unnecessary 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?
With no parameters and no output schema, the description is adequate for the tool's simplicity, though it could elaborate on what 'library + metadata' includes.
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 zero parameters and 100% coverage, so the description adds no further parameter info. Baseline of 4 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 it returns the complete signal-interpretation library and metadata, distinguishing it from sibling tools that interpret individual signals.
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?
It explicitly mentions use cases (fine-tuning or full agent context) but does not contrast with specific siblings or state 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.
Interpret a market expansion signal (new geo, vertical, product). Returns implications and outreach playbook. Types: international_office_opening, vertical_expansion, product_launch.
| Name | Required | Description | Default |
|---|---|---|---|
| expansion_type | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It mentions returning 'implications and outreach playbook' but does not clarify side effects, required permissions, or whether the operation is read-only. The lack of detail beyond the return type leaves the agent uncertain about invocation 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 concise with two sentences, front-loading the purpose and listing inputs. No redundant information; every sentence serves a clear function.
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 simple schema (one enum parameter) and no output schema, the description should fully explain the tool's behavior and output format. However, it vaguely mentions 'implications and outreach playbook' without detailing the structure or format of the return value, leaving the agent without complete context.
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?
With 0% schema description coverage, the description should compensate by explaining the parameter. It only repeats the enum values already in the schema without adding meaning (e.g., definitions of each expansion type). The parameter name 'expansion_type' is self-explanatory, but the description adds minimal semantic value 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's function: interpreting a market expansion signal and returning implications and an outreach playbook. It lists the three specific types, making it distinct from sibling tools like interpret_funding_signal or interpret_hiring_signal, which handle different signal categories.
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 for expansion signals (international office opening, vertical expansion, product launch) but does not explicitly state when to use this tool over alternatives, nor does it provide exclusions or prerequisites. While the sibling list offers context, the description lacks direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Interpret a funding-event signal. Returns interpretation, budget band, typical buyers, outreach timing, pitfalls. Stages: seed, series_a, series_b, series_c_plus, ipo_recent, down_round.
| Name | Required | Description | Default |
|---|---|---|---|
| funding_stage | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavior. It states the tool 'returns' data, implying a read-only operation, but does not mention safety, permissions, or side effects. The list of outputs gives some transparency, but lacks explicit assurance of no mutation.
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?
Two-sentence description that front-loads the main purpose, then lists outputs and valid stages. No redundant words; each sentence adds value.
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 parameter and no output schema, the description covers the input options and key outputs. It could be slightly enhanced by mentioning the structure of the returned object, but remains adequate.
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 has 0% coverage (no descriptions), but the tool description lists all enum values for the single parameter and explains how they map to funding stages. This adds meaningful context beyond the raw enum.
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 verb 'interpret' and resource 'funding-event signal', lists specific return values, and is distinct from sibling tools which interpret different signals (expansion, hiring, etc.). No ambiguity.
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 explicit guidance on when to use this tool versus siblings or when not to use it. The description only states the tool's purpose without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Interpret a hiring signal (new exec hire, team expansion, role posting). Returns signal strength, outreach timing, pitch angle, common pitfalls, average decision window. Provide signal_type from: head_of_sales, head_of_revenue, head_of_security, vp_marketing, sdr_team_expansion, head_of_data.
| Name | Required | Description | Default |
|---|---|---|---|
| signal_type | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It states the tool returns analysis fields but does not reveal whether it is read-only, requires authentication, or has side effects. The behavioral profile is opaque beyond the listed outputs.
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 two sentences, front-loaded with the action, and contains no superfluous content. Every word adds value.
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 simplicity of the tool (one parameter, no output schema), the description adequately covers the input and output. It lacks some behavioral context and usage guidelines, but is otherwise complete for a straightforward interpretation tool.
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 only parameter, signal_type, has an enum defined in the schema. The description repeats the enum values but does not explain what each signal type means or how they differ. With 0% schema description coverage, the description adds marginal value—it lists values but lacks semantic explanation.
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 interprets a hiring signal, lists the return fields (signal strength, outreach timing, etc.), and specifies the input enum values. This distinguishes it from sibling tools like interpret_expansion_signal or interpret_funding_signal.
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 tells the agent to provide a signal_type from a list, but does not give explicit guidance on when to use this tool versus alternative interpretation tools (e.g., interpret_leadership_change). Usage context is implied by the signal type names, but no when-not or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Interpret a leadership-change signal. Returns interpretation, outreach timing, pitch angle. Types: ceo_change, cfo_change, cto_change, cmo_change, founder_departure.
| Name | Required | Description | Default |
|---|---|---|---|
| change_type | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It mentions that the tool returns interpretation, outreach timing, and pitch angle, but does not explain side effects, authentication needs, rate limits, or prerequisites. The lack of output schema and minimal behavioral context makes this score appropriate.
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 short (two sentences) with no fluff. It front-loads the action and return values, then lists types. However, listing the types that are already in the schema is somewhat redundant. Overall efficient but could be slightly more concise.
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 single-parameter tool without an output schema, the description covers the return fields (interpretation, outreach timing, pitch angle) but lacks details on output format, prerequisites, or when to use specific change types. It provides minimally acceptable completeness.
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 one parameter 'change_type' with an enum. The description lists the enum values again but does not add new meaning beyond the schema, such as explaining when each type is appropriate. With 0% schema description coverage, the description fails to compensate; it mostly repeats what the schema already provides.
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 interprets a leadership-change signal and returns interpretation, outreach timing, and pitch angle. It lists the five types of leadership changes, making the purpose specific and distinguishable from sibling tools that handle other signals like expansion or funding.
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 use when a leadership-change signal is detected, but does not explicitly state when not to use it or provide alternatives. The sibling tools are thematically similar, and no comparative guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Interpret a tech-stack change signal. Returns interpretation, outreach timing, pitch angle, decision window. Types: added_competitor, removed_competitor, added_warehouse, added_compliance_tool, removed_legacy_crm.
| Name | Required | Description | Default |
|---|---|---|---|
| change_type | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description states what it returns (interpretation, timing, pitch angle, decision window) but gives no details on side effects, authorization, or error behavior. Minimal transparency for a read-only interpretation tool.
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?
Two sentences, front-loaded with verb, resource, and return summary. Efficient but could be more structured (e.g., separate sections for return and types).
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 adequately conveys purpose and valid inputs. Agent can infer behavior from types and return list.
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 coverage is 0% but description lists enum values. However, it does not explain the semantic meaning of each change type (e.g., what 'added_competitor' implies). Adds some value over schema but insufficient for full understanding.
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 uses a specific verb 'interpret' and resource 'tech-stack change signal' and lists return values and valid types, clearly differentiating from sibling tools like 'interpret_expansion_signal'.
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 vs alternatives. Sibling tools are listed but description does not mention contexts 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.
Given a list of signals observed for a target account, return a composite intent score (0-100) and recommended outreach action. Use this to prioritize an account list.
| Name | Required | Description | Default |
|---|---|---|---|
| signals | Yes | Array of signal keys observed for this account |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose behavioral traits such as whether the tool is read-only, side effects, error handling for empty inputs, or any rate limits. The description is purely functional.
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 very concise at two sentences with no wasted words. It front-loads the purpose and usage.
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 simplicity (one parameter, no output schema), the description covers the essential information: input, output, and purpose. However, it could add more detail on the output format or scenarios like empty signals.
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 coverage is 100% with a clear parameter description. The tool description does not add additional meaning beyond what the schema provides; it only restates the general purpose.
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 takes a list of signals and returns a composite intent score (0-100) and recommended outreach action. It distinguishes from siblings like interpret_expansion_signal by being a composite aggregator for prioritization.
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 explicitly says to use it to prioritize an account list, which provides usage context. However, it doesn't explicitly state when not to use it or mention the alternative interpret tools for single signals.
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.
v1.0.0get_full_packinterpret_expansion_signalinterpret_funding_signalinterpret_hiring_signalinterpret_leadership_changeinterpret_tech_stack_changescore_buyer_intentScored across 7 tools
Each tool targets a distinct signal type (funding, hiring, expansion, leadership, tech stack) plus a composite scoring tool and a full pack retrieval. No overlap in purposes.
Five tools follow the consistent 'interpret_<signal_type>' pattern, but 'get_full_pack' and 'score_buyer_intent' break the pattern with different verbs, causing minor inconsistency.
Seven tools is well-scoped for interpreting key B2B buyer signals and scoring intent. Not overly numerous nor sparse.
Covers major signal types and includes aggregation via scoring. Minor gap: lacks coverage for signals like partnership or regulatory changes, but core workflows are complete.
Signal-based B2B prospecting: find leads with buying intent, run email and LinkedIn outreach.
Sales research and prep tools for B2B reps. Prospect briefs, angles, citations.
Cold engine for B2B founders. Detects buying signals, drafts outreach, books qualified meetings.
Real-time B2B buying signals on your target accounts: funding, hiring, leadership, tech stack.
