Skip to main content
Glama
closermethod

B2B Buyer-Signal MCP

interpret_hiring_signal

Analyze B2B hiring signals (exec hires, team expansions) to get signal strength, optimal outreach timing, pitch angle, pitfalls, and decision window for sales engagement.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
signal_typeYes

Implementation Reference

  • Handler for 'interpret_hiring_signal': Looks up the signal_type from HIRING_SIGNALS data and returns the interpretation payload with metadata.
    if (name === "interpret_hiring_signal") {
      const data = HIRING_SIGNALS[(args as any).signal_type];
      if (!data) return { content: [{ type: "text", text: JSON.stringify({ error: "Unknown signal_type. See enum.", _meta: MCP_META }, null, 2) }] };
      return { content: [{ type: "text", text: JSON.stringify({ signal_type: (args as any).signal_type, ...data, _meta: MCP_META }, null, 2) }] };
    }
  • Tool registration with inputSchema for 'interpret_hiring_signal', including the enum of signal types derived from HIRING_SIGNALS keys.
    {
      name: "interpret_hiring_signal",
      description: "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.",
      inputSchema: {
        type: "object",
        properties: { signal_type: { type: "string", enum: Object.keys(HIRING_SIGNALS) } },
        required: ["signal_type"]
      }
  • src/main.ts:321-389 (registration)
    Registration of the 'interpret_hiring_signal' tool via ListToolsRequestSchema handler on the MCP server instance.
    server.setRequestHandler(ListToolsRequestSchema, async () => ({
      tools: [
        {
          name: "interpret_hiring_signal",
          description: "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.",
          inputSchema: {
            type: "object",
            properties: { signal_type: { type: "string", enum: Object.keys(HIRING_SIGNALS) } },
            required: ["signal_type"]
          }
        },
        {
          name: "interpret_funding_signal",
          description: "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.",
          inputSchema: {
            type: "object",
            properties: { funding_stage: { type: "string", enum: Object.keys(FUNDING_SIGNALS) } },
            required: ["funding_stage"]
          }
        },
        {
          name: "interpret_tech_stack_change",
          description: "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.",
          inputSchema: {
            type: "object",
            properties: { change_type: { type: "string", enum: Object.keys(TECH_STACK_SIGNALS) } },
            required: ["change_type"]
          }
        },
        {
          name: "interpret_leadership_change",
          description: "Interpret a leadership-change signal. Returns interpretation, outreach timing, pitch angle. Types: ceo_change, cfo_change, cto_change, cmo_change, founder_departure.",
          inputSchema: {
            type: "object",
            properties: { change_type: { type: "string", enum: Object.keys(LEADERSHIP_SIGNALS) } },
            required: ["change_type"]
          }
        },
        {
          name: "interpret_expansion_signal",
          description: "Interpret a market expansion signal (new geo, vertical, product). Returns implications and outreach playbook. Types: international_office_opening, vertical_expansion, product_launch.",
          inputSchema: {
            type: "object",
            properties: { expansion_type: { type: "string", enum: Object.keys(EXPANSION_SIGNALS) } },
            required: ["expansion_type"]
          }
        },
        {
          name: "score_buyer_intent",
          description: "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.",
          inputSchema: {
            type: "object",
            properties: {
              signals: {
                type: "array",
                items: { type: "string", enum: Object.keys(SIGNAL_WEIGHTS) },
                description: "Array of signal keys observed for this account"
              }
            },
            required: ["signals"]
          }
        },
        {
          name: "get_full_pack",
          description: "Returns the complete signal-interpretation library + metadata. Useful for fine-tuning or full agent context.",
          inputSchema: { type: "object", properties: {} }
        }
      ]
    }));
  • The HIRING_SIGNALS data dictionary containing all hiring signal interpretations by signal_type key (head_of_sales, head_of_revenue, vp_marketing, sdr_team_expansion, head_of_data, head_of_security).
    const HIRING_SIGNALS: Record<string, any> = {
      "head_of_sales": {
        signal_strength: "Very High",
        interpretation: "Company is scaling revenue function — expect new tooling decisions in next 60-90 days. NEW Head of Sales typically reviews/replaces 30-50% of existing tech stack within first 90 days.",
        outreach_timing: "First contact: week 2-4 of new exec's tenure (post-onboarding, pre-decision)",
        pitch_angle: "Reference their previous-company tech stack (LinkedIn check) — anchor on what worked there",
        common_pitfalls: ["Reaching out week 1 (too early — no authority yet)", "Reaching out month 6+ (decisions already made)", "Generic 'congrats on the new role' opener — read as low-effort"],
        related_signals_to_correlate: ["recent SDR/AE hiring posts", "marketing leadership changes", "funding events", "geo expansion"],
        average_decision_window: "60-120 days from new exec start date"
      },
      "head_of_revenue": {
        signal_strength: "Very High",
        interpretation: "RevOps + Sales + Marketing + CS unification signal. Expect cross-functional tooling decisions and consolidation pressure on point solutions.",
        outreach_timing: "Week 3-5 of tenure",
        pitch_angle: "Lead with consolidation/integration story over best-of-breed pitch",
        common_pitfalls: ["Pitching point solution without integration narrative", "Ignoring CS/RevOps stakeholder mention"],
        related_signals_to_correlate: ["RevOps role hiring", "tech stack consolidation announcements"],
        average_decision_window: "90-180 days"
      },
      "vp_marketing": {
        signal_strength: "High",
        interpretation: "Marketing tech reset incoming. Expect MAP/CRM/content tool reviews. New VP-Marketing replaces ~20-40% of marketing stack in first 6 months.",
        outreach_timing: "Week 2-6",
        pitch_angle: "Performance attribution + pipeline contribution metrics from peer companies",
        common_pitfalls: ["Pitching tools they already use at previous company (research first)", "Generic ROI claims without industry-specific benchmarks"],
        related_signals_to_correlate: ["MAP migration mentions", "content marketing hiring surges", "demand gen role openings"],
        average_decision_window: "60-150 days"
      },
      "sdr_team_expansion": {
        signal_strength: "High",
        interpretation: "Multiple SDR/BDR job posts in 30 days = aggressive outbound investment. Tooling decisions imminent (sales engagement, intent data, AI SDR layers).",
        outreach_timing: "Now — when the team is small enough to influence tooling",
        pitch_angle: "Per-rep ROI math, ramp-time comparisons, AI augmentation angle",
        common_pitfalls: ["Selling to the AE manager when SDR manager owns the decision", "Ignoring SDR ops / RevOps gatekeeper"],
        related_signals_to_correlate: ["SDR ops roles", "AE hiring", "outbound platform job mentions in JDs"],
        average_decision_window: "30-90 days"
      },
      "head_of_data": {
        signal_strength: "Medium-High",
        interpretation: "Data infrastructure investment signal. Expect ETL/reverse-ETL/warehouse tool decisions. AI/ML capabilities likely on roadmap.",
        outreach_timing: "Week 4-8",
        pitch_angle: "Data observability + lineage; AI/ML readiness; warehouse-native architecture",
        common_pitfalls: ["Pitching point analytics tools without data platform narrative"],
        related_signals_to_correlate: ["Data engineer hiring", "ML engineer hiring", "warehouse migration mentions"],
        average_decision_window: "90-240 days"
      },
      "head_of_security": {
        signal_strength: "High",
        interpretation: "Security maturity signal. SOC2/ISO27001/HIPAA-ready. Expect security tooling consolidation, IAM/SIEM/CSPM/cloud security decisions.",
        outreach_timing: "Week 2-6 (often shorter window — security roles move fast)",
        pitch_angle: "Compliance-readiness, audit support, integration with their current SIEM/IAM",
        common_pitfalls: ["Generic 'we're SOC2 compliant' boast — they will ask deep questions", "Ignoring IT/RevOps/Engineering stakeholders"],
        related_signals_to_correlate: ["compliance announcements", "incident disclosures", "fundraise (security investment usually scales with funding)"],
        average_decision_window: "30-120 days (security has faster decision cycle than other functions)"
      }
    };
Behavior2/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/closermethod/buyer-signal-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server