Leadpoet

Get GTM context

getGtmContext

Read-onlyIdempotent

Reads what this workspace knows about how it sells, for one task: guardrails (claims, topics, angles and phrases never to use, companies never to target), offer, proof, voice, ICP, buyers, problems, objections and their saved answers, buying signals, what fit ratings show and saved memories. It is the workspace's context, not a campaign's, whose product and rules can differ: the outreach profile, one published ICP and its Product. Guardrails are listed in full; the rest fits max_chars, with a ref per item. Proof appears only when approved and current. A section with nothing saved is missing, with the screen that adds it; a read this connection can't make is unavailable, never empty.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "task": "<task>"
    },
    "name": "getGtmContext"
  }
}

Input Schema

Name	Required	Description
`task`	Yes	What the context is for: messaging (anything a prospect will read), targeting (ICPs, lead requests, audiences), objections, call_prep or overview.
`focus`	No	Words about the job at hand, such as a prospect's industry, a buyer's role or the objection raised. Items that share them are kept ahead of others.
`icp_id`	No	The ICP to write or plan for. Without it, the primary published ICP is read; when others are published too, guardrails aren't complete until one is named.
`sections`	No	Only these sections. Guardrails are always included.
`max_chars`	No	Character budget for the items other than guardrails, which are always listed in full. Default 6000.
`product_id`	No	The Product to write for, when the ICP keeps its guidance on several connected Products, such as a campaign's product. With one connected Product, it is read without this.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 9, 2026

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), yet the description adds real operational detail: guardrails are always listed in full and exempt from the budget, everything else fits max_chars, proof is only returned when approved and current, and sections with nothing saved are marked missing with a pointer rather than omitted. The 'unavailable, never empty' rule is an unusually valuable disclosure about partial reads that annotations cannot express.

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?

Front-loaded with the purpose, then the content inventory, then the scoping and budget rules in declining order of importance. The second and third sentences are long and clause-heavy, which costs a little readability, but no sentence is filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a six-parameter, no-output-schema read tool, the description covers what comes back (sections, per-item refs, missing vs unavailable sections), how much comes back (budget rules), and the ICP/Product fallback logic. An agent can call it correctly and interpret the response shape without further information.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds genuine meaning on top: max_chars excludes guardrails, sections still always include guardrails, and icp_id falls back to the primary published ICP with the caveat that guardrails are incomplete when multiple ICPs are published. That last point is a behavioral consequence the schema does not convey.

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?

States a specific verb (reads) and a precisely scoped resource (what this workspace knows about how it sells), then enumerates the content: guardrails, offer, proof, voice, ICP, buyers, problems, objections, signals, fit ratings, memories. It also explicitly distinguishes itself from campaign-scoped context ('It is the workspace's context, not a campaign's'), which separates it from siblings like getCampaignMessaging.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 'for one task' framing plus the task enum makes the usage context clear, and the campaign-vs-workspace distinction tells the agent which family of tools to reach for. However, it never names the actual alternatives (getPlaybook, getOutreachProfile, getIcp, listAgentMemories) that overlap with its content, so an agent must infer the routing itself.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Leadpoet tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?