Let plugins register tools for the built-in MCP server (Tier 3 of the AI sidebar spec)

Features
1

Bonjour everyone,

Thanks for the built-in MCP server in 3.7, it works well.

But the set of MCP tools is fixed. Useful additions like listing backlinks, finding orphan notes or broken links, editing a specific section of a long note,they would require changing Joplin core. The only alternative today would be running a second MCP server next to the built-in one, (extra setup, duplicated tools ).

Proposal

Implement plugin tool registration as described in the AI sidebar spec (ai_sidebar_tools.md, "Tier 3 — Plugin-registered tools") ,so plugin tools appear both in the AI sidebar and through /mcp.

In v3.7.21 and on dev, ToolIndex only contains the built-in and editor tools, and JoplinAi has no way to register tools. Since the sidebar and the MCP server already share ToolIndex, this would mostly mean adding plugin tools to it and bridging calls to the plugin sandbox.

some questions

  1. Is Tier 3 still planned, and is anyone working on it?
  2. How should plugin tools fit with the per-tool settings (e.g. ID prefixed with the plugin ID, disabled by default) ?
  3. Could a first version skip the custom render part ?

Merci!

2

What tools in particular do you think would be needed? Could you provide a list? I think we could simply add them for now as the MCP feature is quite new so it's possible it's missing essential tools

3

Thank you ! Here's my list. It's a very personal selection, based on how I use Joplin, and other Notes apps together with AI chatbots.

Related to navigation:

  1. get_links (note_id) - Outgoing links and backlinks of a note. In order to give AI the possibility to follow connections between notes having to search every time.
  2. related_notes (note_id): notes semantically similar to a given note, using the existing embeddings. This matches the "AI-generated note graphs" use case in the AI primitives spec.

improvements for long notes :

  1. Section support in read_note. Possibility to return to the note's outline (headings only), and a section parameter to read a single heading's content. This saves tokens on long notes.
  2. Section support in update_note: append or replace content under a given heading, so the AI doesn't need to resend or replace_text the whole body.

Efficiency

  1. read_notes (note_ids): read several notes in one call, to save round trips after a search.

Maintenance (lower priority)

  1. find_broken_links and find_orphan_notes: internal links pointing to missing notes, and notes with no links in or out.

A few smaller server-side suggestions, not tools:

  • Accept the token in an Authorization: Bearer header, not only in the URL.
  • Add MCP tool annotations (readOnlyHint, destructiveHint) so clients can skip confirmations for read-only tools.
  • Return compact JSON instead of pretty-printed JSON to save tokens.
  • "search_notes" loads the full body of every match before applying limit (it only needs bodies for the returned snippets), which may be slow on broad queries in large collections..

C'est tout :slight_smile:
Adding these to core would be great.

4

Thanks for the feedback, I think some of these makes sense so I've started creating a few issues for it:

Looks GitHub is falling apart at the moment so I can't add more for now, but I will later when it's back