Enforce complete tool hint annotations with a linter

[dcramer]

Every tool in the catalog must declare readOnlyHint and destructiveHint in its annotations block. Right now several write tools (add-issue-note, analyze-issue-with-seer, create-dsn, create-project, create-team) have no annotations at all, while others declare only one of the two hints. This creates ambiguity for any routing logic, client-side confirmation gates, or server-side filters that rely on these values.

Scope

• Audit all tools in packages/mcp-core/src/tools/catalog/ and catalog-runtime/ for missing or partial annotations blocks.
• Add readOnlyHint and destructiveHint to every tool that lacks them.
• Add a deterministic test or CI lint rule that fails if any registered tool is missing either hint — so gaps can't be reintroduced silently. Something like iterating allTools and asserting both fields are explicitly true or false, not undefined.

Known gaps (as of reviewed commit 3705c15)

• add-issue-note — no destructiveHint
• analyze-issue-with-seer — no readOnlyHint or destructiveHint
• create-dsn — no destructiveHint
• create-project — no destructiveHint
• create-team — no destructiveHint
• update-dsn, update-issue, update-project — have destructiveHint: true but no explicit readOnlyHint: false

Related: sentry-geoffg/readOnlyHint-changes branch adds server-side filtering keyed on readOnlyHint; that filter is only as good as the annotations it reads.

--

View Junior Session in Sentry

[linear-code]

MCP-997

[sentry-pierre]

Hi, I'm Pierre!

I checked the current state after commit 3705c15. The specific gaps listed in the issue are already fixed in HEAD — add-issue-note, analyze-issue-with-seer, create-dsn, create-project, create-team, update-dsn, update-issue, and update-project all now declare both readOnlyHint and destructiveHint.

What is still missing: almost every read-only catalog tool only declares readOnlyHint: true without an explicit destructiveHint: false. There is also a baseline test in packages/mcp-core/src/tools/tools.test.ts, but it only asserts destructiveHint when readOnlyHint === false, so the gaps the issue wants to prevent can still be reintroduced on read-only tools.

A maintainer can take it from here.