Skip to main content
Glama
Sign In

Proof Holdings

by holdings.proof
OverviewDiscussionsAdmin

revoke_auth_session

Destructive

Sign out one device (session) by ID. Over a signed-in session it cannot end the current one (that is logout). Over an API key it can end any of the account's sessions.

ACCESS: needs a Proof account. Authenticate this client (Claude Code: /mcp → Authenticate), then call this tool again. start_login does NOT open this tool.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "session_id": "<session_id>"
    },
    "name": "revoke_auth_session"
  }
}

Input Schema

NameRequiredDescriptionDefault
session_idYesSession ID to revoke

Output Schema

NameRequiredDescriptionDefault
messageNo
successYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": {},
+  "description": "Generic success response",
+  "properties": {
+    "message": {
+      "type": "string"
+    },
+    "success": {
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "success"
+  ],
+  "type": "object"
+}
  2. Changed1 schema field changed
    • removedInput schema / additionalProperties
      Removed value: -false
  3. First observed

TDQS

A4.3/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the destructiveHint=true annotation: it discloses the auth prerequisite (Proof account + client authentication, with the /mcp → Authenticate path and the note that start_login does not unlock this tool) and the context-dependent scope limitation on which sessions can be ended. That is exactly the non-obvious behavioral context an agent needs before a destructive call.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight blocks: behavior first, then access requirements, with no filler. The parenthetical Claude Code authentication path is slightly client-specific but earns its place as an actionable prerequisite.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Annotations cover the destructive profile and an output schema exists, so the description only needs the access and scope story — which it delivers. The one remaining gap is that it does not relate this tool to the adjacent revoke_api_key / list_auth_sessions siblings an agent may be choosing between.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Only one parameter (session_id), and the schema already documents it at 100% coverage with the same wording ('Session ID to revoke'). The description's 'by ID' adds nothing beyond the schema, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Sign out one device (session) by ID') and immediately scopes it: it cannot end the current session when called over a signed-in session, but can end any of the account's sessions over an API key. This is enough for an agent to separate it from create_session, list_auth_sessions, and revoke_api_key without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-it-works/when-it-doesn't conditions (signed-in session vs API key context) and names the alternative behavior for the current session ('that is logout'). It stops short of pointing at the concrete sibling tools for related operations (e.g. revoke_api_key, revoke_authorization), so routing is clear but not exhaustive.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Proof Holdings toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources