Skip to main content
Glama
PROMPTEYE-SP-Z-O-O

prompteye-mcp

Official

Mark an article as published

publish_article

Records that an article went live on the user's site at the given address and marks it published, the same as saving the live URL in the PromptEye app.

Instructions

Records that an article went live on the user's site at the given address and marks it published, the same as saving the live URL in the PromptEye app. From then on PromptEye shows it as published content and follows whether the assistants cite that page. Call this once the user has published the text from get_article on their own site. The article must be written first — draft, ready, published or tracked are accepted; one still processing or in error is refused. Calling it again with another address replaces the URL and keeps the first publication date.

PromptEye generates content as well as measuring visibility, and the two make one loop: track the prompts and how often the assistants name the brand on them, generate an article that targets a prompt where the brand is weak, publish it, then measure whether that prompt's visibility and citations move. Generation starts from a content brief: PromptEye fans the target prompt out into the phrases people ask around it, keeps the ones that belong in this article, sets aside the ones that deserve an article of their own, and writes a title and an H2/H3 outline from them. create_content_brief orders one and get_content_brief reads it. create_article then writes the article from a ready brief, from the brand description, the knowledge documents picked for it and the chosen writing style; get_article reads its text and list_articles lists the project's articles, also those added in the app under Content (https://app.prompteye.com/content). Publishing the page is done on the user's own site; publish_article then records the URL it went live at, and requesting indexing and following citations happen in the app. A generated article is a draft to review, and neither it nor its indexing guarantees that an assistant will cite it. Guides: https://app.prompteye.com/help/content/ and https://app.prompteye.com/help/content/article-workflow/.

Input Schema

NameRequiredDescriptionDefault
urlYesThe full http(s) address the article went live at.
articleIdYesId of the article, as create_article or list_articles reports it.

Output Schema

NameRequiredDescriptionDefault
idYes
errorYesWhy the last generation failed. null unless status is error; content then still holds the previous version, if there was one.
titleYes
promptYesThe target prompt the article was written for.
sourceYesgenerated_article when PromptEye wrote it from a brief, uploaded_docx or pasted when it was added in the app.
statusYesprocessing while PromptEye writes it, then draft (the text is in content) or error. ready, published and tracked are later steps the team moves it through in the app.
briefIdYesThe content brief it was written from. null = text added to the app by hand.
contentYesThe article text in Markdown, with ## and ### headings. null until it is written.
createdAtYesWhen the article was created, ISO 8601 in UTC.
projectIdYes
updatedAtYesWhen the article last changed, ISO 8601 in UTC.
publishUrlYesWhere the article was published. null until it is.
publishedAtYesWhen it was published, ISO 8601 in UTC. null until it is.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.0.28

TDQS

A4.3/5.0
Behavior5/5

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

Beyond the annotations, it discloses the state-machine gate, the overwrite semantics on repeat calls ('replaces the URL and keeps the first publication date'), and the downstream effects (PromptEye tracks citations; indexing and citation-following happen in the app). It also sets an honest expectation that citation is not guaranteed, which is real behavioral context, not schema repetition.

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

Conciseness2/5

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

The first paragraph is well front-loaded and entirely on-topic, but the second paragraph is a long detour through content briefs, create_content_brief, create_article, and the generate-then-measure loop that does nothing for a caller of this tool. Roughly half the text is promotional context for sibling tools, violating the 'every sentence earns its place' bar.

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 2-parameter mutating tool with full annotations and an output schema, the definition covers preconditions, side effects, repeat-call behavior, and adjacent responsibilities — nothing needed to call it correctly is missing. The only deficiency is the surplus off-topic material rather than a gap.

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 coverage is 100%, so both `articleId` and `url` are already documented, including the 'full http(s) address' format. The description reinforces that the URL is where it went live on the user's own site and that a new URL replaces the old one, but adds little technical detail beyond the schema — the baseline 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 opening sentence states a specific verb and resource — records that an article went live and marks it `published` — and immediately equates it to a concrete app action. It is clearly distinguishable from siblings like create_article (writes text), get_article (reads text), and list_articles (enumerates), all of which the description also names.

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 an explicit trigger ('Call this once the user has published the text from get_article on their own site'), an explicit precondition with the accepted and refused states (`draft`/`ready`/`published`/`tracked` accepted, `processing`/`error` refused), and clarifies that the actual publishing/indexing happen elsewhere. When-not is as concrete as when.

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