Why
MCP仕様には、ツールの挙動をクライアントに伝えるためのannotations（readOnlyHint / destructiveHint / idempotentHint / openWorldHint）という仕組みがありますが、現在このサーバーが公開している26個のツールにはいずれも設定されていません。
具体的には次の3点を確認しました。
@modelcontextprotocol/sdkのregisterTool()はconfig.annotationsを受け付ける仕様になっていますが、src/tools/types/tool.tsのToolConfig型にはtitle / description / inputSchema / outputSchemaしかなく、そもそもannotationsを渡す手段がありません。src/server/index.tsでは、JSON Schema 2020-12対応のため（[Bug] Tool outputSchema uses JSON Schema draft-07, causing "unsupported dialect" error in MCP clients requiring 2020-12 (SEP-1613) #544 ListToolsRequestSchemaのハンドラをserver.server.setRequestHandler(...)で独自実装に差し替えており、src/server/tool-definitions.tsのbuildToolDefinition()がツール定義を手動で組み立てています。この関数はname / title / description / inputSchema / outputSchemaしか返していないため、仮にToolConfigにannotationsを追加しても、ここを直さない限りクライアントには一切伝わりません 。結果として、kintone-delete-recordsのような破壊的操作も、kintone-get-appsのような読み取り専用操作も、クライアント側からは区別する材料が何もない状態です。
annotationsはあくまでヒントであり、クライアントがこれだけを根拠に確認ダイアログの要否を決めるべきではないとMCP仕様にも明記されていますが、対応しているクライアントであれば「これは読み取り専用だから確認不要」「これは破壊的だから確認が必要」といった安全側のUXを提供できるようになります。
What
src/tools/types/tool.tsのToolConfig型に、SDKのToolAnnotations型を使うannotations?フィールドを追加してほしいです。各ツール定義（src/tools/kintone/**/*.ts）に、実態に合ったannotationsを設定してほしいです。例:
kintone-get-*系・kintone-search・kintone-download-fileなど読み取り専用の操作: readOnlyHint: truekintone-delete-records / kintone-delete-form-fields / kintone-delete-space: destructiveHint: truekintone-deploy-app: 削除操作ではありませんが、プレビュー環境の変更（フィールド追加・更新・削除、レイアウト変更、一般設定変更）を本番へ不可逆に確定させる操作のため、destructiveHint: trueが妥当だと考えますその他の追加・更新系操作: 内容に応じてdestructiveHint: false / idempotentHint等を検討
src/server/tool-definitions.tsのbuildToolDefinition()が返すオブジェクトにannotations: tool.config.annotationsを含めるよう修正してほしいです（上記2の理由により、ここを直さないと設定した値がクライアントに届きません）。
ツール単位でMCPサーバー自体がツールを無効化できる仕組みのIssue とは独立した、小さく低リスクな改善として提案します。annotationsはあくまで情報提供であり拒否そのものは実現しないため、両方が揃って初めて「危険なものが分かる」＋「危険なものを実際に止められる」の両方が揃うと考えています。
Why
MCP仕様には、ツールの挙動をクライアントに伝えるための
annotations（readOnlyHint/destructiveHint/idempotentHint/openWorldHint）という仕組みがありますが、現在このサーバーが公開している26個のツールにはいずれも設定されていません。具体的には次の3点を確認しました。
@modelcontextprotocol/sdkのregisterTool()はconfig.annotationsを受け付ける仕様になっていますが、src/tools/types/tool.tsのToolConfig型にはtitle/description/inputSchema/outputSchemaしかなく、そもそもannotationsを渡す手段がありません。src/server/index.tsでは、JSON Schema 2020-12対応のため（[Bug] Tool outputSchema uses JSON Schema draft-07, causing "unsupported dialect" error in MCP clients requiring 2020-12 (SEP-1613) #544 対応）ListToolsRequestSchemaのハンドラをserver.server.setRequestHandler(...)で独自実装に差し替えており、src/server/tool-definitions.tsのbuildToolDefinition()がツール定義を手動で組み立てています。この関数はname/title/description/inputSchema/outputSchemaしか返していないため、仮にToolConfigにannotationsを追加しても、ここを直さない限りクライアントには一切伝わりません。kintone-delete-recordsのような破壊的操作も、kintone-get-appsのような読み取り専用操作も、クライアント側からは区別する材料が何もない状態です。annotationsはあくまでヒントであり、クライアントがこれだけを根拠に確認ダイアログの要否を決めるべきではないとMCP仕様にも明記されていますが、対応しているクライアントであれば「これは読み取り専用だから確認不要」「これは破壊的だから確認が必要」といった安全側のUXを提供できるようになります。
What
src/tools/types/tool.tsのToolConfig型に、SDKのToolAnnotations型を使うannotations?フィールドを追加してほしいです。src/tools/kintone/**/*.ts）に、実態に合ったannotationsを設定してほしいです。例:kintone-get-*系・kintone-search・kintone-download-fileなど読み取り専用の操作:readOnlyHint: truekintone-delete-records/kintone-delete-form-fields/kintone-delete-space:destructiveHint: truekintone-deploy-app: 削除操作ではありませんが、プレビュー環境の変更（フィールド追加・更新・削除、レイアウト変更、一般設定変更）を本番へ不可逆に確定させる操作のため、destructiveHint: trueが妥当だと考えますdestructiveHint: false/idempotentHint等を検討src/server/tool-definitions.tsのbuildToolDefinition()が返すオブジェクトにannotations: tool.config.annotationsを含めるよう修正してほしいです（上記2の理由により、ここを直さないと設定した値がクライアントに届きません）。ツール単位でMCPサーバー自体がツールを無効化できる仕組みのIssueとは独立した、小さく低リスクな改善として提案します。annotationsはあくまで情報提供であり拒否そのものは実現しないため、両方が揃って初めて「危険なものが分かる」＋「危険なものを実際に止められる」の両方が揃うと考えています。