Skip to main content
Glama
Sign In

PumpGTM

by com.pumpgtm.mcp
OverviewDiscussionsAdmin
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).

Write a cold email or message

write_cold_email
Read-onlyIdempotent

Write or improve a cold email, LinkedIn message or X DM. Returns PumpGTM's writing rules, its three-follow-up plan, the LinkedIn connection-note rule and a few proven examples from its library of the most-liked public posts about cold messages. Write the message from them in the customer's voice, using what you know about their company and the prospect, and show it to the customer. Free and read-only: it sends and saves nothing, and save_sequence_draft turns approved copy into a sequence. Credit example authors and never copy them word for word.

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": "write_cold_email"
  }
}

Input Schema

NameRequiredDescriptionDefault
examplesNoHow many library examples to include; 0 returns only the rules.
workspaceIdNoA 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

NameRequiredDescriptionDefault
nextYesWhat to do next: write the message and show it to the customer.
rulesYesPumpGTM's writing rules to follow.
examplesYesRandom examples from the library.
examplesUnavailableNotrue when the library could not be read; write from the rules alone.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / examples / description
      Previous value: -"How many library examples to include."New value: +"How many library examples to include; 0 returns only the rules."
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "additionalProperties": {},
+  "properties": {
+    "examples": {
+      "description": "Random examples from the library.",
+      "items": {
+        "additionalProperties": {},
+        "properties": {
+          "author": {
+            "description": "Who wrote the post; credit them."
+          },
+          "likes": {
+            "description": "How many likes the post had."
+          },
+          "text": {
+            "description": "The example's text; learn from it, never copy it."
+          },
+          "url": {
+            "description": "Link to the original post."
+          },
+          "why": {
+            "description": "Why it was kept in the library."
+          }
+        },
+        "required": [
+          "author",
+          "url",
+          "text"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "examplesUnavailable": {
+      "description": "true when the library could not be read; write from the rules alone.",
+      "type": "boolean"
+    },
+    "next": {
+      "description": "What to do next: write the message and show it to the customer.",
+      "type": "string"
+    },
+    "rules": {
+      "additionalProperties": {},
+      "description": "PumpGTM's writing rules to follow.",
+      "properties": {
+        "connectionNote": {
+          "description": "The rule for LinkedIn connection notes (send none).",
+          "type": "string"
+        },
+        "followUps": {
+          "description": "The three-follow-up plan for every new sequence.",
+          "type": "string"
+        },
+        "style": {
+          "description": "How the message should read.",
+          "type": "string"
+        }
+      },
+      "required": [
+        "style",
+        "followUps",
+        "connectionNote"
+      ],
+      "type": "object"
+    }
+  },
+  "required": [
+    "rules",
+    "examples",
+    "next"
+  ],
+  "type": "object"
+}
  2. Added

TDQS

A4.1/5.0
Behavior4/5

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

The annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false and idempotentHint=true, and the description correctly reinforces that nothing is sent or saved. Beyond that, it discloses policies the annotations cannot: writing in the customer's voice, crediting example authors, and never copying examples verbatim. It does not describe size or latency of the returned rule set, but the behavioral picture is solid.

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 purpose and the return contents are front-loaded, and the read-only/next-step note follows in a sensible order. The final sentence packs voice, review, crediting and anti-copying rules into one long clause, which is dense but each element is actionable rather than filler.

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?

An output schema exists, yet the description still usefully characterizes the shape of the returned guidance, which helps an agent choose this tool over example-only siblings. Safety, voice, attribution and the handoff to save_sequence_draft are all covered. The only gap is the teammate-workspace (`workspaceId`) scenario, which 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.

Parameters3/5

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

Schema description coverage is 100%, so both `examples` and `workspaceId` are already documented in the schema, including the 0–10 range and the 'omit for your own workspace' semantics. The description only alludes to examples generically ('a few proven examples') and says nothing about the teammate-workspace case, so it adds no meaning beyond the schema — baseline 3.

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 opens with a specific verb and resource: 'Write or improve a cold email, LinkedIn message or X DM.' It also spells out what is returned (writing rules, three-follow-up plan, connection-note rule, library examples), which distinguishes it from the sibling get_cold_message_examples that only returns examples.

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?

It gives a clear operating instruction ('Write the message from them in the customer's voice ... and show it to the customer') and routes the next step explicitly to save_sequence_draft for approved copy. It lacks an explicit inverse condition such as when to prefer get_cold_message_examples or how to proceed without a known company/prospect, so it stops short of full when/when-not coverage.

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

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