Bug: MCP: comment, suggestion and glossary-write tools fail with "This token was granted to an MCP client and is accepted by /_mcp only"

[lukaskrawczyk]

Environment

• Wiki.js 3.0.1 Docker Container
• Built-in MCP server (Administration Area → MCP, enabled)
• Prerequisites met: API enabled, Personal Access Tokens allowed
• Token: Personal Access Token created via Profile → Personal Access Tokens → "Connect an AI Assistant", with read+write scopes on Pages, Glossary and Comments (plus the AI Assistants (MCP) scope)
• Client connected to https://<host>/_mcp over HTTP with Bearer auth

Affected tools

Tool	Result
list_comments	fails
post_comment	fails — with and without annotations
suggest_edit	fails
define_term	fails
update_term	was not testable (depends on define_term to create a term)

Working tools (same token, same session)

browse_tree, search_pages, get_page (incl. section/offset paging), list_tags, recent_changes, create_page, update_page (find-and-replace + optimistic locking), get_page_links, list_versions, get_version, diff_versions, list_terms, lookup_term

Error

Every affected call returns exactly:

This token was granted to an MCP client and is accepted by /_mcp only.

This is not a 403/permission error. The message indicates the request reached the REST API layer carrying an MCP-only token, which the REST layer correctly refuses. I.e. the built-in MCP server appears to route these specific tool calls to the REST endpoints instead of the MCP-only handler — while other tools (e.g. list_terms, lookup_term, create_page, update_page) work fine with the same token.

Steps to reproduce

1. Enable MCP, API and Personal Access Tokens (Administration Area).
2. Create a PAT via "Connect an AI Assistant" with read+write scopes on Pages, Glossary and Comments.
3. Connect an MCP client to https://<host>/_mcp.
4. Call list_comments, post_comment, suggest_edit, define_term on a page the token may read/write.
5. Observe the token-routing error above.
6. Call list_terms, lookup_term, create_page — these succeed.

[Sagargupta16]

Your reading is right, and the split in your table follows one branch in the source. The five tools that fail (list_comments, post_comment, suggest_edit, define_term, update_term) call the wiki's own REST routes in-process through backend/mcp/inject.ts, which replays your bearer token against /_api/.... Every tool that works calls the models directly. The bearer hook in backend/index.ts L672 refuses on /_api any personal token whose row carries an OAuth client, with exactly your message. So a grant token is confined to /_mcp by design (the RFC 8707 note in dev/specs/mcp.md), while inject.ts assumes a token "reaches exactly what it reaches on /_api". Those two rules collide for these five tools and nothing else. Only a code change closes it: skip the client check for injected requests, or have callApi act as the token's owner without forwarding the token.

It also tells you which token the client is sending: one issued by the wiki's OAuth flow, not the one from the create dialog. A hand-made token has no clientId, so oauthClientId is null (backend/models/personalTokens.ts L335) and that branch never runs. Profile > Personal Access Tokens shows the difference: the OAuth connection is listed under the client's name with a robot icon. Until the fix lands, put a hand-made token with the same scopes into the client as a static Authorization: Bearer header. It passes the hook, and the in-process calls reach the comment, suggestion and glossary routes.

Read from the scarlett branch at the 3.0.1 commit; not run locally.

[NGPixel]

Fixed in 3.0.2