AI 销售代理的意图层 —— 结构化信号解读，而非数据抓取。
基于 10 多年 B2B 企业销售经验构建。
免责声明。 输出内容是基于公开记录的 B2B 销售实践的结构化信号解读框架。不构成投资、财务或法律建议。不能替代人工资格审查。在进行外联之前，请务必通过原始来源核实有关公司、个人或事件的任何具体声明。
当今的每一个 AI SDR 和销售代理都存在同样的结构性差距：他们拥有信号数据（来自 Apollo、Clay、Crunchbase、抓取工具、付费 API），但缺乏一致的解读层。他们知道目标公司聘请了一位销售主管，但不知道如何利用这些信息。
此 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 Scrapers / Crunchbase API 自带数据适配器
Elisabeth Hitz —— 在广告技术、SaaS、媒体和全球招聘领域拥有 10 多年 B2B 企业销售经验。曾在一家上市广告技术公司连续五年超额完成配额。目前正在为 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.
