Skip to main content
Glama
closermethod

B2B Buyer-Signal MCP

interpret_leadership_change

Interpret a leadership change type (e.g., CEO or CTO change) to determine optimal outreach timing and pitch angle for B2B sales.

Instructions

Interpret a leadership-change signal. Returns interpretation, outreach timing, pitch angle. Types: ceo_change, cfo_change, cto_change, cmo_change, founder_departure.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
change_typeYes

Implementation Reference

  • src/main.ts:350-358 (registration)
    Tool registration in the ListToolsRequestSchema handler. The tool 'interpret_leadership_change' is defined with a description and inputSchema that expects a 'change_type' parameter (enum: ceo_change, cfo_change, cto_change, cmo_change, founder_departure).
    {
      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"]
      }
    },
  • Handler logic in the CallToolRequestSchema handler. Looks up the change_type in the LEADERSHIP_SIGNALS data structure and returns the interpretation as JSON. If unknown, returns an error.
    if (name === "interpret_leadership_change") {
      const data = LEADERSHIP_SIGNALS[(args as any).change_type];
      if (!data) return { content: [{ type: "text", text: JSON.stringify({ error: "Unknown change_type. See enum.", _meta: MCP_META }, null, 2) }] };
      return { content: [{ type: "text", text: JSON.stringify({ change_type: (args as any).change_type, ...data, _meta: MCP_META }, null, 2) }] };
    }
  • Input schema for the tool: expects an object with 'change_type' (string, enum of the five leadership signal types).
    inputSchema: {
      type: "object",
      properties: { change_type: { type: "string", enum: Object.keys(LEADERSHIP_SIGNALS) } },
      required: ["change_type"]
  • The LEADERSHIP_SIGNALS data dictionary containing all leadership change interpretations for ceo_change, cfo_change, cto_change, cmo_change, and founder_departure.
    const LEADERSHIP_SIGNALS: Record<string, any> = {
      "ceo_change": {
        signal_strength: "Very High",
        interpretation: "Company-wide reset. Strategy review imminent. All major spend will be reviewed. New CEO typically replaces/reviews 30-60% of tooling within first 12 months.",
        outreach_timing: "Week 4-8 of new CEO tenure",
        pitch_angle: "Strategic alignment with new CEO's prior-company stack and priorities",
        common_pitfalls: ["Reaching out in week 1 (too early)", "Not researching CEO's prior company tech preferences"],
        average_decision_window: "120-360 days"
      },
      "cfo_change": {
        signal_strength: "High",
        interpretation: "Cost discipline + audit pressure incoming. Stack rationalization. Renewal scrutiny.",
        outreach_timing: "Week 6-10 of new CFO tenure",
        pitch_angle: "ROI/payback period math, consolidation savings, audit-readiness",
        common_pitfalls: ["Generic ROI claims without specific peer benchmarks"],
        average_decision_window: "60-180 days"
      },
      "cto_change": {
        signal_strength: "High",
        interpretation: "Technical stack reset. Architecture review. Often replaces 20-40% of dev tools in first 9 months.",
        outreach_timing: "Week 4-12",
        pitch_angle: "Architecture compatibility with their prior-company stack",
        common_pitfalls: ["Pitching tools they already adopted at previous company without checking", "Not respecting build-vs-buy lens"],
        average_decision_window: "90-240 days"
      },
      "cmo_change": {
        signal_strength: "Medium-High",
        interpretation: "Marketing reset. MAP / content / attribution decisions in 90 days. Brand work likely.",
        outreach_timing: "Week 3-8",
        pitch_angle: "Performance attribution, pipeline contribution, peer-CMO playbook references",
        common_pitfalls: ["Ignoring demand-gen vs brand-marketing distinction"],
        average_decision_window: "60-180 days"
      },
      "founder_departure": {
        signal_strength: "High (negative or positive)",
        interpretation: "Major culture/strategy signal. If founder out = professionalization signal. If founder back as CEO = reset signal. Either way, expect tooling review.",
        outreach_timing: "Week 4-8 (let dust settle)",
        pitch_angle: "Tailor based on direction — professionalization (mature tooling) or reset (lean tooling)",
        common_pitfalls: ["Not reading the post-departure narrative carefully"],
        average_decision_window: "120-360 days"
      }
    };
Behavior2/5

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.

Conciseness4/5

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.

Completeness3/5

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.

Parameters2/5

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.

Purpose4/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 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.

Usage Guidelines3/5

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.

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