prompteye-mcp

Official

by PROMPTEYE-SP-Z-O-O

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

Read one article

get_article

Read-only

Instructions

One article with its full text in Markdown. Call this after create_article until status is no longer processing: draft means the text is written and in content, error means generation failed — error says why. content is empty while it is processing. ready, published and tracked are later steps of a written article: ready means the team approved it for publishing in the app, and its text is in content as well.

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

Name	Required	Description	Default
`articleId`	Yes	Id of the article, as create_article or list_articles reports it.

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

Behavior5/5

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

Annotations already establish readOnlyHint and openWorldHint, but the description adds substantial behavioral context: the status lifecycle, that content is empty while processing, that error explains failure, and that draft and ready both place text in content. This is well beyond what the annotations provide and directly affects how the agent should interpret the result.

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 sentences are front-loaded and useful, especially the status semantics and create_article polling guidance. However, much of the description is broad product workflow about content briefs, publishing, indexing, citations, and guides that does not help an agent select or invoke get_article specifically.

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?

Given a simple one-parameter read tool with an output schema and read-only annotations, the description is more than complete. It covers what is returned, the status meanings, and how this tool fits into the surrounding article workflow.

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 description coverage is 100%, and the single articleId parameter is already documented in the schema as coming from create_article or list_articles. The description does not add meaningful syntax or format detail beyond the schema, so the baseline of 3 is appropriate.

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: reading one article with its full text in Markdown. It explicitly distinguishes the tool from create_article and list_articles, so an agent can tell which sibling reads a single article versus creating or listing them.

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 a direct usage rule: call after create_article until status is no longer processing. It also routes the agent among create_content_brief, get_content_brief, create_article, list_articles, and publish_article, making the when-to-use context explicit.

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

Deploy Server