Skip to main content
Glama
prismicio

@prismicio/mcp-server

Official
by prismicio
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Remote
IMPORTANT

This package is no longer recommended for building Prismic websites with AI. Follow the new Prismic CLI-based approach instead:Build with AI in Prismic.

For Prismic content management through MCP, use Prismic’s server-side MCP server: Prismic MCP documentation.

@prismicio/mcp-server

npm version npm downloads Github Actions CI Codecov Conventional Commits License

Prismic Model Context Protocol (MCP) Server.

Install

{
	"mcpServers": {
		"prismic": {
			"command": "npx",
			"args": ["-y", "@prismicio/mcp-server@latest"]
		}
	}
}

Related MCP server: Echo MCP Server

Documentation

To discover what's new on this package check out the changelog. For full documentation, visit the official Prismic documentation.

Contributing

Whether you're helping us fix bugs, improve the docs, or spread the word, we'd love to have you as part of the Prismic developer community!

Asking a question: Open a new topic on our community forum explaining what you want to achieve / your question. Our support team will get back to you shortly.

Reporting a bug: Open an issue explaining your application's setup and the bug you're encountering.

Suggesting an improvement: Open an issue explaining your improvement or feature so we can discuss and learn more.

Submitting code changes: For small fixes, feel free to open a pull request with a description of your changes. For large changes, please first open an issue so we can discuss if and how the changes should be implemented.

For more clarity on this project and its structure you can also check out the detailed CONTRIBUTING.md document.

License

Copyright 2013-2025 Prismic <contact@prismic.io> (https://prismic.io)

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.

Available Tools

5 tools
add_slice_to_custom_typeA

PURPOSE: Adds a slice to a custom type.

USAGE: Required path for modifying Prismic slice registrations. Adds/registers/attaches a slice to a custom type and regenerates types. Do not edit custom type JSON files manually; this tool performs validation and follow-up steps.

RETURNS: A message indicating whether the slice was added to the type or not, and detailed error messages if it is not.

ParametersJSON Schema
NameRequiredDescriptionDefault
sliceMachineConfigAbsolutePathYesAbsolute path to 'slicemachine.config.json' file
sliceDirectoryAbsolutePathYesAbsolute path to the slice directory (contains 'model.json')
customTypeDirectoryAbsolutePathYesAbsolute path to the custom type directory (contains 'index.json')

TDQS

A3.5/5.0
Behavior2/5

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

No annotations are provided, so the description must fully disclose behavior. It states it 'adds/registers/attaches' and 'regenerates types', but lacks details on side effects (e.g., overwrites existing registrations), required permissions, or the validation process. The warning about manual editing is helpful, but overall transparency is minimal 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.

Conciseness5/5

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

The description is concise (3 lines) and well-structured with 'PURPOSE', 'USAGE', and 'RETURNS' sections. Every sentence adds value; no fluff or repetition. Ideal for quick comprehension.

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?

The description covers purpose, usage, and return values (message/errors). However, it omits prerequisites (e.g., slice and custom type directories must exist, valid model.json) and does not explain the 'regenerates types' effect. For a tool with 3 required params and no output schema, it is adequate but leaves some gaps.

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% (all 3 parameters have clear descriptions). The description adds no extra detail beyond the schema, so baseline 3 is appropriate. The parameters are self-explanatory from the schema alone.

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 explicitly states 'Adds a slice to a custom type'—a specific verb and resource. It also adds 'regenerates types' to clarify scope. This is direct and unambiguous, distinguishing it from sibling tools which focus on coding, mocking, or modeling slices.

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 provides a 'USAGE' section stating it is the 'Required path for modifying Prismic slice registrations' and warns against manual editing. However, it does not explicitly compare to siblings or state when not to use it (e.g., when just modeling a slice). The guidance is present but not comprehensive.

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

how_to_code_sliceA

PURPOSE: Provides slice and field implementation guidance for Prismic slice components.

USAGE: Use FIRST when working with any Prismic slice component or field implementation.

RETURNS: Prismic Framework-specific field documentation and code examples.

ParametersJSON Schema
NameRequiredDescriptionDefault
sliceMachineConfigAbsolutePathYesAbsolute path to 'slicemachine.config.json' file
projectFrameworkYesProject framework (Next.js, Nuxt, or SvelteKit)
stylingSystemYesDetected styling system in the project (e.g., 'vanilla-css', 'tailwind', 'css-modules', 'styled-components', 'emotion', 'sass'...)
modelAbsolutePathYesAbsolute path to the slice's 'model.json' file
fieldsUsedYesField types used in the slice (from 'prismicio-types.d.ts' file)

TDQS

A4/5.0
Behavior3/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 states the tool 'Provides slice and field implementation guidance' and 'RETURNS: ... documentation and code examples', implying a read-only knowledge retrieval. However, it does not explicitly confirm non-destructive behavior or disclose any side effects, which is minimal but acceptable for a guidance tool.

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: three sentences with clear labels (PURPOSE, USAGE, RETURNS). Every sentence adds value, and the structure is front-loaded. No unnecessary 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?

The tool has 5 required parameters and no output schema. The description summarizes the return value as 'Prismic Framework-specific field documentation and code examples', which is somewhat general but sufficient for a guidance tool. It could mention output format or error handling, but overall it covers the essential context.

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%, providing clear descriptions for all 5 parameters. The tool description does not add extra meaning beyond what the schema already conveys, so the baseline score 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 explicitly states it provides slice and field implementation guidance for Prismic slice components, which is a specific verb+resource. It clearly differentiates from sibling tools like 'how_to_mock_slice' (mocking) and 'how_to_model_slice' (modeling).

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 says 'Use FIRST when working with any Prismic slice component or field implementation', providing clear context and priority among siblings. It does not explicitly list when not to use or alternatives, but the instruction is direct and helpful.

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

how_to_mock_sliceA

PURPOSE: Generate a model-valid slice mock (mocks.json) and provide guidance for text-only refinements.

USAGE: Use when creating or updating slice mocks.

RETURNS: A JSON mock covering all variations, plus guidance for text-only refinements.

ParametersJSON Schema
NameRequiredDescriptionDefault
sliceMachineConfigAbsolutePathYesAbsolute path to 'slicemachine.config.json' file
sliceDirectoryAbsolutePathYesAbsolute path to the slice directory (contains model.json)
userIntentYesUser-provided guidance describing desired mock changes, tone, quantities, constraints

TDQS

A3.6/5.0
Behavior3/5

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

No annotations are provided, so the description must disclose behavior. It states it 'generate[s]' a mock and 'provide[s] guidance,' but it doesn't clarify if this is a read-only operation or if it modifies files. It also doesn't mention permissions or side effects. It's adequate but lacks depth.

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 concise with three clear sections: PURPOSE, USAGE, RETURNS. Every sentence adds value without repetition. It is front-loaded with the purpose. Slightly more detail could be added without being verbose, so not a perfect 5.

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 3 parameters, no output schema, and no annotations, the description covers the basic purpose but lacks completeness. It doesn't clarify whether the tool reads/writes files, the format of the returned JSON, or how it relates to sibling tools. More detail would be needed for full context.

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 input schema has 100% coverage with clear descriptions for each parameter (e.g., absolute paths, user intent). The tool description does not add extra meaning beyond what the schema already provides, but the schema itself is sufficient. Following the baseline rule for high coverage, a score 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 clearly states the tool's purpose: 'Generate a model-valid slice mock (mocks.json) and provide guidance for text-only refinements.' The verb 'generate' and resource 'slice mock' are specific. The sibling tools include other how-to tools (code, model), so this tool is distinct as the mocking one.

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 says 'Use when creating or updating slice mocks.' This gives a clear context but does not explicitly mention when not to use it or provide alternative sibling tools. No exclusions or comparisons are given, so it's implied but not fully guided.

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

how_to_model_sliceA

PURPOSE: Provide detailed, opinionated guidance to create or update Prismic slice model files using modern best practices, including naming, file placement, allowed fields, shapes, and configuration.

USAGE: Use FIRST for any Prismic slice creation or modeling request. Do not use for component or mock implementation. Input Type Selection Rules:

  • If the user attaches an image, include "image".

  • If the user attaches code, include "code".

  • Include "text" ONLY if the prompt contains model-related information (e.g., explicitly describes desired fields/structure, adds nuance, or overrides what is seen in the code/image).

  • It is acceptable to include multiple input types when each adds model-relevant signal per the rules above.

RETURNS: Step-by-step modeling instructions, naming conventions, final Prismic model shapes, comprehensive field shape reference, opinionated modeling guidance, validation and testing steps.

ParametersJSON Schema
NameRequiredDescriptionDefault
sliceMachineConfigAbsolutePathYesAbsolute path to 'slicemachine.config.json' file
sliceNameYesThe name of the slice, it MUST be PascalCase, e.g., 'SliceName', cannot start with a number, and with no special characters allowed
isNewSliceYesWhether this is a new slice creation (true) or updating existing slice (false)
contentRequirementsYesDescription of what content the slice should contain (e.g., 'hero with title, description, and CTA button')
inputTypesYesThe kinds of input present in the prompt.

TDQS

A4.5/5.0
Behavior4/5

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

No annotations provided, so description carries full burden. It clearly states it returns step-by-step guidance, naming conventions, shapes, etc. It does not mention side effects, but as a guidance-only tool, that's acceptable. Could be more explicit about not making changes.

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?

Well-structured with sections (PURPOSE, USAGE, Input Type Selection Rules, RETURNS) and bold headings. Concise but informative; each sentence adds value. Could be slightly more streamlined.

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 no output schema, the description covers purpose, usage, parameter guidance, and return value. It's adequate for an AI agent to select and invoke correctly. Missing only explicit mention that it does not modify anything, but implied.

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% with good descriptions. The description adds extra meaning: explains input type selection rules, gives an example for contentRequirements, and reinforces the PascalCase pattern for sliceName. This adds significant value beyond 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 purpose: providing opinionated guidance for Prismic slice model files. It specifies the resource (slice model files) and action (create or update), and distinguishes from sibling tools like how_to_code_slice and how_to_mock_slice.

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?

Explicitly states 'Use FIRST for any Prismic slice creation or modeling request' and 'Do not use for component or mock implementation.' Provides detailed input type selection rules, giving clear context on when to include each input type.

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

save_slice_dataB

PURPOSE: Creates or updates a Prismic slice model and/or mocks in your project with given valid data, performing local changes to the slice library.

USAGE: Use to validate and create/update slice data (model and/or mocks).

RETURNS: Success confirmation or detailed validation errors if the data is invalid.

ParametersJSON Schema
NameRequiredDescriptionDefault
sliceMachineConfigAbsolutePathYesAbsolute path to 'slicemachine.config.json' file
sliceAbsolutePathYesAbsolute path to the directory of the slice to be created/updated
dataYesThe data to be saved for the slice. At least one of 'model' or 'mocks' must be specified.

TDQS

B3.2/5.0
Behavior2/5

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

No annotations provided, so description carries full burden. States it performs 'local changes' and returns success/errors, but lacks details on overwrite behavior, permissions, or reversibility. Minimal disclosure.

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?

Three sentences, no fluff. Front-loaded with purpose. Concise and well-structured.

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?

Adequately covers purpose and returns, but could be more explicit about the requirement that at least one of model/mocks must be provided (schema notes it, description does not). No output schema, but return description suffices.

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% with well-described parameters. Description adds 'with given valid data' but little extra beyond schema. Baseline score appropriate.

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?

Clearly states the verb 'creates or updates' and resource 'Prismic slice model and/or mocks' with scope 'local changes to the slice library'. Does not explicitly differentiate from sibling tools like add_slice_to_custom_type, but purpose 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 Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides basic usage guidance: 'Use to validate and create/update slice data'. Does not mention when not to use or alternatives among siblings, but implication is clear.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 5 tool updatesv0.0.20
    • First observedadd_slice_to_custom_type
    • First observedhow_to_code_slice
    • First observedhow_to_mock_slice
    • First observedhow_to_model_slice
    • First observedsave_slice_data
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.8/5.0
Disambiguation5/5

Each tool targets a distinct aspect of Prismic slice work: registration, coding guidance, mocking guidance, modeling guidance, and saving model/mock data. No two tools overlap in purpose.

Naming Consistency3/5

Two naming patterns exist: 'how_to_*' for guidance tools and verb_noun for action tools (add_slice_to_custom_type, save_slice_data). While readable, the mix of patterns reduces consistency.

Tool Count5/5

Five tools is appropriate for a focused server on Prismic slice management, covering key development tasks without being excessive or insufficient.

Completeness4/5

The tool set covers the main workflows for Prismic slice development: adding to custom types, guidance for coding/mocking/modeling, and saving data. Minor gaps like missing delete or list operations are acceptable given the server's assisting role.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • Echo MCP Server

    somacaru
    F
    license
    Not graded
    quality
    D
    maintenance
    A simple demonstration MCP server that provides an echo tool and resource for learning how to build MCP servers. Serves as a starting point and template for creating custom MCP server implementations.
    1
    -

  • make-mcp

    D1DX
    A
    license
    Not graded
    quality
    F
    maintenance
    This MCP server provides integration with Make.com (formerly Integromat) for workflow automation. It is now deprecated and replaced by Make's official cloud MCP.
    110
    4
    MIT

Latest Blog Posts

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/prismicio/prismic-mcp-server'

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