Capa de intención para agentes de ventas de IA: interpretación estructurada de señales, no extracción de datos.
Creado a partir de más de 10 años de experiencia en ventas empresariales B2B.
Aviso legal. Los resultados son marcos de interpretación de señales estructurados basados en prácticas de ventas B2B documentadas públicamente. No constituye asesoramiento de inversión, financiero o legal. No sustituye la cualificación humana. Verifique cualquier afirmación específica sobre una empresa, persona o evento con fuentes primarias antes de realizar la prospección.
Cada SDR de IA y agente de ventas actual tiene la misma brecha estructural: tienen datos de señales (de Apollo, Clay, Crunchbase, scrapers, APIs de pago) pero ninguna capa de interpretación consistente. Saben que un objetivo contrató a un Jefe de Ventas, pero no saben qué hacer con esa información.
Este MCP cierra esa brecha. Proporcione una carga útil de señal y reciba implicaciones de prospección estructuradas.
NO extrae datos de fuentes. Utilice el ecosistema de Apify / Clay / Apollo / Crunchbase / LinkedIn para la recopilación inicial. Este MCP es el motor de interpretación.
Related MCP server: Sales Signals MCP Server
Herramienta | Qué devuelve |
| Fuerza de la señal, momento de prospección, ángulo de venta, riesgos, ventana de decisión para eventos de contratación (nuevo ejecutivo, expansión de equipo) |
| Lo mismo para eventos de financiación (semilla → OPI, rondas a la baja), incluyendo bandas presupuestarias y compradores típicos |
| Lo mismo para cambios en la pila tecnológica (competidor añadido/eliminado, adopción de almacén de datos, herramientas de cumplimiento) |
| Lo mismo para cambios en la alta dirección (salidas de CEO/CFO/CTO/CMO/fundadores) |
| Lo mismo para expansión de mercado (oficina internacional, vertical, lanzamiento de producto) |
| Puntuación de intención compuesta (0-100) dadas múltiples señales, para priorización |
// 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 windowPago por evento de Apify: $0.05 por llamada a la herramienta
Primeras 10 llamadas gratuitas por actor
Esta v1.0 es la capa de interpretación. Versiones futuras:
v1.1: Patrones de correlación de señales múltiples (ej. "head_of_sales + sdr_team_expansion en 30 días = señal pre-Serie-A")
v1.2: Ponderaciones específicas por industria (SaaS vs Fintech vs Salud tienen diferentes vidas útiles de señal)
v1.3: Puntuación de decaimiento temporal (la antigüedad de la señal afecta el peso)
v2.0: Adaptador opcional "trae tus propios datos" para Clay / Scrapers de Apify / API de Crunchbase
Elisabeth Hitz — más de 10 años de experiencia en ventas empresariales B2B en ad-tech, SaaS, medios y contratación global. Cinco años superando la cuota en una empresa de ad-tech que cotiza en bolsa. Ahora construyendo servidores MCP para el ecosistema de agentes de IA.
Licencia: 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.
