利用者の鍵をすべて失効
revoke_user利用者 (external_id) のパスキーをすべて失効します (退会・乗っ取り時)。取り消せません。 (api_key が必要: 管理画面で発行したキー)
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | Yes | API キー (sk_live_…) | |
| external_id | Yes |
revoke_user利用者 (external_id) のパスキーをすべて失効します (退会・乗っ取り時)。取り消せません。 (api_key が必要: 管理画面で発行したキー)
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | Yes | API キー (sk_live_…) | |
| external_id | Yes |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal destructiveness and idempotency; the description adds valuable context by stating the operation is irreversible ('取り消せません') and requires an admin-issued api_key. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one compact sentence that front-loads the operation and scope, then adds the critical trigger, irreversibility warning, and auth requirement. Every clause earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive two-parameter tool with no output schema, the description covers trigger, scope, irreversibility, and auth. It does not explicitly describe the post-condition (e.g., the user can no longer authenticate with those passkeys), but that is reasonably implied by '失効'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50% (api_key is described in the schema, external_id is not). The description compensates by clarifying that external_id identifies the user and that api_key must be issued from the admin console, though it does not specify external_id's format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('失効します' — revoke) against a specific resource ('利用者 (external_id) のパスキーをすべて' — all passkeys of the user). It also differentiates from the sibling revoke_credential by emphasizing 'すべて' (all), making the user-level scope explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly gives the intended use cases ('退会・乗っ取り時' — for account deletion or takeover) and the required api_key from the admin console. It does not explicitly mention when not to use it or contrast it with revoke_credential, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.