prompteye-mcp

Official

Overview Schema Source Related Servers Discussions Admin

Write the article for a content brief

create_article

Has PromptEye write the article for a content brief: the brief's title and H2/H3 outline, filled in with the project's brand description and knowledge base, in the language of the project's market.

Instructions

Has PromptEye write the article for a content brief: the brief's title and H2/H3 outline, filled in with the project's brand description and knowledge base, in the language of the project's market. Call this when the user wants the article itself written, once get_content_brief reports the brief ready; a brief that is still processing or failed is refused. Before calling it, show the user the brief from get_content_brief — its title and H2/H3 outline — and wait for their explicit yes; a request to write an article is not that yes, since the outline decides what gets written and the article uses the plan's allowance.

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/.

Requesting it is instant; writing takes a few minutes. The article comes back processing — read it with get_article until status is no longer processing. A brief has one article: calling this again for a brief whose article is already written rewrites it and replaces the previous text, and it is refused while the article is still being written. Each written article counts against the plan's monthly article limit.

Input Schema

Name	Required	Description	Default
`briefId`	Yes	Id of the brief to write the article for, as create_content_brief reports it.
`confirmedByUser`	Yes	Must be true, and only set it once the user has seen the brief's title and outline and explicitly agreed in this conversation to have this article written.

Output Schema

Name	Required	Description
`id`	Yes
`error`	Yes	Why the last generation failed. null unless status is error; content then still holds the previous version, if there was one.
`title`	Yes
`prompt`	Yes	The target prompt the article was written for.
`source`	Yes	generated_article when PromptEye wrote it from a brief, uploaded_docx or pasted when it was added in the app.
`status`	Yes	processing 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.
`briefId`	Yes	The content brief it was written from. null = text added to the app by hand.
`content`	Yes	The article text in Markdown, with ## and ### headings. null until it is written.
`createdAt`	Yes	When the article was created, ISO 8601 in UTC.
`projectId`	Yes
`updatedAt`	Yes	When the article last changed, ISO 8601 in UTC.
`publishUrl`	Yes	Where the article was published. null until it is.
`publishedAt`	Yes	When it was published, ISO 8601 in UTC. null until it is.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.0.28Oct 23, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Adds substantial context beyond the annotations: async behavior ('requesting is instant; writing takes a few minutes', poll with get_article until status leaves `processing`), quota consumption against the plan's monthly article limit, and rewrite semantics where a second call for the same brief replaces the previous text (consistent with idempotentHint=false). It also discloses that a refusal occurs while writing is in progress and that citation is not guaranteed. The one omission is any hint about failure recovery if generation errors out.

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 the action and the gating conditions, and the operational facts (async polling, quota, rewrite/refusal) are grouped at the end. The middle paragraph drifts into product narrative — the visibility/generation 'loop', app URLs, and a link list — which is longer than a 2-parameter tool strictly needs, though it is not padded 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?

With an output schema present, return values need not be described, and the description still covers everything an agent needs: the readiness precondition, the confirmation requirement, the async lifecycle and how to poll, refusal conditions, quota cost, and destructive-ish rewrite behavior. Nothing material for correct invocation 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% and both parameters are already documented in-schema, so baseline is 3; the description goes slightly further by framing confirmedByUser as a real conversational gate — the user must see the brief's title and H2/H3 outline and agree, since the outline determines what gets written. It adds little about briefId beyond the schema's own 'as create_content_brief reports 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?

Opening sentence names a specific verb (write) and resource (the article for a content brief) plus the inputs it draws on: brief title/outline, brand description, knowledge base, market language. It is immediately distinguishable from create_content_brief (orders the plan) and get_article (reads the text), both named in the body.

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?

Explicit preconditions and exclusions: call it only after get_content_brief reports `ready`; briefs that are `processing` or failed are refused; and the user must be shown the title and outline and give an explicit yes. It even pre-empts a likely mistake by stating 'a request to write an article is not that yes', and it names the sibling tools for the adjacent steps.

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

Deploy Server