Skip to main content
Glama

get_persona_brief

get_persona_brief

Read an AI persona and brand voice brief, poll until it is done

Returns the brief started by POST /api/v1/tools/persona-brief. While status is pending, fetching, analyzing or synthesizing, call again every 3 seconds: progress and pages show what has been read so far. When status is done, brief holds the structured brief, brief.writingPrompt the ready-to-paste prompt and markdown the full document. When status is failed, failureReason says why (NO_USABLE_PAGE, LLM_UNAVAILABLE, TIMEOUT, INTERNAL).

A page with a failureReason did not contribute to the brief. ANALYSIS_FAILED is the only one on a page that was read: it keeps its title and wordCount, stays counted in progress.pagesFetched and never enters progress.pagesAnalyzed nor metrics.

No quota is consumed. The briefId is random: whoever holds it can read the brief, which is what makes share links work. Briefs expire after 90 days. Reads that are not attributed to an account are subject to three anti-abuse counters, all per IP address and per UTC day: the total number of requests, the reads of a single brief, and the number of different briefs read. All three are far above any legitimate polling, including the busiest paid account: crossing any of them returns 429 READ_RATE_LIMITED with Retry-After. Once the cost ceiling is reached, further requests keep being refused until it resets, whether or not they carry a valid briefId.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
briefIdYesThe briefId returned by the creation call (22 characters).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations provided, the description carries the full behavioral burden and does so thoroughly. It discloses status transitions, page-level failure semantics, quota consumption, brief expiration, anti-abuse rate limits, and the 429 response with Retry-After, giving the agent a complete model of the tool's side effects and constraints.

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?

The description is longer than average, but it earns its length by covering a genuinely complex polling and failure model in a structured, front-loaded way. The first sentence states the action and polling requirement, and the following paragraphs are organized by statuses, failure behavior, and rate limits.

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?

The tool is complex and has no output schema, so the description must explain return values and behaviors on its own. It does so completely by covering the progress fields, final brief fields, failure reasons, page-level exceptions, expiration, quota, and rate-limit responses. An agent has enough information to poll correctly and handle all documented outcomes.

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?

The schema already documents the single briefId parameter at 100% coverage, including its 22-character format. The description adds substantial meaning by explaining that briefId is random, that anyone holding it can read the brief, and that this enables share links and also exposes the brief to anti-abuse counters.

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 opens by naming the specific operation: reading an AI persona and brand voice brief and polling until it is done. It clearly distinguishes this read/poll tool from related creation and discovery tools in the sibling list, such as create_persona_brief and discover_persona_brief_pages.

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?

The description gives explicit polling guidance: call again every 3 seconds while status is pending, fetching, analyzing, or synthesizing, and stop when done or failed. It does not explicitly name alternative tools or exclusions, but it provides clear operational context for when and how to use the tool.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources