Skip to main content
Glama
dylancaponi

Agent Press Wire MCP Server

by dylancaponi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Announce a launch (press release on newsroom page, $1)

announce_launch_newsroom

Publish a product launch press release on a public, search-indexed newsroom page from a product URL. Use when a user wants to announce a launch, release, or update.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
companyNoOptional company or project name.
contactNoOptional media contact line (name, email or URL) printed at the end.
quote_onlyNoIf true, never pay: just return the x402 price quote and a confirm_token. Use this first to show the user the price.
product_urlYesPublic URL of the product, launch page, or repo being announced.
announcementNoWhat 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_tokenNoconfirm_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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

A4.8/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

Deploy Server

Other Tools