PumpGTM

This connector has been deprecated

Duplicate listing. The official PumpGTM connector is https://glama.ai/mcp/connectors/com.pumpgtm/mcp (same server, https://mcp.pumpgtm.com/mcp).

Find people

find_people

Idempotent

Create or revise a Play from targeting and run it. Targeting may include a hiring signal (currentCompanyHiringRolesAny): the person's current company must have an open job posting for one of those roles, posted within currentCompanyHiringPostedWithinDays. It may include a fundraising signal (currentCompanyRaisedWithinDays, optionally currentCompanyRoundTypesAny and currentCompanyMinRaisedUsd): the person's current company must have closed a funding round that recently; such a Play is re-run once a day so newly funded companies keep arriving for review. Without confirmed=true it only saves the Play and returns the targeting summary; then call again with confirmed=true without asking the customer. Company names are resolved automatically and never block: when several companies share a name, an exclusion covers all of them and a required company includes every strong match; pass a website domain in currentCompanyDomainsAny or a LinkedIn company URL in currentCompanyLinkedInUrlsAny to pin one exactly. The result's companyResolution reports each company's outcome (matched, matched_several, unmatched) with the companies chosen, so you can mention it in one line if useful. With confirmed=true, the Play runs discovery and returns candidates in retrieval order. Pass playId alone to rerun an existing ready Play. Optional sequenceId sets the Play's default sequence. Creates no leads and contacts no one.

Input Schema

TableJSON Schema

Name	Required	Description
`playId`	No
`confirmed`	No
`requestId`	Yes	Stable idempotency key; reuse it only to retry this exact request.
`targeting`	No
`sequenceId`	No
`workspaceId`	No	A teammate's workspace you may manage: an active workspace ID from list_team_workspaces. Omit for your own workspace. Supply on every call for a teammate.
`expectedRevision`	No	Required with targeting when revising an existing playId.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 15, 2026

changedInput schema / properties / workspaceId / description

Previous value: -"Team owner only: an active workspace ID from list_team_workspaces. Omit for your own workspace. Supply on every call for a teammate."New value: +"A teammate's workspace you may manage: an active workspace ID from list_team_workspaces. Omit for your own workspace. Supply on every call for a teammate."

Changed3 schema fields changedOct 9, 2026

addedInput schema / properties / targeting / properties / hardFilters / properties / currentCompanyMinRaisedUsd

Added value: +{
+  "description": "Minimum size of the recent round in US dollars. Only meaningful with currentCompanyRaisedWithinDays.",
+  "maximum": 9007199254740991,
+  "minimum": 0,
+  "type": "integer"
+}

addedInput schema / properties / targeting / properties / hardFilters / properties / currentCompanyRaisedWithinDays

Added value: +{
+  "description": "Fundraising signal about the company, not the person: the current company must have closed a funding round within this many days.",
+  "maximum": 365,
+  "minimum": 1,
+  "type": "integer"
+}

addedInput schema / properties / targeting / properties / hardFilters / properties / currentCompanyRoundTypesAny

Added value: +{
+  "default": [],
+  "description": "Alternative round types the recent raise must be, such as Seed, Series A or Series B. Leave empty for any round. Only meaningful with currentCompanyRaisedWithinDays.",
+  "items": {
+    "maxLength": 240,
+    "minLength": 1,
+    "type": "string"
+  },
+  "maxItems": 40,
+  "type": "array"
+}

First observedOct 1, 2026

TDQS

A4.4/5.0

Behavior5/5

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

The description adds substantial behavior beyond the annotations: 'Creates no leads and contacts no one,' that fundraising-signal Plays are re-run once a day, that company-name resolution never blocks and how it behaves with ambiguous names, and that a recovered companyResolution field is returned. These are traits the readOnlyHint/destructiveHint/idempotentHint annotations cannot convey.

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 definition is a single dense paragraph, front-loaded with the core action and then the confirmed/playId flow. Nearly every sentence earns its place, though the signal-resolution detail is packed tightly enough to be hard to scan.

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?

For a complex nested tool with no output schema, the description covers the create/revise/run lifecycle, the confirmation gate, signal semantics, and the key return field (companyResolution). It is nearly complete; only workspace/expectedRevision usage is left entirely to the schema.

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 only 43%, so the description must compensate, and it does for the signal parameters: it explains the hiring signal (open posting for a role, posted within currentCompanyHiringPostedWithinDays), the fundraising signal, and that a domain or LinkedIn URL pins a company exactly. It does not explain requestId, workspaceId, or expectedRevision, but those are covered in the schema.

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 opens with a specific verb and resource: 'Create or revise a Play from targeting and run it,' then elaborates that it runs discovery and returns candidates. It distinguishes itself from siblings like manage_x_play and review_people by describing the create/revise/run flow. However, the name 'find_people' does not obviously map to 'create a Play,' so the agent must reconcile the mismatch.

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

Usage Guidelines5/5

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

Explicit when-to-use guidance: without confirmed=true it only saves the Play and returns the targeting summary, then 'call again with confirmed=true without asking the customer.' It also states 'Pass playId alone to rerun an existing ready Play,' naming the alternative invocation path directly.

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

All PumpGTM 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?