Honeyfield Marketing MCP

Strapi: Get entry

strapi_get_entry

Read-only

Einen einzelnen Strapi-Eintrag abrufen. entry_id ist bei v4 die numerische id, bei v5 die documentId. locale wählt die Sprachversion (Strapi-v5-i18n, z. B. 'de'; ohne Angabe die Default-Locale). populate lädt Relationen und Medien mit: '' genau eine Ebene tief (Sektionen einer Dynamic Zone kommen mit, Medien und Repeatables INNERHALB der Sektionen fehlen), 'cover' oder 'cover,seo' gezielt. Tiefes Populate als Dict wie in der Strapi-Doku, z. B. populate={"content": {"populate": ""}} (entspricht populate[content][populate]=) — lädt jede Sektion einer Dynamic Zone eine Ebene tief (Medien, Relationen und Repeatables direkt in der Sektion); für Medien innerhalb von Repeatables tiefer verschachteln, z. B. per on-Strategie je Komponente populate={"content": {"on": {"sections.faq": {"populate": {"items": {"populate": ""}}}}}}. Vor dem Zurückschreiben per strapi_update_entry prüfen, dass alle Medien der Sektionen im GET enthalten sind. Der fertige Query-String 'populate[content][populate]=*' oder das Dict als JSON-String gehen ebenfalls. status wählt bei v5 die Version: 'draft' oder 'published'. Ohne status liefert v5 die VERÖFFENTLICHTE Version: ein noch nie publizierter Draft ergibt dann {"error": "http_error", "status": 404}, ein geänderter Draft erscheint als unveränderte Live-Version. Drafts nach create/update deshalb mit status='draft' zurücklesen (status wirkt nur bei v5; v4 ignoriert ihn). Single Types (z. B. 'impressum', 'footer'): Singular-API-ID als collection; der Server spricht sie automatisch über ihre ID-lose Route an. entry_id wird dabei NICHT geprüft (ein Single Type hat nur ein Dokument) — die documentId aus dem Lesen mitgeben, sie dient nur als Platzhalter. collection: API-ID der Collection (Buchstaben, Ziffern, _ und -; keine Plugin-Routen wie users, upload, admin), sonst {"error":"invalid_collection"}. entry_id: documentId bzw. numerische ID (Buchstaben, Ziffern, _ und -), sonst {"error":"invalid_id"}. workspace: Slug des Kunden-Workspace (optional bei nur einem Workspace).

Input Schema

Name	Required	Description	Default
`locale`	No
`status`	No
`entry_id`	Yes
`populate`	No
`workspace`	No
`collection`	Yes

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 31, 2026

TDQS

A4.7/5.0

Behavior5/5

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

The description adds substantial behavior beyond the readOnlyHint and openWorldHint annotations, including v4 versus v5 ID semantics, locale behavior, populate depth, default published-version behavior, draft 404 outcomes, single-type handling, and validation errors. This is unusually transparent for a read 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 purpose is front-loaded and the detail is largely justified by the tool's complexity and the lack of schema descriptions. Still, the text is dense and could be more scannable, with long sentences and parenthetical examples that make it heavier than necessary.

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 0% schema description coverage, six parameters, and version-specific behavior, the description is complete enough to call the tool correctly. It also benefits from an existing output schema, so it does not need to describe return values in detail.

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 carry the full parameter burden, and it does: collection, entry_id, locale, populate, status, and workspace are all explained with formats, version-specific behavior, allowed values, and edge cases. It adds meaningful semantics far beyond the raw 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 states a specific verb and resource: retrieving a single Strapi entry. The singular scope clearly distinguishes it from sibling tools such as strapi_list_entries, strapi_create_entry, and strapi_update_entry.

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?

It gives strong conditional guidance, especially for reading drafts after create/update with status='draft' and for checking media before using strapi_update_entry. However, it does not explicitly say when to use this tool versus strapi_list_entries or other retrieval alternatives.

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

All Honeyfield Marketing MCP tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?