Skip to main content
Glama
MithrynMarious

Agent Keyring

keyring_authenticated_request

Make authenticated API calls using managed secrets without exposing keys in responses. It retrieves the secret, executes the request, and logs every call for auditing.

Instructions

Make an authenticated API call using a managed secret. The key never appears in the response.

The keyring retrieves the secret, makes the API call, and returns only the response data. Every call is logged to the checkout ledger.

Args: service: Service identifier (e.g. 'agentmail', 'stripe', 'ga4', 'firebase'). For unregistered services, pass any name — the generic adapter handles the request if base_url is in params. secret_name: Name of the secret to use (from keyring_list_available). method: HTTP method (GET, POST, PUT, DELETE). endpoint: API endpoint path (appended to service base URL). params: Query parameters for the request. For unregistered services, include: base_url (required), auth_type ('bearer'|'header'|'basic'|'query', default 'bearer'), auth_header (header name when auth_type='header'). body: JSON body for POST/PUT requests. scope: Optional scope for multi-value keys (e.g. 'fleet', 'mcp'). When set, tries secret_name:scope first, falls back to secret_name. purpose: Why this request is being made (logged to ledger). did: Agent's DID for identity verification. agentmail_token: AgentMail API key for identity fallback. agentmail_inbox: Agent's AgentMail address for identity fallback.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
didNo
bodyNo
scopeNo
methodNoGET
paramsNo
purposeNo
serviceYes
endpointNo
secret_nameYes
agentmail_inboxNo
agentmail_tokenNo
Behavior5/5

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

No annotations are present, so the description carries the full burden and meets it: it discloses that the key never appears in the response, that only response data is returned, that every call is logged, and that scope/identity fallback behaviors exist. This is far beyond a generic 'makes a request' statement.

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 well-structured: a concise summary, security/logging notes, then a complete Args list. It is long because it must document 11 parameters without schema help, but a few sentences ('The keyring retrieves the secret...') restate the opening mechanic.

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?

For a tool with 11 parameters, no annotations, and no output schema, the description covers invocation and core behavior thoroughly. It does not specify response/error shape beyond 'response data,' but that is largely service-dependent and does not prevent correct invocation.

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

Parameters5/5

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

Schema description coverage is 0%, and the description compensates fully by documenting all 11 parameters with examples, defaults, required conditions (base_url for unregistered services), auth_type options, and fallback semantics. An agent can correctly populate every parameter from this text alone.

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?

Description opens with a specific verb+resource: 'Make an authenticated API call using a managed secret.' It clearly describes the operation and references sibling-adjacent concepts (keyring_list_available, checkout ledger), making it easy for an agent to distinguish this request tool from listing/history/affinity siblings.

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?

Provides clear context: the agent is told to obtain secret_name from keyring_list_available, that calls are logged to the checkout ledger, and that unregistered services need base_url in params. It lacks explicit 'use X instead' exclusions, but the intended selection is unmistakable given tool names and content.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/MithrynMarious/agent-keyring'

If you have feedback or need assistance with the MCP directory API, please join our Discord server