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

prompteye-mcp

Official

List the articles of the project

list_articles
Read-only

Every article of the project, newest first, without its text — read one with get_article. Lists the articles PromptEye wrote from a brief and the texts the team added in the app.

Instructions

Every article of the project, newest first, without its text — read one with get_article. Lists the articles PromptEye wrote from a brief and the texts the team added in the app. Briefs whose article has not been requested yet are not listed; read those with get_content_brief.

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
limitNoHow many entries to return, at most 200. Defaults to 50.
cursorNoThe nextCursor of the previous page. Omit it to start from the first one.
projectIdYesThe project to work on — its id from list_projects. Required on every call, so that parallel conversations never read or write each other's project.

Output Schema

NameRequiredDescriptionDefault
dataYes
nextCursorYesPass as cursor to read the next page. null = this was the last page.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.0.28

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already mark it read-only and open-world, but the description adds substantial behavioral detail: newest-first ordering, omission of article text, inclusion of both PromptEye-generated and app-added articles, exclusion of briefs whose article has not been requested, and caveats that generated articles are drafts not guaranteed to be cited.

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

Conciseness3/5

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

The first sentence is excellent and front-loads the core purpose. However, the description then expands into a lengthy explanation of the entire content generation loop, publishing, indexing, and two help links, which is more than a list tool needs to earn its place.

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?

An output schema exists, so return-value details need not be repeated. The description covers ordering, exclusions, text omission, and companion tools, leaving no significant gap for an agent to call list_articles correctly.

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% and all three parameters (limit, cursor, projectId) are fully documented in the schema. The description adds no parameter-specific syntax or usage beyond the schema, so the high-coverage baseline of 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 first sentence states a specific verb (lists), resource (articles of the project), ordering (newest first), and excludes text content, while routing to get_article for full text. It also distinguishes from get_content_brief for briefs not yet turned into articles.

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?

The description explicitly names alternatives and the conditions that select them: use get_article to read text, get_content_brief for unrequested briefs, create_content_brief to order one, and create_article to write from a brief. It gives a clear workflow context for when this tool is appropriate.

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