Add MCP tool annotations (readOnlyHint/destructiveHint/idempotentHint) for enterprise auto-approval policies

[chrisfriedline-benchling]

Right now the built-in MCP server (/mcp/) registers all its tools with no annotations. That means enterprise MCP client policies (Claude Code, Claude Desktop team policies, etc) that auto-approve tool calls based on the standard MCP tool annotations (readOnlyHint, destructiveHint, idempotentHint, openWorldHint) can't do that here. Every call needs manual approval, even safe read-only ones like vault_list or vault_read.

Want to propose annotating all 16 built-in tools with accurate hints:

• vault_list, vault_read, vault_get_document_map, search_query, search_simple, tag_list, command_list, active_file_get_path → readOnlyHint: true
• vault_write, vault_patch, vault_delete, vault_move, command_execute → destructiveHint: true
• vault_append, periodic_note_get_path, open_file → non-destructive write hints (idempotentHint set on periodic_note_get_path and open_file, since a repeat call is a no-op)
• openWorldHint: false across the board, since none of these leave the local vault

Have a working implementation with passing tests locally, happy to open a PR if this is a direction y'all want.

One thing worth flagging first: vault_patch supports append/prepend/replace, but annotations are static per-tool (set once at registration, not per-call), so I annotated the whole tool as destructiveHint: true to cover the replace case, even though append/prepend aren't destructive. Curious whether you'd rather keep that as one conservative annotation, or split vault_patch into per-operation tools for tighter auto-approval behavior.

[coddingtonbear]

TIL that tool annotations for indicating idempotency/destructiveness are a thing! I'm actually in the middle of some tool annotation changes as we speak, so I think I can take this on as part of that work. Thanks for the tip @chrisfriedline-benchling !

[chrisfriedline-benchling]

Rock on! Excited for this - we'll definitely be looking out for it.