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).

Preview the workspace setup

preview_workspace_setup

Read-onlyIdempotent

When get_workspace reports company_profile_unconfirmed, draft the company profile and setup answers from known business facts and preview them here. Saves nothing: PumpGTM reviews the draft (it may improve or replace unclear audiences and removes the customer's own company as a lookalike customer) and returns the reviewed version, what the reviewer changed and why, and a reviewToken. Show the customer that one summary (company, offer, buyers, audiences, proof they are happy to mention, channels and anything the reviewer changed), then save it with save_workspace_setup only after they confirm. Never invent customers, results, numbers or offers. Without a website it asks for one instead. Only a workspace owner or admin's connection may use it. Returns reviewed, reviewerChanges and reviewToken, or status needs_input with what is missing.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "preview_workspace_setup"
  }
}

Input Schema

Name	Required	Description
`answers`	No	The setup answers you drafted: proof, best customer, warm sources, audiences, signals and channels.
`company`	No	The company profile you drafted from what you know about the business: name, website, offer, buyers, audiences and proof the person confirmed.
`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.

Output Schema

Name	Required	Description
`code`	No	website_required when a website is needed first.
`next`	No	The suggested next call, or null.
`saved`	Yes	Always false: a preview saves nothing.
`status`	No	needs_input when a website is required first.
`nextStep`	No	What to ask the person next.
`reviewed`	No	The reviewed company and answers; save exactly this.
`reviewToken`	No	Pass to save_workspace_setup with the reviewed payload.
`reviewerChanges`	No	What PumpGTM's reviewer changed.
`suggestedWebsite`	No	A website PumpGTM found for the company, to confirm with the person.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 10, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the readOnlyHint/idempotent annotations, it discloses that nothing is saved, that PumpGTM reviews and may improve or replace audiences and strips the customer's own company as a lookalike, what is returned (reviewed, reviewerChanges, reviewToken, or needs_input), and the authorization constraint (owner or admin connection only). This is unusually rich behavioral context for a preview tool.

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?

It is front-loaded with the trigger and the no-save guarantee, and nearly every clause carries operational information. It is dense rather than padded, though the long parenthetical about the reviewer's edits slows scanning slightly.

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 nested, three-parameter tool with an output schema, the description covers trigger, side effects, review semantics, return shape, failure mode (needs_input) and permissions. An agent has everything needed to call it and handle the result correctly.

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?

Schema description coverage is 100%, so the schema already defines answers, company and workspaceId in detail. The description restates a couple of those rules (website fallback, never invent proof points) rather than adding new parameter meaning, so the baseline 3 applies.

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 first sentence names a specific verb pair (draft and preview) and resource (company profile and setup answers), and implicitly contrasts with save_workspace_setup which persists. An agent can distinguish this from the save sibling without opening either schema.

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?

The trigger condition is explicit ('When get_workspace reports company_profile_unconfirmed'), the follow-up path is explicit ('save it with save_workspace_setup only after they confirm'), and an edge case is covered ('Without a website it asks for one instead'). Nothing about when to call this versus saving is left to inference.

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?