Skip to main content
Glama

Agentic Endpoints

by com.oliverkiss

Rotate a vault namespace token

vault_rotate_token
Destructive

Free. Mints a new namespace_token and immediately invalidates the current one, which you must present to authorize the rotation. Do this whenever the token may have been exposed — a leaked token is otherwise permanent, unrevocable read and delete access to every secret in the namespace. There is no recovery if you lose the token. This tool is free; no payment is required.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
namespaceYesIsolation scope
namespace_tokenYesOne-time token issued by the first call that claimed this namespace. Required for every later call.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
noticeNoHuman-readable warning that the old token is now invalid
statusYes'rotated'
namespace_tokenYesThe new token, shown exactly once. The previous one stops working.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations mark the operation as destructive and non-read-only, and the description goes further by disclosing immediate invalidation, irreversibility, the need to present the current token, and permanent unrevocable access if leaked. This adds significant behavioral context beyond the annotations.

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 description is front-loaded with the core behavior and risk in compact sentences. It is slightly padded by repeating 'free' at the start and again at the end, but the overall structure is efficient.

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?

With both parameters fully documented in the schema and an output schema present, the description covers everything needed to decide and invoke correctly: trigger conditions, required authorization, consequences, and irreversibility.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3. The description adds value by clarifying that the namespace_token must be the current token and that rotation produces a new one, disambiguating the schema's 'first call' phrasing.

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 the exact action—'Mints a new namespace_token and immediately invalidates the current one'—on a specific resource. It is unambiguous and clearly distinct from sibling tools like vault_delete or once_key_claim.

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?

It explicitly says when to use the tool ('whenever the token may have been exposed') and explains the stakes if you don't. It does not mention alternatives or explicitly state when not to use, preventing a 5.

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

All Agentic Endpoints toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0
Disambiguation5/5

Each tool maps to a distinct resource and action: meetings have import/list/search/get, the once-key system has claim/complete/release, vault has store/retrieve/exists/list/delete/rotate_token, and compress/pdf_parse/scrape are separate utilities. No two tools appear to perform the same side effect, so an agent should not struggle to choose among them.

Naming Consistency5/5

Tools use consistent snake_case and mostly follow a domain_verb pattern (meetings_*, once_key_*, vault_*), with standalone verbs like compress, scrape, and pdf_parse for single utilities. The naming is predictable and easy to extend.

Tool Count4/5

At 16 tools the server is just above the ideal 3-15 range, but the count is justified by six distinct capability clusters. Each tool earns its place, and nothing feels redundant.

Completeness4/5

Core lifecycles are covered well: vault has full CRUD plus token rotation, once-key has claim/complete/release, and meetings provide import/search/get/list. Minor gaps include no meeting update/delete and no direct namespace management, but these are workable rather than blocking.

Resources