What can you do with this server?

This server lets AI agents integrate Pitch Machine via MCP to create and manage hyper-personalized pitch microsites. * Create a receiver (pitchmachine_create_receiver): Add a B2B or B2C prospect/contact with required details; returns a receiver_id. * Generate a pitch (pitchmachine_generate_pitch): Initiate microsite generation for a receiver, poll until deployment, and return a public share URL. On timeout, returns an in-progress status and a pitch_id. * Fetch a pitch URL (pitchmachine_get_pitch_url): Retrieve the current status and public share URL for any pitch by ID, useful for resuming timed-out generations or re-sharing. * List pitches (pitchmachine_list_pitches): List recent pitches with optional filters (status, since timestamp, limit) for auditing or discovering pitch IDs. * No send tool: The server deliberately does not send emails/messages; it returns shareable URLs for the agent or user to distribute through their own channels. * Security/integration: Supports long-lived agent tokens or a cookie-based compatibility path; works with MCP hosts like Claude Desktop, Cursor, Grok Bot, and others.

How do I use pitchmachine-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@pitchmachine-mcp Create a personalized pitch microsite for the new lead and share the URL." That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

pitchmachine-mcp

by rcabanes-ops

Overview Schema Related Servers Score Discussions

TypeScript

Local

`@pitchmachine/mcp-server`

Model Context Protocol server for Pitch Machine. Build hyper-personalized pitch microsites from any AI agent — Claude Desktop, Cursor, Grok Bot, Continue, or any other MCP host.

The agent creates the receiver, generates the microsite, and hands you back a public URL. Sending is deliberately left to you (or to the agent, via its own channels) — Pitch Machine gets out of the way after the artifact is ready.

Status

v0.2.2 — the friendly-install release.

Package name is @pitchmachine/mcp-server (the earlier @pitchmachine/mcp name was retired after an unpublish incident placed it under npm's 24-hour name-reserve hold; see CHANGELOG.md). Both pitchmachine-mcp and pitchmachine-mcp-server binaries are shipped, so any older config snippets continue to work.

Auth is now a long-lived agent token you mint inside the app at Settings → Agent access. Copy once, paste into your MCP host config, done. Cookie forwarding from v0.1.x still works as a compatibility path but is no longer the recommended flow. See Roadmap for what's next.

If you were on v0.1.0: don't use it. It called the wrong receiver endpoint and sent the wrong auth header, and every first tool call would have failed. Fixed in v0.1.1; details in CHANGELOG.

Related MCP server: speed-to-lead-agent

What you get

Four tools:

Tool	What it does
`pitchmachine_create_receiver`	Adds a receiver (a company + one contact human). Same shape as the production form; `company_name` is the only required field. Set `audience_mode: "b2c"` and fill the B2C-only strings for personal-book receivers.
`pitchmachine_generate_pitch`	Kicks off generation and polls until the microsite is deployed.
`pitchmachine_get_pitch_url`	Fetches the public share URL for any pitch, past or in-progress.
`pitchmachine_list_pitches`	Lists recent pitches with status and URL.

No send tool. On purpose. See the /agents page for the reasoning; short version: platform email deliverability is still on its warmup arc, and we'd rather hand you an artifact than a low-deliverability outbox.

Install & configure — recommended flow (v0.2.0+)

1. Mint an agent token

Sign in at pitchmachine.ai.
Go to Settings → Agent access.
Click Mint token, name it after where it'll live (e.g. Claude on my laptop), optionally set an expiry.
Copy the plaintext token. It's shown exactly once. Format: pm_agent_live_<24 base62 chars>.

Treat the token like a password. It's tied to your pitcher, not a device; revoke and re-mint from Settings if it ever leaks.

2. Point your MCP host at `@pitchmachine/mcp-server`

Claude Desktop

~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):

{
  "mcpServers": {
    "pitchmachine": {
      "command": "npx",
      "args": ["-y", "@pitchmachine/mcp-server"],
      "env": {
        "PITCHMACHINE_API_TOKEN": "pm_agent_live_replace_with_your_token"
      }
    }
  }
}

Restart Claude Desktop. The four tools appear in the tools panel.

The Copy for Claude Desktop button in Settings → Agent access hands you this exact JSON block with the token already filled in.

Cursor

.cursor/mcp.json at your repo root (or the global equivalent):

{
  "mcpServers": {
    "pitchmachine": {
      "command": "npx",
      "args": ["-y", "@pitchmachine/mcp-server"],
      "env": {
        "PITCHMACHINE_API_TOKEN": "pm_agent_live_replace_with_your_token"
      }
    }
  }
}

Grok Bot / any other MCP host

The stdio command is the same. Point your host at npx -y @pitchmachine/mcp-server with PITCHMACHINE_API_TOKEN in the environment.

3. Verify with the smoke script

Before trusting the install in an agent workflow, run the live smoke test:

export PITCHMACHINE_API_TOKEN="pm_agent_live_replace_with_your_token"
git clone https://github.com/rcabanes-ops/pitchmachine-mcp
cd pitchmachine-mcp && npm install && npm run build && npm run smoke

This lists your recent pitches over the real API. If it prints an array, your token is good and the endpoint path is right. If it prints 401 unauthorized, the token was revoked or never existed.

Still supported. Use this if you're on a Pitch Machine build that predates Settings → Agent access, or if you want a one-off check without minting a token. The cookie is valid for 14 days; re-copy after that.

Sign in at pitchmachine.ai.
Open DevTools (F12 or Cmd+Opt+I).
Application tab → Cookies → https://pitchmachine.ai. (Firefox: Storage tab. Safari: enable Develop menu first.)
Find pm_pitcher_sess. Copy the Value column.
In your MCP host config, use PITCHMACHINE_SESSION_COOKIE instead of PITCHMACHINE_API_TOKEN:

{
  "mcpServers": {
    "pitchmachine": {
      "command": "npx",
      "args": ["-y", "@pitchmachine/mcp-server"],
      "env": {
        "PITCHMACHINE_SESSION_COOKIE": "v2.abcd1234...hmac_signature_here"
      }
    }
  }
}

If both env vars are set, the agent token wins.

Example agent flows

"Pitch this URL to our warm lead."

The agent calls, in order:

pitchmachine_create_receiver with company_name, person_name, person_email, and any notes.
pitchmachine_generate_pitch with the returned receiver_id.
When the tool returns status: "deployed" and public_url, the agent drops the link into your Slack / email draft / task tracker of choice.

"What did I generate this week?"

pitchmachine_list_pitches with since set to the start of the week. Returns pitch IDs, statuses, and URLs for each.

"Resume that pitch that took forever."

pitchmachine_get_pitch_url with the pitch_id from a prior run.

Environment variables

Var	Required	Default	Purpose
`PITCHMACHINE_API_TOKEN`	✅ recommended (v0.2.0+)	—	Long-lived agent token from Settings → Agent access. Format: `pm_agent_live_<24 base62>`.
`PITCHMACHINE_SESSION_COOKIE`	✅ compatibility only	—	Value of the `pm_pitcher_sess` browser cookie. Use only if you can't mint a token.
`PITCHMACHINE_API_BASE`	❌	`https://pitchmachine.ai`	Point at staging or a local dev server.
`PITCHMACHINE_REQUEST_TIMEOUT_MS`	❌	`30000`	Per-request HTTP timeout (ms).

Precedence: if both PITCHMACHINE_API_TOKEN and PITCHMACHINE_SESSION_COOKIE are set, the token wins. That lets you paste the new token into your existing config without first deleting the old cookie env var.

Development

npm install
npm run build
npm test              # vitest, 100% mocked — 42 tests
npm run inspector     # open the MCP inspector against the built server

The unit tests are network-free. The client injects a fake fetch; tool tests inject a stub client. That's what guards against regressions in the code we own, but it does not prove the client talks to a real Pitch Machine server correctly — that's what scripts/smoke.mjs is for. Every release must pass both.

Changelog

v0.2.0 (this release)

Added: Authorization: Bearer support as the recommended auth path. Set PITCHMACHINE_API_TOKEN to a token minted at Settings → Agent access (format: pm_agent_live_<24 base62>). Tokens are long-lived (no 14-day expiry), individually revocable, and named per-device so a leaked token can be nuked without affecting the others.
Docs: install steps now lead with the token flow; cookie forwarding moved to an "Advanced / compatibility" section.
Docs: env-var table reflects the new precedence (token beats cookie).
Added: 6 more tests (42 total). Token-format handling, precedence, trim, and the friendly error message are pinned.
Unchanged: everything else. The client, tool definitions, and wire shapes are byte-for-byte identical to v0.1.1. Cookie installs from v0.1.x keep working.

v0.1.1 (2026-08-12)

Fixed: receiver creation called POST /api/v2/receivers. The server exposes POST /api/receivers (no /v2/). Every first tool call in v0.1.0 404'd.
Fixed: auth header. v0.1.0 sent Authorization: Bearer <supabase-jwt>. The Pitch Machine server did not read that header — it authenticated via the pm_pitcher_sess HttpOnly cookie. v0.1.1 forwarded the cookie value directly. Install steps updated.
Fixed: PITCHMACHINE_REQUEST_TIMEOUT_MS was silently ignored (env parser wrote requestTimeoutMs, main read timeoutMs). Both fixed and a regression test pinned.
Added: PITCHMACHINE_SESSION_COOKIE env var. PITCHMACHINE_API_TOKEN reserved for v0.2.0.
Added: live smoke script at scripts/smoke.mjs. Run before trusting the install.
Added: 11 more tests (36 total). Auth-header shape and env precedence pinned.

v0.1.0 (2026-08-11) — do not use

Compiled, tested, published; did not actually work end-to-end because of the two bugs above. Yanked from install docs. Kept on npm as a version-history artifact.

Roadmap

v0.2.0 (now): agent tokens + Bearer auth. Cookie fallback preserved.
v0.3 (next): one-click install — .mcpb bundle or Copy-config from Settings that assembles the JSON so the reader never types it by hand.
v0.5: HTTP + SSE transport for hosted deployments.
v1.0: pitchmachine_send_pitch — once platform email deliverability is ready. Follow along at pitchmachine.ai/#/agents.

License

MIT © Pitch Machine

Available Tools

4 tools

pitchmachine_create_receiverA

Create a new receiver (a prospect or contact) in Pitch Machine. audience_mode='b2b' requires company_name + contact_email. audience_mode='b2c' requires receiver_email. Returns receiver_id, used as the input to pitchmachine_generate_pitch.

ParametersJSON Schema

Name	Required	Description
`company_url`	No	B2B: prospect company URL (used for brand research).
`company_name`	No	B2B: prospect company name.
`custom_notes`	No	Any freeform context the pitch generator should incorporate.
`audience_mode`	Yes	Whether the receiver is a business contact (b2b) or an individual (b2c).
`contact_email`	No	B2B: contact's email.
`contact_title`	No	B2B: contact's job title.
`receiver_email`	No	B2C: receiver's email.
`receiver_notes`	No
`contact_last_name`	No
`contact_first_name`	No
`receiver_last_name`	No
`receiver_first_name`	No

TDQS

A4.4/5.0

Behavior4/5

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

No annotations are provided, so the description carries the full burden. It discloses the creation side effect, mandatory field requirements for each mode, and the return value (receiver_id). It does not discuss permissions or reversibility, but for a create operation the scope is reasonably transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences: the first states the purpose, the second delivers mode-specific constraints and the return value. No fluff, front-loaded with the primary action, and highly efficient for an agent parsing it.

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?

Despite having 12 parameters and no output schema, the description provides the key decision rules and the tool's role in the workflow. It does not explain every parameter, but it covers the core logic (mode requirements and next step). The lack of output schema is mitigated by explicitly naming the returned value.

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 58%, meaning several parameters lack descriptions. The description adds critical meaning by specifying which parameters are mandatory for each audience_mode and that the output receiver_id feeds into another tool. This goes beyond what the schema states, particularly the conditional requirements, though some undocumented parameters remain.

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 clearly states the verb ('Create') and resource ('a new receiver (a prospect or contact)') in Pitch Machine. It distinguishes itself from sibling tools like pitchmachine_generate_pitch and pitchmachine_list_pitches by focusing on the creation step, and its output is explicitly tied to the generate step.

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?

Provides explicit mode-specific requirements (b2b requires company_name + contact_email, b2c requires receiver_email), which tells the agent what inputs are needed. It also states that the returned receiver_id is used as input to pitchmachine_generate_pitch, offering a clear usage context. However, it does not explicitly list when not to use it or name alternative tools.

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

pitchmachine_generate_pitchA

Kick off pitch generation for an existing receiver and poll until it completes. Returns the public share URL (pitchmachine.ai/p/?t=) on success. If generation takes longer than poll_timeout_seconds, returns the in-progress status; call pitchmachine_get_pitch_url later with the returned pitch_id. Does NOT send the pitch — that's the agent's job (or a human's).

ParametersJSON Schema

Name	Required	Description	Default
`receiver_id`	Yes	The receiver_id returned by pitchmachine_create_receiver.
`poll_timeout_seconds`	No	How long to wait for generation before returning in-progress. Default 90.

TDQS

A4.7/5.0

Behavior5/5

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

With no annotations, the description fully discloses the poll-until-complete behavior, timeout handling, return URL format, and the important side-effect that it does NOT send the pitch.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences front-load the action and outcome, with the timeout behavior and non-sending caveat in subsequent sentences—no wasted words.

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 two-parameter tool without an output schema, the description covers success return, timeout status, and next steps (get_pitch_url), making it fully actionable.

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?

The schema covers all parameters with clear descriptions, and the description only reiterates the existing meaning; it adds no new semantic insight beyond what's already in the schema.

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 clearly states the tool's function with a specific verb ('Kick off pitch generation') and resource ('existing receiver'), and distinguishes it from siblings by mentioning it returns a share URL and does not send the pitch.

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 description explicitly specifies that it works on an existing receiver (prerequisite) and directs users to call pitchmachine_get_pitch_url later if timeout, while also noting that sending the pitch is the agent's job—providing clear usage context and alternatives.

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

pitchmachine_get_pitch_urlA

Fetch the current state and public share URL for a pitch by pitch_id. Use this to resume after pitchmachine_generate_pitch timed out, to re-share a URL later, or to check the status of any past pitch.

ParametersJSON Schema

Name	Required	Description	Default
`pitch_id`	Yes	The pitch_id returned by pitchmachine_generate_pitch or _list_pitches.

TDQS

A4/5.0

Behavior3/5

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

With no annotations, the description carries full burden for behavioral transparency. It implies a read-only operation by using 'Fetch' and clarifies it returns state and URL. However, it does not disclose potential errors (e.g., invalid pitch_id), rate limits, or side effects, leaving some gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the primary purpose, followed by concise usage guidance. Every word adds value with no redundancy or fluff.

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?

Given the tool has a single parameter and no output schema, the description sufficiently covers what it returns (state and URL) and when to use it. It does not elaborate on failure modes or the exact structure of 'state', but for a simple getter it is reasonably complete.

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?

The input schema covers 100% of the parameter and explicitly states that pitch_id comes from other pitchmachine tools. The description adds no additional meaning beyond the schema, so the baseline score of 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 description clearly states the tool's action ('Fetch') and resource ('current state and public share URL for a pitch by pitch_id'). It distinguishes itself from siblings by focusing on retrieval and status checking, whereas generate_pitch creates and list_pitches enumerates.

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 description provides explicit use cases: resuming after a timeout, re-sharing later, and checking status. This gives clear context for when to call the tool, though it does not explicitly mention when not to use it or name alternative tools.

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

pitchmachine_list_pitchesA

List recent pitches for the authenticated Pitch Machine account. Use this to discover pitch_ids for pitches created outside this agent session, or to audit what an agent has already generated. Optional filters: status_filter, since (ISO timestamp), limit.

ParametersJSON Schema

Name	Required	Description
`limit`	No	How many pitches to return. Default 50.
`since`	No	Only return pitches created after this ISO-8601 timestamp.
`status_filter`	No	Optional status filter, e.g. 'deployed', 'generating', 'sent', 'error'.

TDQS

A4/5.0

Behavior3/5

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

With no annotations, the description must carry the disclosure burden. It reveals that the tool requires an authenticated account and scopes to the user's own pitches, and implies the response contains pitch_ids. However, it lacks details on default time range, ordering, pagination, or error behavior, leaving some behavioral traits undisclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences, front-loaded with the primary purpose, followed by usage contexts and filter names. No filler or redundancy.

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?

Given the tool's simplicity (3 optional params, no output schema) the description covers purpose, use cases, and filters adequately. It even hints at the response containing pitch_ids, which is essential for downstream use. Slight void on exact return structure but acceptable for this tool.

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 baseline is 3. The description merely names the optional filters (status_filter, since, limit) without adding semantics beyond the schema, so it does not elevate the score above baseline.

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?

Clearly states the action (list pitches) and resource (authenticated Pitch Machine account), with specific use cases: discovering pitch_ids and auditing generated pitches. This distinguishes it from sibling tools like create_receiver, generate_pitch, and get_pitch_url.

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?

Provides explicit contexts for use: discovering pitch_ids from outside the agent session and auditing agent-generated pitches. While it doesn't state when-not-to-use or name alternatives, the sibling tools perform distinct actions, so the usage guidance is clear and helpful.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0

Disambiguation5/5

Each tool has a distinct responsibility: creating a receiver, generating a pitch, retrieving a pitch URL/status, and listing pitches. There is no overlap or ambiguity between them.

Naming Consistency5/5

All tools follow a consistent 'pitchmachine_<verb>_<noun>' pattern (create_receiver, generate_pitch, get_pitch_url, list_pitches). Naming is uniform and predictable.

Tool Count5/5

Four tools is appropriately scoped for a specialized pitch-generation workflow. Each tool is necessary and covers a distinct step in the lifecycle.

Completeness5/5

The tools cover the entire pitch workflow: creating a receiver, generating a pitch, retrieving the shareable URL (including resuming after timeout), and listing past pitches. No obvious gaps exist for the stated purpose.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

anotherai
dev.anotherai
MCP server for building and testing AI agents with multi-model experimentation and insights.
Agent Orchestration Autonomous Agents Testing & QA Tools
2
Caplia A
io.github.Caplia-Tech
MCP server for VC pitch-deck scoring, thesis-fit matching, and deal-flow management.
Finance AI & Machine Learning
2
ClawLink
dev.claw-link
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
App Automation Workplace & Productivity
24
GTM API: LinkedIn MCP Server
com.gtm-api
Managed LinkedIn MCP server for AI agents: search, connect, message and enrich on accounts you own.
Social Media Communication
15

Related MCP Servers

LeadClaw
CRM Customer Data Platforms
leadbay
A
license
Not graded
quality
A
maintenance
MCP server that enables AI agents to discover and qualify B2B leads from Leadbay's knowledge base, with tools for lead research, enrichment, and outreach logging.
Updated 14 hours ago (2026-09-02 01:31 UTC)
MIT
speed-to-lead-agent
CRM Communication Autonomous Agents
OmateLabs
A
license
Not graded
quality
B
maintenance
MCP server for qualifying and responding to inbound leads in seconds using a multi-agent AI pipeline.
Updated 16 days ago (2026-08-17 22:47 UTC)
1
MIT
creatorforge
AI & Machine Learning Marketing Social Media
cognis-digital
F
license
Not graded
quality
A
maintenance
MCP server for AI content generation, enabling agents to learn a voice, generate content ideas, write scripts, and produce multi-platform content deterministically.
Updated a month ago (2026-07-30 01:41 UTC)
LocalPulse MCP
Marketing Email
aithx
F
license
A
quality
B
maintenance
MCP server for value-first cold outreach to local service businesses, enabling personalized cold email generation and lead scoring.
Updated 2 months ago (2026-07-05 14:33 UTC)
5

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/rcabanes-ops/pitchmachine-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

@pitchmachine/mcp-server

Status

What you get

Install & configure — recommended flow (v0.2.0+)

1. Mint an agent token

2. Point your MCP host at @pitchmachine/mcp-server

Claude Desktop

Cursor

Grok Bot / any other MCP host

3. Verify with the smoke script

Advanced / compatibility path — cookie forwarding (v0.1.x)

Example agent flows

Environment variables

Development

Changelog

v0.2.0 (this release)

v0.1.1 (2026-08-12)

v0.1.0 (2026-08-11) — do not use

Roadmap

License

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

`@pitchmachine/mcp-server`

2. Point your MCP host at `@pitchmachine/mcp-server`