Why
現状、kintone-delete-records / kintone-delete-form-fields / kintone-delete-space / kintone-deploy-app のような破壊的操作を含む26個のツールが常に全て有効になっており、危険な操作を防ぐにはMCPクライアント側の権限設定（deny）に頼るしかありません。しかしクライアントごとに設定方法・設定ファイルの場所が異なり、ユーザーが気づかずに設定し忘れるケースが起きやすいです。
kintoneのAPIトークン権限（レコード閲覧/追加/編集/削除、アプリ管理）でツールを絞ろうとしても、レコード削除以外は粒度が粗すぎて実現できませんでした。
kintone-delete-form-fields は、kintone-add-form-fields / kintone-update-form-fields / kintone-update-form-layout / kintone-update-general-settings / kintone-deploy-app と同じ「アプリ管理」権限1つに束ねられており、フィールド削除だけを個別に禁止できません。kintone-deploy-app は、プレビュー環境に溜まった変更（フィールド追加・更新・削除、レイアウト変更、一般設定変更）を本番環境へ確定反映する操作で、1回の呼び出しで最大300アプリを一括反映できます。削除操作ではありませんが、他の変更系ツールの効果を不可逆に確定させる操作であり、実質的に削除系ツールと同格かそれ以上に危険です。kintone-delete-space を含むSpace系ツールは、APIトークン認証ではそもそも全て無効になり、パスワード認証でも利用者のスペース内の役割という別体系の権限にしか依存できず、APIトークンの権限設定では制御できません。
つまり、kintone側の権限だけでは「ツール単位で許可/拒否を決める」ことができず、MCPサーバー自身がツール名を基準に有効/無効を切り替えられる仕組みが必要だと考えています。
What
- ツール名を指定して個別に無効化できる環境変数・CLIオプション（例:
KINTONE_MCP_DISABLE_TOOLS、カンマ区切りで複数指定可能）を追加してほしいです。
- 可能であれば、明示的に許可したツールだけを有効化するallowlist方式（例:
KINTONE_MCP_ENABLED_TOOLS）も検討してほしいです。組織によってはdenylistよりも「明示的に許可したものだけ動く」方が安全に運用できます。
- 存在しないツール名（typoなど）が指定された場合は、黙って無視せず起動時にエラーにしてほしいです。サイレントに無視されると、denyを設定したつもりが実は効いていない、という事故につながります。
- 実装イメージとして、既存の
src/server/tool-filters.ts の shouldEnableTool() は認証方式（APIトークンかどうか）によるツール除外の仕組みをすでに持っているため、ここにユーザー指定のdeny/allowリストによる判定を追加する形で実現できるのではと考えています。
Why
現状、
kintone-delete-records/kintone-delete-form-fields/kintone-delete-space/kintone-deploy-appのような破壊的操作を含む26個のツールが常に全て有効になっており、危険な操作を防ぐにはMCPクライアント側の権限設定（deny）に頼るしかありません。しかしクライアントごとに設定方法・設定ファイルの場所が異なり、ユーザーが気づかずに設定し忘れるケースが起きやすいです。kintoneのAPIトークン権限（レコード閲覧/追加/編集/削除、アプリ管理）でツールを絞ろうとしても、レコード削除以外は粒度が粗すぎて実現できませんでした。
kintone-delete-form-fieldsは、kintone-add-form-fields/kintone-update-form-fields/kintone-update-form-layout/kintone-update-general-settings/kintone-deploy-appと同じ「アプリ管理」権限1つに束ねられており、フィールド削除だけを個別に禁止できません。kintone-deploy-appは、プレビュー環境に溜まった変更（フィールド追加・更新・削除、レイアウト変更、一般設定変更）を本番環境へ確定反映する操作で、1回の呼び出しで最大300アプリを一括反映できます。削除操作ではありませんが、他の変更系ツールの効果を不可逆に確定させる操作であり、実質的に削除系ツールと同格かそれ以上に危険です。kintone-delete-spaceを含むSpace系ツールは、APIトークン認証ではそもそも全て無効になり、パスワード認証でも利用者のスペース内の役割という別体系の権限にしか依存できず、APIトークンの権限設定では制御できません。つまり、kintone側の権限だけでは「ツール単位で許可/拒否を決める」ことができず、MCPサーバー自身がツール名を基準に有効/無効を切り替えられる仕組みが必要だと考えています。
What
KINTONE_MCP_DISABLE_TOOLS、カンマ区切りで複数指定可能）を追加してほしいです。KINTONE_MCP_ENABLED_TOOLS）も検討してほしいです。組織によってはdenylistよりも「明示的に許可したものだけ動く」方が安全に運用できます。src/server/tool-filters.tsのshouldEnableTool()は認証方式（APIトークンかどうか）によるツール除外の仕組みをすでに持っているため、ここにユーザー指定のdeny/allowリストによる判定を追加する形で実現できるのではと考えています。