Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@B2B Buyer-Signal MCP Interpret hiring signal: new Head of Sales at Acme"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Intent layer for AI sales agents — structured signal interpretation, not data scraping.
Built from 10+ years of B2B enterprise sales experience.
Disclaimer. Outputs are structured signal-interpretation frameworks based on publicly-documented B2B sales practice. Not investment, financial, or legal advice. Not a substitute for human qualification. Verify any specific claim about a company, person, or event with primary sources before outreach.
Every AI SDR and sales agent today has the same structural gap: they have signal data (from Apollo, Clay, Crunchbase, scrapers, paid APIs) but no consistent interpretation layer. They know a target hired a Head of Sales, but they don't know what to do with that information.
This MCP bridges that gap. Provide a signal payload — receive structured outreach implications.
It does NOT scrape data sources. Use Apify / Clay / Apollo / Crunchbase / LinkedIn ecosystem for upstream collection. This MCP is the interpretation engine.
Related MCP server: Sales Signals MCP Server
Tool | What it returns |
| Signal strength, outreach timing, pitch angle, pitfalls, decision window for hiring events (new exec, team expansion) |
| Same for funding events (seed → IPO, down rounds) including budget bands and typical buyers |
| Same for tech-stack changes (added/removed competitor, warehouse adoption, compliance tooling) |
| Same for C-suite changes (CEO/CFO/CTO/CMO/founder departures) |
| Same for market expansion (international office, vertical, product launch) |
| Composite intent score (0-100) given multiple signals — for prioritization |
// 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 Pay-Per-Event: $0.05 per tool call
First 10 calls free per actor
This v1.0 is the interpretation layer. Future versions:
v1.1: Multi-signal correlation patterns (e.g., "head_of_sales + sdr_team_expansion within 30 days = pre-Series-A signal")
v1.2: Industry-specific weightings (SaaS vs Fintech vs Healthcare have different signal half-lives)
v1.3: Time-decay scoring (signal age affects weight)
v2.0: Optional bring-your-own-data adapter for Clay / Apify Scrapers / Crunchbase API
Elisabeth Hitz — 10+ years of B2B enterprise sales experience across ad-tech, SaaS, media, and global hiring. Five-year stretch overshooting quota at a publicly-listed ad-tech company. Now building MCP servers for the AI agent ecosystem.
License: 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.
