Skip to main content
Glama
Sign In

LivePublicator

by com.livepublicator
OverviewDiscussionsAdmin

Fix a live release

fix_live_release
DestructiveIdempotent

Fixes the text of a published press release within 24 hours of it going live: a typo, a wrong date, a link, the quote. Send only the fields to change. The release keeps the same link and the earlier version is kept. The change is checked again before it shows. After 24 hours the text can't be changed.

Input Schema

NameRequiredDescriptionDefault
faqNoOptional: up to 6 questions and answers.
bodyNoThe release body, 250 to 1,000 words, as text, Markdown or HTML. Do not repeat the headline. 3 links at most.
quoteNoA quote from a real person at the company. More quotes can go in the body.
summaryNoOne sentence that sums up the news (40 to 300 characters).
headlineNoOne line, 10 to 200 characters. Name the company in it.
key_factsNo1 to 8 short facts, 5 to 200 characters each.
quote_nameNoFull name of the person quoted.
release_idYesThe release id.
image_is_aiNotrue when the image was made with AI (for example by you, at the user's request). The page then labels it "Illustration, created with AI".
quote_titleNoRole of the person quoted, e.g. Founder and CEO.
contact_nameNoPress contact's name, shown for journalists.
contact_emailNoPress contact's email.
contact_titleNoPress contact's role.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / body / description
      Previous value: -"The release body, 150 to 800 words, as text, Markdown or HTML. Do not repeat the headline. 3 links at most."New value: +"The release body, 250 to 1,000 words, as text, Markdown or HTML. Do not repeat the headline. 3 links at most."
  2. Changed1 schema field changed
    • addedInput schema / properties / image_is_ai
      Added value: +{
+  "description": "true when the image was made with AI (for example by you, at the user's request). The page then labels it \"Illustration, created with AI\".",
+  "type": "boolean"
+}
  3. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Adds real behavior beyond the annotations: the link is preserved, the prior version is retained (reversibility), and the edit is re-checked before it appears (a review delay the agent should expect). It does not say what the tool returns, whether re-review can reject the change, or what error surfaces once the 24-hour window closes — meaningful gaps for a destructiveHint mutation on live content.

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?

Four short sentences, zero waste: purpose and time window first, then the partial-update instruction, then the consequences (same link, prior version kept, re-check). Nothing is buried or repeated from the schema.

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?

For a 13-parameter mutation with full schema coverage and rich annotations, the description covers scope, input contract and side effects adequately. With no output schema, it never indicates what a successful call returns or how a rejection after re-review is reported, which is the main remaining hole.

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% and the field descriptions already carry word counts, character limits and link caps, so the baseline is 3. The description earns an extra point by stating 'Send only the fields to change,' which makes the partial-update contract explicit — the only required field being release_id implies this but does not state it.

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?

Names a specific verb and resource — fixing the text of an already-published press release — and pins the scope with 'within 24 hours of it going live.' The examples ('a typo, a wrong date, a link, the quote') make it immediately distinguishable from create_release, publish_release and update_release without opening any schema.

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?

Gives a clear use window (within 24 hours of going live) and an explicit exclusion ('After 24 hours the text can't be changed'), plus the partial-update instruction 'Send only the fields to change.' It stops short of naming the alternative tool an agent should use for a release older than 24 hours, leaving that routing to inference from the sibling list.

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

All LivePublicator 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