Skip to main content
Glama
Sign In

Gemmein

by com.gemmein
OverviewDiscussionsAdmin

Ask to revoke a server key

request_revoke_server_key
Destructive

Asks the founder to revoke one of the app's secret server keys by its name: a server that uses it is refused from then on. The key's value never passes through this chat. This is a change to how the business runs: your human approves it in their browser with the code Gemmein emails (and, when they set one up, their authenticator app's code). Nothing changes until they approve; approving it carries it out — Gemmein does it the moment they press Approve, once, and records what happened on their Logs. The approval page shows Gemmein's own sentence of the real effect, read against Live; a request that no longer matches Live when it is carried out is refused and nothing changes. Returns the approval link for your human and a handle: live_action_status with wait: true answers the moment it is done, or why not — never ask your human to tell you they approved. A second call asks again (a new approval).

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": {
      "name": "<name>",
      "env": "<env>"
    },
    "name": "request_revoke_server_key"
  }
}

Input Schema

NameRequiredDescriptionDefault
envYeswhich environment the key is in
nameYesthe key's name
noteNoone sentence for your human, shown under Gemmein's own summary

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

Beyond annotations, it discloses that the key value never passes through chat, that the human approves in-browser with emailed and authenticator codes, that Live is checked at execution time, that mismatches are refused, and that the action is recorded on Logs. These are substantive operational details an agent needs before triggering a destructive approval flow.

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?

The purpose and key constraints are front-loaded, and the length is mostly justified by the approval and Live-checking behavior. It is somewhat dense and could be slightly tighter, but there is little outright waste.

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

Completeness5/5

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

For a non-idempotent destructive request tool with no output schema, the description is unusually complete: it explains the approval flow, the return values (approval link and handle), how to poll with live_action_status, and what happens on repeated calls.

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?

Schema coverage is 100%, so the schema already defines name, env, and note. The description reinforces that the key is selected by name but does not add meaningful semantics for env or the optional note beyond what is already structured.

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?

The description states a specific verb and resource: it asks the founder to revoke one of the app's secret server keys by name, and notes the downstream effect that the using server is refused. This clearly distinguishes it from sibling tools such as request_server_key and live_action_status.

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

Usage Guidelines5/5

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

It explains the approval workflow and when it applies, states that nothing changes until human approval, warns that a second call creates a new approval request, and directs the agent to live_action_status with wait:true rather than asking the human for confirmation.

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

All Gemmein toolsInspect
Try in Browser
Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources