Intent-Ebene für KI-Vertriebsagenten — strukturierte Signalinterpretation, kein Data Scraping.
Entwickelt auf Basis von über 10 Jahren Erfahrung im B2B-Enterprise-Vertrieb.
Haftungsausschluss. Die Ergebnisse sind strukturierte Frameworks zur Signalinterpretation, die auf öffentlich dokumentierten B2B-Vertriebspraktiken basieren. Dies stellt keine Anlage-, Finanz- oder Rechtsberatung dar. Es ist kein Ersatz für eine menschliche Qualifizierung. Überprüfen Sie jede spezifische Behauptung über ein Unternehmen, eine Person oder ein Ereignis vor der Kontaktaufnahme mit Primärquellen.
Jeder KI-SDR und Vertriebsagent hat heute die gleiche strukturelle Lücke: Sie verfügen über Signaldaten (von Apollo, Clay, Crunchbase, Scrapern, bezahlten APIs), aber keine konsistente Interpretationsebene. Sie wissen, dass ein Zielunternehmen einen Head of Sales eingestellt hat, aber sie wissen nicht, was sie mit dieser Information anfangen sollen.
Dieses MCP schließt diese Lücke. Stellen Sie eine Signal-Payload bereit — erhalten Sie strukturierte Outreach-Implikationen.
Es führt KEIN Data Scraping durch. Nutzen Sie das Ökosystem von Apify / Clay / Apollo / Crunchbase / LinkedIn für die vorgelagerte Datenerfassung. Dieses MCP ist die Interpretations-Engine.
Related MCP server: Sales Signals MCP Server
Tool | Was es zurückgibt |
| Signalstärke, Outreach-Timing, Pitch-Ansatz, Fallstricke, Entscheidungsfenster für Einstellungsereignisse (neue Führungskraft, Teamerweiterung) |
| Dasselbe für Finanzierungsereignisse (Seed → IPO, Down-Rounds) einschließlich Budgetrahmen und typischer Käufer |
| Dasselbe für Änderungen im Tech-Stack (hinzugefügter/entfernter Wettbewerber, Einführung von Data Warehouses, Compliance-Tools) |
| Dasselbe für Änderungen in der Geschäftsführung (CEO/CFO/CTO/CMO/Gründer-Abgänge) |
| Dasselbe für Marktexpansion (internationales Büro, vertikale Expansion, Produkteinführung) |
| Zusammengesetzter Intent-Score (0-100) bei mehreren Signalen — zur Priorisierung |
// 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 pro Tool-Aufruf
Die ersten 10 Aufrufe pro Actor sind kostenlos
Diese Version 1.0 ist die Interpretationsebene. Zukünftige Versionen:
v1.1: Korrelationsmuster für mehrere Signale (z. B. "head_of_sales + sdr_team_expansion innerhalb von 30 Tagen = Pre-Series-A-Signal")
v1.2: Branchenspezifische Gewichtungen (SaaS vs. Fintech vs. Gesundheitswesen haben unterschiedliche Signal-Halbwertszeiten)
v1.3: Time-Decay-Scoring (das Alter des Signals beeinflusst die Gewichtung)
v2.0: Optionaler "Bring-your-own-data"-Adapter für Clay / Apify Scraper / Crunchbase API
Elisabeth Hitz — über 10 Jahre Erfahrung im B2B-Enterprise-Vertrieb in den Bereichen Ad-Tech, SaaS, Medien und globales Recruiting. Fünf Jahre lang übertraf sie ihre Quoten bei einem börsennotierten Ad-Tech-Unternehmen. Entwickelt jetzt MCP-Server für das KI-Agenten-Ökosystem.
Lizenz: 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.
