🐛 Bug - `publish_entry` sends truncated entry ID in request URL, causing 404

[markferritto]

Describe the bug

When calling the MCP tool publish_entry with a valid full entryId (e.g. 5hEsXUrB0Gf7S6vCuQZfut), the request sent to the Contentful API uses only the first character of the ID in the URL (e.g. .../entries/5 instead of .../entries/5hEsXUrB0Gf7S6vCuQZfut). The API returns 404 and the entry is not published. The same truncation may occur when passing an array of entry IDs to the bulk publish overload.

To Reproduce

1. In Cursor (or another MCP client), use the Contentful MCP server (contentful-mcp-server) with a valid space/environment and management token.
2. Create an entry with create_entry and note the full entryId from the response.
3. Call publish_entry with that entryId (and the same spaceId and environmentId).
4. Observe the failing request (e.g. in network logs or MCP Inspector): the request URL contains only the first character of the entry ID.
5. See 404 from the API and no publish.

Expected behavior

publish_entry should send the full entryId in the request URL so the Contentful Management API can publish the correct entry.

Screenshots

If applicable, add a screenshot of the request URL or 404 response. Otherwise omit.

Environment (please complete the following information):

• OS: macOS 26.2
• Browser / client: Cursor (MCP client)
• Version: 2.4.23

Additional context

• Reproduced when using the MCP from Cursor with @contentful/mcp-server / contentful-mcp-server.
• Workaround: publish the entry in the Contentful web app using the entry’s direct link.
• Same entryId works for get_entry and update_entry; the truncation appears specific to the publish request.

[ethan-ozelius-contentful]

Hello Mark Ferritto (@markferritto), thanks for raising this issue. I'm unable to reproduce this bug, I created a new entry and was able to publish with the following steps:

1a. # Prompt I used to create a new entry of content type Author
Create a new Author entry with the following data:

name: Alex Elevante
skills: (link to existing skills entrys): gitlab "4XJ0dfg6SE8lxJb6L5xttL", microservices: "3E2mUDLhWI0PxessTLYmyK", serverless "55Z55RK0rpGlzQW63lmIXB".
bio: <generate a 4 sentence bio of an author who enjoys architecting microservices and taking hikes in their free time.>
age: 38,
photo: leave blank for now.

1b. MCP/LLM response
Successfully created the Author entry! The entry is now in Contentful as a draft with:

Name: Alex Elevante
Age: 38
Skills: Linked to gitlab, microservices, and serverless
Bio: A 4-sentence bio about architecting microservices and hiking
Picture: Left blank as requested
Entry ID: 11JCWWgFEGu2pdTVFNpZLd

The entry is currently in draft status. Would you like me to publish it?

2a. # Prompt I used to publish the newly created entry:
publish this entry: 11JCWWgFEGu2pdTVFNpZLd

2b. MCP/LLM response
Entry published successfully! The Author entry "11JCWWgFEGu2pdTVFNpZLd" for Alex Elevante is now live in Contentful.

Can you provide the prompts & MCP/LLM responses you used to reproduce this? Otherwise I'm not sure how much I'll be able to help out here.

[ethan-ozelius-contentful]

Hello Mark Ferritto (@markferritto), I hope the above feedback was helpful to you. If this issue still persists, please reopen this ticket with more context and steps to reproduce. Thank you.

[ethan-ozelius-contentful]

Reopening this ticket as we have received another report of this issue occurring. I will create an internal bug ticket to track this. After doing some very basic debugging, the team has a suspicion that this issue might be caused by the normalization that occurs in the publishEntry method, or potentially because the param schema accepts a single id (string) or a list of strings (array) and the LLM doesn't always know which is being passed.

As a workaround in the meantime, the best we can offer is to suggest very explicit prompts to an LLM to pass the entry id(s) and in what format.

Thanks for your patience while we work on this.