Skip to main content
Glama

prismic_get_types

Retrieve custom content type metadata from Prismic's Content API to identify available document structures and their labels for content management workflows.

Instructions

Get repository custom types from Content API root.

Returns content type metadata from the Content API types map as normalized entries with id and label. Typical sequencing: call once, then iterate type ids with prismic_get_documents(type=..., page_size=1) when you only need counts or existence checks.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Implementation Reference

  • The handler function that executes the logic to fetch content types from the Prismic API.
    async def handle_prismic_get_types(
        *,
        service_factory: ServiceFactory = _build_service,
    ) -> dict[str, Any]:
        """Return repository custom types from Prismic Content API root (`/api/v2`)."""
    
        async with service_factory() as service:
            types = await service.get_types()
    
        return {"types": types}
  • The MCP tool registration for 'prismic_get_types'.
    @server.tool(name="prismic_get_types")
    async def prismic_get_types() -> dict[str, Any]:
        """Get repository custom types from Content API root.
    
        Returns content type metadata from the Content API `types` map as
        normalized entries with `id` and `label`.
        Typical sequencing: call once, then iterate type ids with
        `prismic_get_documents(type=..., page_size=1)` when you only need counts
        or existence checks.
        """
    
        return await handle_prismic_get_types()
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.

Install Server

Other Tools

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/rahulpowar/prismic-content-mcp'

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