Prismic Content MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool has a clearly distinct purpose targeting specific Prismic resources and operations. The naming convention (prismic_ + verb + noun) combined with detailed descriptions eliminates ambiguity between similar-sounding tools like prismic_get_document vs prismic_get_documents or prismic_insert_custom_type vs prismic_update_custom_type.
Naming Consistency5/5
All tools follow a perfect prismic_verb_noun pattern with consistent snake_case throughout. The naming is predictable and systematic, making it easy to understand what each tool does based on its name alone.
Tool Count4/5
With 18 tools, the count is slightly high but reasonable for a comprehensive content management system interface. The tools cover multiple domains (documents, custom types, shared slices, media, refs, releases) which justifies the number, though some consolidation might be possible.
Completeness5/5
The toolset provides complete CRUD coverage for all major Prismic entities: documents (get, list, upsert), custom types (get, list, insert, update), shared slices (get, list, insert, update), media (add, list), plus essential supporting operations for refs, releases, and repository context. There are no obvious gaps for content management workflows.
Average 4.1/5 across 18 of 18 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action is an insertion but doesn't cover permissions, side effects, error handling, or response behavior. The mention of the API endpoint adds minimal context, leaving significant gaps in understanding how the tool behaves.
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 brief and front-loaded with the main action, using two sentences efficiently. However, the second sentence could be more structured, and some information (like the API endpoint) might be redundant if not contextualized, slightly reducing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, the description doesn't need to explain return values. However, with no annotations, 0% schema coverage, and a mutation operation, the description is incomplete—it lacks behavioral details, usage context, and full parameter guidance, making it only minimally adequate.
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 0%, so the description must compensate. It specifies that the parameter should be a 'full Custom Type JSON model' and lists some fields ('id', 'label', 'repeatable', 'json tabs/fields'), adding meaning beyond the generic schema. However, it doesn't fully detail all required properties or constraints, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Insert a new Custom Type model') and the resource ('Custom Type'), making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'prismic_update_custom_type' or 'prismic_insert_shared_slice', which would require more specific context about when to use each.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'prismic_update_custom_type' or 'prismic_insert_shared_slice'. It mentions the API endpoint but doesn't clarify prerequisites, dependencies, or typical scenarios for insertion versus update operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but provides minimal behavioral insight. It mentions the HTTP method ('POST') and that a 'full JSON model' is required, but lacks details on permissions, side effects, error handling, or response format, which are critical for a mutation tool.
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 brief and front-loaded with the main action, using three sentences efficiently. However, the second sentence about the HTTP method could be integrated more smoothly, and some redundancy exists between 'Insert' and 'POST'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (mutation with nested objects) and lack of annotations, the description is incomplete. It mentions the output schema exists but doesn't explain return values or error cases. For a creation tool, more context on success/failure outcomes is needed.
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 0%, but the description adds some value by specifying 'Pass a full Shared Slice JSON model', clarifying the parameter's purpose. However, it doesn't detail the JSON structure, required fields, or examples, leaving significant gaps in understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Insert') and resource ('Shared Slice model'), making the purpose understandable. It distinguishes from siblings like 'prismic_update_shared_slice' by specifying 'new', but doesn't explicitly contrast with all alternatives like 'prismic_get_shared_slice'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. While 'new' implies creation rather than updating, there's no mention of prerequisites, constraints, or specific scenarios for insertion versus other operations like 'prismic_insert_custom_type'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but provides minimal behavioral insight. It states the tool updates a model and uses a POST endpoint, but doesn't disclose permissions, side effects, rate limits, or response format. This is inadequate for a mutation tool with zero annotation coverage.
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 brief and front-loaded, with two sentences that directly state the action and parameter. There's no wasted text, but it could be more structured with bullet points or examples for better clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given complexity (mutation tool with nested objects) and no annotations, the description is incomplete. It mentions the output schema exists but doesn't explain return values or error handling. For a tool updating a shared slice, more context on behavior and parameters is needed.
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 0%, so the description must compensate. It adds that the parameter is 'the full updated Shared Slice JSON model', giving basic semantics beyond the schema's generic object type. However, it doesn't detail structure, fields, or constraints, leaving significant gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and resource ('existing Shared Slice model'), making the purpose evident. It distinguishes from siblings like 'prismic_insert_shared_slice' by specifying 'existing' versus creation, though it doesn't explicitly name alternatives. This is specific but could be more distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It mentions the HTTP method ('POST /slices/update') but doesn't clarify prerequisites, such as needing an existing slice, or contrast with tools like 'prismic_update_custom_type'. Usage is implied by the action but lacks explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the HTTP method ('GET'), implying a read-only operation, but lacks details on authentication needs, rate limits, error handling, or what happens if the ID is invalid. This is a significant gap for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, with two sentences that directly state the purpose and HTTP method. There is zero waste or redundancy, making it efficient and easy to parse for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter) and the presence of an output schema, the description is somewhat complete but lacks depth. It covers the basic action and method but misses behavioral context (e.g., permissions, errors) and usage guidelines. With no annotations, it should do more to compensate, but the output schema reduces the need to explain return values.
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?
The description adds minimal meaning beyond the input schema, which has 0% description coverage. It implies 'slice_id' is used to fetch a specific shared slice, but doesn't clarify format, constraints, or examples. With one parameter and an output schema present, the baseline is 3, as the schema handles structure, but the description doesn't compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('one Shared Slice model by ID'), making the purpose specific and understandable. It distinguishes from sibling 'prismic_get_shared_slices' (plural) by specifying retrieval of a single item, though it doesn't explicitly contrast with other siblings like 'prismic_insert_shared_slice' or 'prismic_update_shared_slice'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a valid slice ID), exclusions, or comparisons to siblings like 'prismic_get_shared_slices' for multiple slices or 'prismic_get_document' for documents. The description only states what it does, not when to apply it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states this is a list operation and mentions the API endpoint, but doesn't disclose important behavioral traits: whether this requires authentication, rate limits, pagination behavior, error conditions, or what format the output takes. The description is minimal and leaves critical operational context unspecified.
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 appropriately concise with two short sentences. The first sentence states the purpose clearly, and the second provides implementation detail. There's no wasted text, though the structure could be slightly improved by integrating the API endpoint information more naturally with the purpose statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a read operation (implied by 'List') with 0 parameters and an output schema exists, the description is minimally adequate. However, with no annotations and multiple sibling tools, it should provide more context about when to use it and what behavioral constraints exist. The presence of an output schema means return values are documented elsewhere, but operational context is lacking.
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 tool has 0 parameters with 100% schema description coverage. The description doesn't need to explain parameters, and it appropriately doesn't mention any. The baseline for 0 parameters is 4, and the description doesn't incorrectly suggest parameters exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List all Shared Slice models from Prismic Custom Types API.' This specifies the verb ('List'), resource ('Shared Slice models'), and source ('Prismic Custom Types API'). However, it doesn't explicitly differentiate from sibling tools like 'prismic_get_shared_slice' (singular) or 'prismic_get_types', which might have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With multiple sibling tools like 'prismic_get_shared_slice' (singular) and 'prismic_get_types', there's no indication of when this list-all operation is appropriate versus more specific queries. The mention of 'Uses GET /slices' is technical implementation detail, not usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It usefully specifies the HTTP method (GET), endpoint, and environment variable requirements, which are important for usage. However, it lacks details on rate limits, error handling, authentication scope, or what 'full Custom Type models' entails in terms of data returned.
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 well-structured and front-loaded with the core purpose. The additional details about the API endpoint and requirements are necessary and efficiently presented. It could be slightly more concise by integrating the requirements more seamlessly, but overall it avoids unnecessary verbosity.
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?
Given the tool has 0 parameters, 100% schema coverage, and an output schema exists, the description provides adequate context. It covers the action, API specifics, and prerequisites. The presence of an output schema means return values don't need explanation, making this description reasonably complete for a simple listing operation.
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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately focuses on operational context without redundant parameter explanations, earning a baseline score of 4 for effectively handling a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List full Custom Type models') and the resource ('from Prismic Custom Types API'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'prismic_get_types' or 'prismic_get_custom_type', which reduces clarity about when to choose this particular listing tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions the API endpoint and requirements but doesn't explain scenarios where listing all custom types is appropriate compared to getting a single custom type or other related operations available in the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It mentions the HTTP method (POST) and implies this is a mutation operation. However, it doesn't disclose important behavioral traits like authentication requirements, rate limits, error conditions, or what happens to existing data. The typical sequence is helpful but doesn't fully compensate for missing behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and efficiently written. The first sentence states the core purpose, followed by technical details (HTTP endpoint), then practical guidance (typical sequence). Every sentence serves a clear purpose with zero wasted words. The bullet-point sequence is particularly effective for readability.
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?
Given this is a mutation tool with no annotations, 1 parameter (0% schema coverage), nested objects, and an output schema exists, the description does reasonably well. It explains the parameter's purpose and provides a usage sequence. However, for a mutation operation, it should ideally mention permissions, side effects, or validation rules. The output schema reduces the need to describe return values.
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 0%, so the description must compensate. It clarifies that the 'custom_type' parameter should contain 'the full updated Custom Type JSON model' and references getting the model first via 'prismic_get_custom_type'. This adds meaningful context beyond the bare schema, but doesn't explain the structure or required fields of the JSON model. Baseline would be lower without this guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Update') and resource ('Custom Type model'), making the purpose immediately understandable. It distinguishes from siblings like 'prismic_insert_custom_type' (create new) and 'prismic_get_custom_type' (read). However, it doesn't specify what aspects of the model can be updated or the scope of changes.
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 provides explicit guidance on when to use this tool through a typical sequence (get → edit → update → verify). It clearly distinguishes from 'prismic_insert_custom_type' by specifying this is for updating existing models, not creating new ones. The sequence provides practical context for proper usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively communicates that this is a read operation ('List'), maps to a specific API endpoint, and discloses authentication requirements (PRISMIC_REPOSITORY and PRISMIC_WRITE_API_TOKEN). It doesn't mention rate limits, pagination behavior beyond cursor usage, or error conditions, but provides solid foundational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly front-loaded with the core purpose in the first sentence, followed by essential implementation details. Every sentence earns its place: the first establishes what the tool does, the second maps parameters to the API, and the third states authentication requirements. No wasted words or redundancy.
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 read operation with 4 parameters and an output schema (which handles return values), the description provides good context: purpose, parameter mapping, and authentication. It doesn't mention pagination strategy (cursor usage) or potential response formats, but with an output schema available, those details are less critical. The main gap is lack of error handling or rate limit information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Given 0% schema description coverage (titles like 'Asset Type' and 'Limit' provide minimal semantic value), the description adds crucial meaning by explicitly naming all four parameters (assetType, limit, cursor, keyword) and clarifying they map directly to GET /assets query parameters. This transforms completely undocumented parameters into well-understood API arguments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List media assets') and resource ('from Prismic Asset API'), making the purpose immediately understandable. It distinguishes this tool from siblings like prismic_add_media (which creates rather than lists) and prismic_get_document (which fetches documents rather than media assets). However, it doesn't explicitly contrast with all similar retrieval tools like prismic_get_custom_types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning it maps to GET /assets and requires specific credentials, suggesting when authentication is needed. However, it doesn't provide explicit guidance on when to use this tool versus alternatives like prismic_get_documents or prismic_get_shared_slices, nor does it mention any exclusions or prerequisites beyond the credentials.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure and does so effectively. It explains security constraints (PRISMIC_UPLOAD_ROOT requirement, path traversal blocking), authentication needs (specific environment variables), and technical implementation details (multipart/form-data, POST /assets). It doesn't mention rate limits or error handling, but covers essential operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with zero wasted sentences. It front-loads the core purpose, then provides implementation details, prerequisites, and security constraints in a logical flow. Each sentence adds essential information without redundancy.
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?
Given the complexity of a media upload operation with security constraints, no annotations, and an output schema present, the description is quite complete. It covers purpose, implementation, prerequisites, and security. The output schema likely handles return values, so the description appropriately focuses on operational context rather than response format.
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?
With 0% schema description coverage, the description must compensate and does so well for most parameters. It explains that 'file_path' is uploaded, and that 'notes', 'credits', and 'alt' are optional metadata mapping to Asset API fields. However, it doesn't provide format expectations or constraints for these string parameters beyond their purpose.
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 clearly states the specific action ('Upload media via Prismic Asset API') and resource ('file_path'), distinguishing it from sibling tools that primarily retrieve or manage documents, custom types, and slices rather than uploading media assets. It provides concrete technical details about the API endpoint and method.
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 provides clear context for when to use this tool (uploading media assets) and mentions prerequisites (environment variables like PRISMIC_REPOSITORY and PRISMIC_WRITE_API_TOKEN). However, it doesn't explicitly contrast with alternatives or state when not to use it compared to sibling tools like prismic_get_media or document management tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing critical behavioral traits: it writes to Migration workflow, documents may not be visible via Content API until release/publish, and supports dry_run and fail_fast for safer execution. It doesn't mention rate limits or authentication requirements, but covers key operational constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement followed by an 'Important behavior' section. Every sentence adds value: the first states the core function, and subsequent sentences explain workflow implications, read-back alternatives, and safety features. No wasted words.
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?
Given the tool's complexity (batch write operation with 3 parameters, no annotations, but with output schema), the description is mostly complete. It covers purpose, usage context, and key behaviors, but lacks details on authentication, error handling, or response format, though some of this may be in the output schema.
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 description coverage is 0%, so the description must compensate. It mentions dry_run and fail_fast parameters, explaining they are 'for safer execution,' which adds useful context beyond the schema's titles. However, it doesn't detail the documents array structure or DocumentWrite model, leaving some parameter semantics undocumented.
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 clearly states the tool performs 'Batch create/update documents in the Prismic Migration API,' specifying both the action (create/update) and resource (documents) with the batch qualifier. It distinguishes from sibling tools like prismic_upsert_document (singular) and prismic_get_documents (read-only).
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 provides explicit guidance on when to use alternatives: it states that for read-back before publish, use read tools with a release ref and PRISMIC_CONTENT_API_TOKEN. It also clarifies this writes to the Migration workflow, not directly to the Content API, helping differentiate from other write operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the HTTP method ('GET /customtypes/{id}'), which implies a read-only operation, and details what is returned when 'include_schema_summary=true' (e.g., tab/field breakdown, field config). However, it doesn't mention error conditions, rate limits, or authentication needs, which are gaps for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose. Each sentence adds value: the first states the action, the second specifies the API endpoint, the third details the schema summary output, and the fourth provides usage guidelines. There is no wasted text, and it's appropriately sized for the tool's complexity.
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 the tool has an output schema (which handles return values), no annotations, and low schema coverage, the description is complete enough. It covers the purpose, usage context, behavioral details (HTTP method and output specifics), and parameter semantics for one parameter. The gaps in behavioral transparency and parameter semantics are mitigated by the output schema and the tool's relative simplicity.
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 description coverage is 0%, so the description must compensate. It explains the purpose of 'include_schema_summary=true' in detail, adding meaning beyond the schema's boolean type. However, it doesn't clarify the 'custom_type_id' parameter (e.g., format or source), leaving some semantic gaps. The description partially compensates but not fully.
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 clearly states the specific action ('Get one Custom Type model and schema summary by ID'), identifies the resource ('Custom Type'), and distinguishes it from sibling tools like 'prismic_get_custom_types' (plural) which likely lists multiple types. The verb 'Get' is precise and the scope is well-defined.
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 states when to use this tool: 'This is the recommended verification call after create/update operations.' It distinguishes it from other tools by specifying it retrieves a single custom type by ID, unlike 'prismic_get_custom_types' which likely lists multiple types. This provides clear context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively explains key behaviors: the need for PRISMIC_CONTENT_API_TOKEN for non-master refs, the absence of a status field in the payload, and the multi-step process to determine publish state. However, it doesn't mention error handling, rate limits, or authentication requirements beyond the token note.
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 well-structured and front-loaded with the core purpose, followed by detailed usage notes. While comprehensive, some sentences could be tightened (e.g., the multi-step sequence is verbose but necessary). Overall, it earns its length with valuable information.
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 the complexity (5 parameters, 0% schema coverage, no annotations, but with output schema), the description is highly complete. It covers purpose, usage guidelines, parameter semantics, and behavioral nuances like authentication and publish state determination. The output schema handles return values, so no need to explain them here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for all parameters. It explains the purpose of id, type, uid, and ref parameters, including that ref is for 'specific preview/release version pointer.' It also implies lang is for language, though less explicitly. This adds significant meaning beyond the bare schema.
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 clearly states the tool's purpose: 'Get one document by id or by type+uid with optional explicit ref.' It specifies the exact action (get), resource (document), and two identification methods, distinguishing it from sibling tools like prismic_get_documents (which retrieves multiple documents).
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 provides explicit guidance on when to use this tool: 'Prefer this over prismic_get_documents when you already have an exact id or type+uid target.' It also explains when to use the ref parameter for preview/release versions and outlines a multi-step sequence for determining publish state, offering clear alternatives and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well: it explains authentication needs ('may require PRISMIC_CONTENT_API_TOKEN'), efficiency considerations, pagination behavior, and important limitations ('no documented Content API q predicate for published status'). It doesn't cover rate limits or error handling, but provides substantial operational context.
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 well-structured with clear sections: parameter explanations, important notes, efficiency tips, and implementation guidance. While comprehensive, some sentences could be more concise (e.g., the Codex js_repl tip feels slightly out of place). Overall, most content earns 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?
Given the complexity (8 parameters, 0% schema coverage, no annotations) and presence of an output schema, the description is remarkably complete. It covers all parameters, provides operational context, efficiency tips, sibling tool relationships, authentication considerations, and implementation notes. The output schema existence means return values don't need explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for 8 parameters, the description fully compensates by explaining every parameter's purpose: ref (content ref selection), q (predicate filtering), type (convenience shortcut), orderings (sorting), routes (URL population), page/page_size (pagination). It provides concrete examples and usage patterns for each.
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 starts with 'List documents with optional Prismic predicate filtering' - a specific verb ('List') and resource ('documents') with clear scope ('Prismic predicate filtering'). It distinguishes from siblings like prismic_get_document (singular) and prismic_upsert_document (write operation).
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 provides explicit guidance on when to use alternatives: 'call prismic_get_refs once and pass ref explicitly' for large scans, and mentions sibling tools like prismic_get_refs. It also gives clear context about when to use certain parameters like 'Only pass routes when you need populated url fields.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's behavior: it returns refs for use with other tools, implies it's a read operation (consistent with 'Get'), and includes an efficiency tip about caching to optimize performance. However, it doesn't mention potential errors, rate limits, or authentication needs, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and concise, with three focused paragraphs: the first states the purpose, the second clarifies what refs are and links to siblings, and the third provides an efficiency tip. Every sentence adds value without waste, and it's front-loaded with key information.
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 the tool's simplicity (0 parameters, no annotations, but has an output schema), the description is complete. It explains what the tool does, how to use the output, and includes performance advice. With an output schema present, it doesn't need to detail return values, making this description fully adequate for the context.
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 tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description appropriately focuses on the tool's purpose and usage without redundant parameter details, earning a baseline score of 4 for zero-parameter tools.
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 clearly states the specific action ('Get repository refs from Content API root') and distinguishes it from siblings by explaining what refs are (repository-level version pointers) and what they are not (per-document refs). It uses precise terminology like 'master', 'preview', or 'release refs' to clarify scope.
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 states when to use this tool (to get refs for version pointers) and how to use the output with sibling tools like 'prismic_get_documents' or 'prismic_get_document'. It also provides an efficiency tip on caching the ref to avoid per-call resolution, offering clear operational guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well by disclosing key behavioral traits: it's a read-only operation (implied by 'Get' and usage with 'read tools'), returns a filtered subset of refs, and clarifies that querying with release refs returns a content snapshot (not just planned items). It also provides an efficiency tip. However, it doesn't mention potential errors, rate limits, or authentication needs, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by clarifications and usage tips in a logical flow. Every sentence adds value: the first states what it does, the second clarifies the output, the third explains usage, the fourth warns about content interpretation, and the fifth provides an efficiency tip. No wasted words.
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 the tool's complexity (simple read operation with 0 parameters), no annotations, and the presence of an output schema (which handles return values), the description is complete enough. It covers purpose, output filtering, usage context, behavioral nuances (content snapshot vs. planned items), and efficiency advice, leaving no significant gaps for the agent.
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 tool has 0 parameters, with 100% schema description coverage. The description adds no parameter information, which is appropriate. A baseline of 4 is applied for zero-parameter tools, as there's no need to compensate for schema gaps, and the description focuses on usage context instead.
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 clearly states the specific action ('Get release refs'), resource ('from Content API root'), and scope ('non-master refs only'), distinguishing it from sibling tools like prismic_get_refs (which presumably includes master refs). It provides a precise technical equivalent ('filtering repository refs by `isMasterRef != true`).
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 states when to use this tool ('Use these refs with read tools (`ref` parameter) to inspect release content through Content API') and provides an efficiency tip for reuse. It implicitly distinguishes from alternatives by specifying it returns 'non-master refs only,' contrasting with tools that might handle master refs or other content types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's behavior: it returns metadata (not secrets), serves as a session initialization step, and helps confirm repository and auth posture. However, it lacks details on potential errors, response format, or any side effects, though these are mitigated by the presence of an output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: the first sentence states the purpose, the second clarifies the return value, and the third provides usage guidelines. Each sentence adds clear value without any wasted words, making it easy to parse and understand quickly.
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 the tool's simplicity (0 parameters, no annotations, but with an output schema), the description is complete. It explains what the tool does, why to use it, and what to expect, covering all necessary context for an agent to invoke it correctly. The output schema will handle return value details, so no additional explanation is needed.
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 tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description appropriately focuses on the tool's purpose and usage without redundant parameter details, earning a high baseline score for this dimension.
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 clearly states the specific action ('Get active repository context') and resource ('for this MCP server'), distinguishing it from sibling tools that perform CRUD operations on documents, types, slices, etc. It explicitly mentions what is returned ('repository and API base URL metadata') and what is not ('no secrets'), making the purpose unambiguous.
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 provides explicit guidance on when to use this tool: 'Recommended first call in a session to confirm repository and auth posture before running read/write workflows.' This clearly positions it as an initialization step distinct from the operational sibling tools, with a specific rationale for its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that it returns 'normalized entries with `id` and `label`' and suggests 'call once' (implying it's a read-only, non-destructive operation that can be cached). However, it doesn't mention potential rate limits, authentication needs, or error handling, leaving some behavioral aspects unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by return details and usage sequencing. Every sentence adds value: the first states what it does, the second specifies the output format, and the third provides practical guidance. No wasted words, and structure is logical for tool understanding.
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 0 parameters, no annotations, but an output schema exists (so return values are documented elsewhere), the description is complete enough. It covers purpose, output semantics, and usage context, which is sufficient for a simple read operation. No gaps are evident for this level of complexity.
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?
There are 0 parameters, and schema description coverage is 100% (though schema is empty). The description doesn't need to explain parameters, but it implicitly confirms no inputs are required by not mentioning any. Baseline for 0 params is 4, as it appropriately avoids redundant parameter details.
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 clearly states the action ('Get repository custom types') and resource ('from Content API root'), specifying it returns 'content type metadata from the Content API `types` map as normalized entries with `id` and `label`.' It distinguishes from siblings like `prismic_get_custom_type` (singular) and `prismic_get_custom_types` (plural, but likely similar) by focusing on the API root and normalized metadata.
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 explicitly provides usage guidance: 'Typical sequencing: call once, then iterate type ids with `prismic_get_documents(type=..., page_size=1)` when you only need counts or existence checks.' This tells when to use it (for initial type retrieval) and how to combine with a sibling tool (`prismic_get_documents`) for follow-up actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. It does this exceptionally well by explaining: 1) This writes to the Migration workflow, 2) New/updated documents may not be immediately visible via Content API, 3) How to read back migrated content before publish, and 4) The dry_run option for validation. This covers critical behavioral aspects including write operations, visibility delays, and safety mechanisms.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly structured and concise. It starts with the core purpose, then provides 'Important behavior' in bullet points, each addressing critical information. Every sentence earns its place by adding essential context about the tool's behavior, limitations, and usage patterns. No wasted words or redundant information.
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 that this is a write operation with no annotations, 2 parameters (one complex nested object), and an output schema exists, the description provides excellent contextual completeness. It explains the write behavior, visibility constraints, how to work with the migration workflow, and includes safety guidance. The presence of an output schema means the description doesn't need to explain return values, allowing it to focus on behavioral context.
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?
With 0% schema description coverage, the description must compensate for the lack of parameter documentation. It mentions the 'dry_run' parameter and explains its purpose ('to validate payload/endpoint choice without writing'), which adds valuable semantic context. However, it doesn't describe the 'document' parameter or its structure, leaving the agent to rely solely on the schema for understanding this complex nested object.
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 clearly states the tool's purpose: 'Create/update one document in the Prismic Migration API.' It specifies the exact action (create/update), the resource (document), and the target system (Prismic Migration API). This distinguishes it from sibling tools like prismic_get_document (read) and prismic_upsert_documents (plural).
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 provides explicit guidance on when to use this tool versus alternatives. It explains that writes go to the Migration workflow, not directly to the Content API, and specifies how to read back migrated content before publishing (using prismic_get_releases/prismic_get_refs). It also mentions the dry_run parameter for validation without writing, which helps the agent understand when to use this mode.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![prismic-content-mcp MCP server](https://glama.ai/mcp/servers/rahulpowar/prismic-content-mcp/badges/card.svg)](https://glama.ai/mcp/servers/rahulpowar/prismic-content-mcp)

Score Badge

Copy to your README.md:

[![prismic-content-mcp MCP server](https://glama.ai/mcp/servers/rahulpowar/prismic-content-mcp/badges/score.svg)](https://glama.ai/mcp/servers/rahulpowar/prismic-content-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/rahulpowar/prismic-content-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server