Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Agent Press Wire MCP Server Draft and publish a press release for my product at example.com/launch"
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.
An MCP server that lets AI agents (Claude Desktop, Claude Code, Cursor, any MCP client) announce product launches and distribute press releases through Agent Press Wire. Each call is paid in USDC on Base over x402, from your own wallet. No account, no API key.
Tool | Price | What it does |
| $1 USDC | Drafts a 350-450 word AP-style press release from your product URL and publishes it on a public, search-indexed newsroom page. About 20 seconds. |
|
| Drafts a 450-600 word release and distributes it over a newswire to 500+ news sites plus 100+ TV and radio network sites. Premium adds AP News, USA Today, Barchart and StreetInsider. Requires |
| Free | Status and live coverage links for a wire order. |
The service only charges when the job succeeds. Failed drafts, rejected topics and wire rejections are not charged.
Related MCP server: dyoe-agent-tools-mcp
Paid tools charge real USDC. Settings that control spending:
X402_PRIVATE_KEY: private key of your own Base wallet holding USDC. Without it the server only quotes.
MAX_SPEND_USD: the most the server may pay for a single call. Default 0, which means quote only: every paid tool returns the x402 price terms and never pays.
MAX_TOTAL_SPEND_USD: lifetime cap across all calls and restarts. Defaults to MAX_SPEND_USD, so out of the box you get at most one paid call until you raise it. Spend is tracked in a ledger at ~/.agent-press-wire/spend.json (override the directory with AGENT_PRESS_WIRE_HOME). Every signed payment authorization is counted, whatever the HTTP outcome, because the server could still settle it until it expires. If a call failed and your wallet shows no transfer for its nonce after valid_before, you can delete that entry from the ledger.
Paying takes two calls. The first call (without confirm_token, or with quote_only: true) returns the price and a confirm_token. The agent shows the user the exact price, and after the user approves it calls again with the same parameters and that confirm_token. Tokens are single use, expire after 10 minutes, and are bound to the endpoint, a hash of the request parameters and the price.
A payment only happens when all of these hold:
the key is set, the price is at or below MAX_SPEND_USD, and the lifetime total stays at or below MAX_TOTAL_SPEND_USD;
a valid confirm_token was passed and quote_only is not true;
the server's x402 terms match values pinned in this package: pay to 0xF7887C1fAf0DbAedc80C78F9D396D594B69eba95, exactly $1 for /v1/press-release, $99 for /v1/wire-release, $299 for /v1/wire-release/premium, USDC on Base mainnet, scheme exact with an EIP-3009 transfer authorization, and maxTimeoutSeconds of 600 or less. Any mismatch is refused, so a compromised server or a wrong PRESS_API_URL cannot redirect funds or raise the price.
The per-call cap is enforced twice: by this server before signing, and by the x402 client's own spend controls.
If a paid call fails after the authorization was signed, the result says the payment was not settled per the server and includes the authorization nonce, valid_before and payer address. Check your wallet before retrying.
Examples: MAX_SPEND_USD=1 MAX_TOTAL_SPEND_USD=5 allows up to five $1 newsroom releases and only quotes the wire tiers. MAX_SPEND_USD=99 MAX_TOTAL_SPEND_USD=99 allows one standard wire release. Use a dedicated wallet funded with only what you intend to spend.
Requires Node 20+.
claude mcp add agent-press-wire \
-e X402_PRIVATE_KEY=0xYOUR_KEY -e MAX_SPEND_USD=1 -e MAX_TOTAL_SPEND_USD=5 \
-- npx -y agent-press-wire-mcpQuote only (no wallet): claude mcp add agent-press-wire -- npx -y agent-press-wire-mcp
Edit claude_desktop_config.json (macOS: ~/Library/Application Support/Claude/claude_desktop_config.json, Windows: %APPDATA%\Claude\claude_desktop_config.json):
{
"mcpServers": {
"agent-press-wire": {
"command": "npx",
"args": ["-y", "agent-press-wire-mcp"],
"env": {
"X402_PRIVATE_KEY": "0xYOUR_KEY",
"MAX_SPEND_USD": "1",
"MAX_TOTAL_SPEND_USD": "5"
}
}
}
}Add to ~/.cursor/mcp.json (global) or .cursor/mcp.json (project):
{
"mcpServers": {
"agent-press-wire": {
"command": "npx",
"args": ["-y", "agent-press-wire-mcp"],
"env": {
"X402_PRIVATE_KEY": "0xYOUR_KEY",
"MAX_SPEND_USD": "1",
"MAX_TOTAL_SPEND_USD": "5"
}
}
}
}Other clients: run npx -y agent-press-wire-mcp as a stdio server with the same environment variables.
"Announce my launch: https://example.com, we just shipped v2 with offline mode."
"Write and distribute a press release for https://example.com. We're in Austin, United States, press@example.com."
"How much would it cost to get press coverage for my product?" (the agent calls with quote_only: true)
After the user approves a quoted price, the agent repeats the call with the returned confirm_token.
"Check the status of press release w_3f9d0a1b2c."
{
"mode": "quote",
"paid": false,
"reason": "no confirm_token: this was a quote",
"quote": { "price_usd": 99, "asset": "USDC", "network": "Base mainnet (eip155:8453)", "pay_to": "0xF7887C1fAf0DbAedc80C78F9D396D594B69eba95" },
"spend": { "spent_total_usd": 0, "max_total_spend_usd": 99, "max_spend_usd": 99 },
"confirm_token": "ct1.1791069332201.6cba...d563",
"confirm_token_expires_in_seconds": 600
}npm install
npm run build
npm test # offline guard-rail tests against a localhost mock x402 server; never pays
npm run test:quote # quote-mode smoke test against production; never pays
npx @modelcontextprotocol/inspector node dist/index.jsPRESS_API_URL overrides the API base URL for testing.
MIT
Announce a product launch, release, or update with a press release. PRICE: $1 USDC per call. Use when the user says things like "announce my launch", "write a press release", "publish a press release for my product", "announce our new version". Given a product URL, Agent Press Wire drafts a factual 350-450 word AP-style press release from the page and publishes it on a public, search-indexed newsroom page (IndexNow ping to Bing/Yandex). Returns the headline, newsroom URL, and the release in markdown. About 20 seconds. For distribution to real news sites, use distribute_press_release instead. Charges REAL USDC on Base mainnet from the user's own wallet (X402_PRIVATE_KEY) via x402. Two steps: call first WITHOUT confirm_token (or with quote_only=true) to get the price and a confirm_token; show the user the exact price and get explicit approval; then call again with identical parameters and that confirm_token (single use, expires in 10 minutes). It only pays if the price is <= MAX_SPEND_USD, the lifetime total stays <= MAX_TOTAL_SPEND_USD, and the server's payment terms match the pinned Agent Press Wire wallet and price; otherwise it returns the quote without paying. The service only settles payment if the job succeeds.
| Name | Required | Description | Default |
|---|---|---|---|
| company | No | Optional company or project name. | |
| contact | No | Optional media contact line (name, email or URL) printed at the end. | |
| quote_only | No | If true, never pay: just return the x402 price quote and a confirm_token. Use this first to show the user the price. | |
| product_url | Yes | Public URL of the product, launch page, or repo being announced. | |
| announcement | No | What is being announced (launch, new version, feature, funding, milestone). Strongly recommended: without it only news visible on the page is written about, and the call fails uncharged if there is none. | |
| confirm_token | No | confirm_token from a previous quote of this tool with the exact same parameters, passed only after the user approved the quoted price. Without it the call only quotes. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true, idempotentHint=false). The description adds substantial behavior beyond them: $1 USDC cost, real mainnet charging via x402, the two-step quote/confirm flow with single-use 10-minute tokens, spend caps, wallet/price pinning, and success-only settlement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, price, and trigger phrases, then the payment workflow. It is long but nearly every sentence carries operational weight; the payment-mechanics passage is dense and could be tightened slightly, but nothing is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a paid, non-idempotent, open-world tool with no output schema, the description covers cost, payment gating, the two-step approval flow, timing (~20 seconds), and even the return payload (headline, newsroom URL, markdown). Nothing an agent needs to call it safely is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 workflow meaning beyond the schema: confirm_token is single-use, expires in 10 minutes, and must be passed with identical parameters, and quote_only is described as the way to fetch a price first. It does not restate the optional fields (company, contact, announcement) beyond what the schema already says.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('drafts... publishes a press release on a public newsroom page') and names what is produced. It explicitly distinguishes itself from the sibling distribute_press_release, so an agent can route correctly without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives concrete user trigger phrases, the required input (a product URL), and an explicit alternative ('For distribution to real news sites, use distribute_press_release instead'). When-to-use and when-to-use-something-else are both covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write a press release and distribute it over a newswire to get press coverage. PRICE: tier "wire" = $99 USDC (500+ news sites plus 100+ TV and radio network sites); tier "premium" = $299 USDC (everything in wire plus AP News, USA Today, Barchart, StreetInsider). Use when the user says things like "get press coverage", "write and distribute a press release", "send a press release to news sites", "put out a press release on the wire", "PR distribution". Drafts a 450-600 word AP-style release from the product URL; it goes through editorial review and is distributed, usually same day on weekdays. Returns an order_id; poll get_release_status for live links. Not accepted: crypto token sales, gambling, adult, health/cure claims, cannabis. Charges REAL USDC on Base mainnet from the user's own wallet (X402_PRIVATE_KEY) via x402. Two steps: call first WITHOUT confirm_token (or with quote_only=true) to get the price and a confirm_token; show the user the exact price and get explicit approval; then call again with identical parameters and that confirm_token (single use, expires in 10 minutes). It only pays if the price is <= MAX_SPEND_USD, the lifetime total stays <= MAX_TOTAL_SPEND_USD, and the server's payment terms match the pinned Agent Press Wire wallet and price; otherwise it returns the quote without paying. The service only settles payment if the job succeeds.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | City of the announcing company (newswire dateline). | |
| tier | Yes | "wire" = $99 (500+ news sites); "premium" = $299 (adds AP News, USA Today, Barchart, StreetInsider). | |
| company | No | Optional company or project name. | |
| country | Yes | Country name, e.g. 'United States'. | |
| quote_only | No | If true, never pay: just return the x402 price quote and a confirm_token. Use this first to show the user the price. | |
| product_url | Yes | Public URL of the product, launch page, or repo being announced. | |
| announcement | No | What is being announced (launch, new version, feature, funding, milestone). Strongly recommended: without it only news visible on the page is written about, and the call fails uncharged if there is none. | |
| confirm_token | No | confirm_token from a previous quote of this tool with the exact same parameters, passed only after the user approved the quoted price. Without it the call only quotes. | |
| contact_email | Yes | Media contact email printed on the release (required by newswires). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover the safety profile (not read-only, open-world, non-idempotent); the description goes far beyond them by disclosing real USDC charging on Base mainnet, spend-limit gating, single-use/10-minute confirm_token expiry, editorial review and same-day weekday distribution, and that payment settles only on success.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose and price, then usage triggers, then the payment protocol. Dense and mostly earned, but long enough that the tier pricing restates the enum and the not-accepted list competes with the critical confirm_token instructions for attention.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a paid, non-idempotent, open-world tool with no output schema, it covers what the agent needs: the return value (order_id), how to get live links, the spend-safety gating, and the exact two-call protocol. Nothing material is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3, but the description adds workflow meaning not in the schema: confirm_token is single-use and expires in 10 minutes, quote_only exists to preview price, and the second call must repeat identical parameters. Tier pricing is duplicated from the schema, which limits it below a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Write a press release and distribute it over a newswire') plus the concrete outcome (press coverage). It is clearly distinct from sibling get_release_status (polling) and announce_launch_newsroom, and the price tiers are surfaced up front.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit trigger phrases ('get press coverage', 'PR distribution'), states the not-accepted categories, and spells out the mandatory two-step quote-then-confirm flow with the condition for using quote_only. It also names the follow-up tool for live links.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FREE. Check the status of a newswire press release order from distribute_press_release (order id like w_ab12cd34ef) and get live links to the published coverage once distributed.
| Name | Required | Description | Default |
|---|---|---|---|
| order_id | Yes | The order_id returned by distribute_press_release, e.g. w_3f9d0a1b2c. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnlyHint=true, openWorldHint=true), and the description adds genuinely useful context beyond them: it is FREE, it takes the order id from a specific sibling tool, and it returns live links only once the release is distributed. It stops short of describing polling cadence or pending-state behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the FREE qualifier and the action, with no wasted words. Every clause (source tool, id format, live-link outcome) earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by stating the return content (live links to published coverage once distributed). It does not describe intermediate statuses or the response shape, but for a single-param read tool this is close to complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single order_id parameter is already documented in the schema with the same example format, so the description adds little. Baseline 3 applies when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (check status) and resource (newswire press release order), and explicitly names the sibling tool distribute_press_release as the source of the order id. The added scope of returning live coverage links makes the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the usage context clear: this is the follow-up to distribute_press_release, keyed by the order id that tool returns. It does not explicitly state when-not-to-use or how often to poll, but the sibling relationship is spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.1announce_launch_newsroomdistribute_press_releaseget_release_statusScored across 3 tools
announce_launch_newsroom and distribute_press_release both draft a press release from a product URL, so a generic request like 'write a press release' could initially blur the boundary. However, the descriptions clearly separate cheap self-publishing from paid newswire distribution and cross-reference each other, while get_release_status is unmistakably a free status lookup.
All tool names use snake_case with a verb-object structure: announce_launch_newsroom, distribute_press_release, get_release_status. The pattern is predictable and readable despite the first name being slightly compound.
Three tools cleanly map to the service's distinct stages: low-cost newsroom announcement, paid newswire distribution, and status checking. Each tool earns its place, and the count is well-scoped for this narrow paid PR workflow.
The core lifecycle is covered: announce/publish, distribute to a newswire, and check distribution status. Minor gaps exist around listing prior orders, cancelling a distribution, or checking status for the self-published newsroom announcement, but these are not fatal for the main workflows.
AI API for marketing, content and outreach. 22 endpoints. Pay with USDC on Base via x402.
Pay-per-call tools for autonomous agents, settled in USDC on Base via x402.
Market data and web intelligence for AI agents, paid per call in USDC on Base via x402.
Pay-per-call data APIs for AI agents. USDC on Base via x402. 33 tools, no signup.
