How do I use agent-keys?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@agent-keys check my OpenAI API key" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

agent-keys

by Gonzih

Overview Schema Related Servers Score Discussions

TypeScript

agent-keys

npm version License: MIT

MCP server that lets AI agents autonomously acquire and manage API keys.

The Problem

AI agents frequently need API keys to accomplish tasks — sending emails, making calls, running models, storing data. Today this requires a human to manually create accounts, navigate dashboards, and paste keys into configs. agent-keys gives agents a structured, secure interface to discover services, get provisioning instructions, store retrieved keys, verify they work, and export them as environment variables — all without human intervention after initial setup.

Related MCP server: Agentic Vault

Quick Start

Via npx (no install required)

npx @gonzih/agent-keys

MCP Configuration

Add to your MCP config file (e.g. ~/.claude/claude_desktop_config.json or ~/.config/claude-code/config.json):

{
  "mcpServers": {
    "agent-keys": {
      "command": "npx",
      "args": ["@gonzih/agent-keys"],
      "env": {
        "AGENT_KEYS_SECRET": "your-strong-encryption-secret"
      }
    }
  }
}

Claude Code Config

Add to your Claude Code settings:

{
  "mcpServers": {
    "agent-keys": {
      "command": "npx",
      "args": ["@gonzih/agent-keys"],
      "env": {
        "AGENT_KEYS_SECRET": "your-strong-encryption-secret"
      }
    }
  }
}

Tools

`list_services`

List all 26 supported services with their category, description, signup URL, and whether a key is stored.

Input: none

Output:

[
  {
    "name": "openai",
    "displayName": "OpenAI",
    "category": "ai",
    "description": "AI research company providing GPT-4, DALL-E, Whisper, and embeddings APIs.",
    "signupUrl": "https://platform.openai.com/signup",
    "has_key": true,
    "freetier": "$5 free credit for new accounts (limited time)",
    "envVarName": "OPENAI_API_KEY"
  }
]

`get_api_key`

Retrieve a stored API key. Returns the key if found, or provisioning guidance if not.

Input:

{ "service": "openai" }

Output (found):

{
  "found": true,
  "service": "openai",
  "key": "sk-proj-...",
  "stored_at": "2024-01-15T10:30:00.000Z",
  "envVarName": "OPENAI_API_KEY"
}

Output (not found):

{
  "found": false,
  "service": "openai",
  "message": "No API key stored for OpenAI. Use provision_api_key to get instructions.",
  "signupUrl": "https://platform.openai.com/signup"
}

`store_api_key`

Store an API key in the encrypted vault.

Input:

{
  "service": "openai",
  "key": "sk-proj-...",
  "metadata": { "org": "my-org", "created_by": "agent" }
}

Output:

{
  "success": true,
  "service": "openai",
  "displayName": "OpenAI",
  "message": "API key for OpenAI stored successfully.",
  "envVarName": "OPENAI_API_KEY"
}

`check_api_key`

Verify a stored key is still valid by calling the service's test endpoint.

Input:

{ "service": "openai" }

Output:

{
  "valid": true,
  "service": "openai",
  "displayName": "OpenAI",
  "status": 200,
  "message": "API key for OpenAI is valid."
}

Services with test endpoints: openai, sendgrid, stripe, github, groq, together-ai, elevenlabs, deepgram, replicate, brave-search, serper, tavily.

`provision_api_key`

Get step-by-step instructions and the direct signup URL for acquiring an API key.

Input:

{ "service": "groq" }

Output:

{
  "service": "groq",
  "displayName": "Groq",
  "signupUrl": "https://console.groq.com/login",
  "steps": [
    "Go to https://console.groq.com/login",
    "Create a free account or sign in",
    "Navigate to https://console.groq.com/keys",
    "Click 'Create API Key'",
    "Give it a name and click 'Submit'",
    "Copy the generated API key immediately (shown only once)",
    "Store it using store_api_key with service 'groq'"
  ],
  "freetier": "Free tier with generous rate limits"
}

`remove_api_key`

Delete a key from the vault.

Input:

{ "service": "openai" }

Output:

{
  "success": true,
  "service": "openai",
  "message": "API key for OpenAI removed from vault."
}

`export_env`

Generate shell export statements for stored keys.

Input:

{ "services": ["openai", "anthropic"] }

Or omit services to export all stored keys.

Output:

{
  "exports": [
    "export OPENAI_API_KEY=\"sk-proj-...\"",
    "export ANTHROPIC_API_KEY=\"sk-ant-...\""
  ],
  "shell": "export OPENAI_API_KEY=\"sk-proj-...\"\nexport ANTHROPIC_API_KEY=\"sk-ant-...\"",
  "count": 2
}

Supported Services

AI (5 services)

Name	Display Name	Free Tier	Env Var
`openai`	OpenAI	$5 credit (new accounts)	`OPENAI_API_KEY`
`anthropic`	Anthropic	Free tier with rate limits	`ANTHROPIC_API_KEY`
`replicate`	Replicate	Pay-per-use, free community models	`REPLICATE_API_TOKEN`
`together-ai`	Together AI	$25 free credit	`TOGETHER_API_KEY`
`groq`	Groq	Free tier, generous limits	`GROQ_API_KEY`

Communication (6 services)

Name	Display Name	Free Tier	Env Var(s)
`twilio`	Twilio	$15 trial credit	`TWILIO_ACCOUNT_SID`, `TWILIO_AUTH_TOKEN`
`sendgrid`	SendGrid	100 emails/day forever	`SENDGRID_API_KEY`
`mailgun`	Mailgun	100 emails/day, 3 months	`MAILGUN_API_KEY`
`postmark`	Postmark	100 emails/month forever	`POSTMARK_API_TOKEN`
`vonage`	Vonage (Nexmo)	$2 trial credit	`VONAGE_API_KEY`, `VONAGE_API_SECRET`
`telnyx`	Telnyx	$1 credit on signup	`TELNYX_API_KEY`

Voice (3 services)

Name	Display Name	Free Tier	Env Var
`elevenlabs`	ElevenLabs	10,000 chars/month	`ELEVENLABS_API_KEY`
`deepgram`	Deepgram	$200 free credit	`DEEPGRAM_API_KEY`
`assemblyai`	AssemblyAI	$50 free credit	`ASSEMBLYAI_API_KEY`

Infrastructure (8 services)

Name	Display Name	Free Tier	Env Var
`stripe`	Stripe	No monthly fee	`STRIPE_SECRET_KEY`
`github`	GitHub	Free for personal use	`GITHUB_TOKEN`
`cloudflare`	Cloudflare	Free plan available	`CLOUDFLARE_API_TOKEN`
`vercel`	Vercel	Hobby plan free	`VERCEL_TOKEN`
`railway`	Railway	$5 credit/month	`RAILWAY_TOKEN`
`supabase`	Supabase	2 free projects	`SUPABASE_ANON_KEY`
`planetscale`	PlanetScale	5GB free storage	`PLANETSCALE_SERVICE_TOKEN`
`upstash`	Upstash	10,000 commands/day	`UPSTASH_REDIS_REST_TOKEN`

Data (4 services)

Name	Display Name	Free Tier	Env Var
`serper`	Serper	2,500 free searches	`SERPER_API_KEY`
`brave-search`	Brave Search	2,000 queries/month	`BRAVE_API_KEY`
`tavily`	Tavily	1,000 calls/month	`TAVILY_API_KEY`
`firecrawl`	Firecrawl	500 credits on signup	`FIRECRAWL_API_KEY`

Adding a New Service

Edit src/registry.ts and add a new object to the registry array:

{
  name: 'my-service',           // slug used in tool calls
  displayName: 'My Service',    // human-readable name
  category: 'ai',               // 'communication' | 'ai' | 'voice' | 'infrastructure' | 'data'
  description: 'What it does.',
  signupUrl: 'https://myservice.com/signup',
  docsUrl: 'https://docs.myservice.com/api',
  envVarName: 'MY_SERVICE_API_KEY',
  freetier: 'Description of free tier',
  programmatic: false,
  provisioningSteps: [
    'Go to https://myservice.com/signup',
    'Create an account',
    'Navigate to API Keys',
    'Click Create Key',
    'Copy the key',
    'Store it using store_api_key with service "my-service"',
  ],
  testEndpoint: {               // optional
    url: 'https://api.myservice.com/v1/me',
    method: 'GET',
    headers: (key: string) => ({ Authorization: `Bearer ${key}` }),
    successStatus: 200,
  },
}

Then run npm run build.

Security

Encryption: AES-256-GCM with scrypt key derivation (N=16384, r=8, p=1)
Per-write randomness: Each vault write uses a fresh 16-byte salt and 16-byte IV
Auth tag: GCM auth tag prevents undetected tampering
Plaintext fallback: If AGENT_KEYS_SECRET is not set, keys are stored unencrypted with a warning
Vault location: ~/.agent-keys/vault.json by default; override with AGENT_KEYS_VAULT
Secret management: Never commit AGENT_KEYS_SECRET to source control; use env vars or a secrets manager

Development

# Install dependencies
npm install

# Build TypeScript
npm run build

# Run directly with tsx (no build step)
npm run dev

License

MIT

Available Tools

7 tools

check_api_keyA

Verify a stored API key still works by hitting the service's test endpoint.

ParametersJSON Schema

Name	Required	Description	Default
`service`	Yes	Service name

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, so the description must fully disclose behavior. It mentions hitting a test endpoint, but does not clarify whether this modifies anything, requires authentication, or has rate limits. For a verification tool, the lack of side-effect details is a gap.

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

Conciseness5/5

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

A single sentence that is front-loaded with the verb 'Verify'. Every word contributes meaning; no wasted text.

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

Completeness3/5

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

The tool is simple (1 param, no output schema) but the description omits what the verification returns (e.g., boolean, status message). For a verification tool, this return context is important for the agent to properly use the result.

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% with a single 'service' parameter described as 'Service name'. The description adds no additional meaning beyond the schema, so baseline score 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?

The description clearly states the verb 'Verify' and the resource 'a stored API key', specifying the action 'hitting the service's test endpoint.' This distinguishes it from sibling tools like get_api_key (retrieve key) or store_api_key (save new key).

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

Usage Guidelines3/5

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

No explicit guidance on when to use or alternatives. While the tool's function is straightforward, it doesn't mention prerequisites (e.g., key must be stored) or when not to use it. A brief context would help, given sibling tools exist.

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

export_envA

Export stored API keys as shell export statements (e.g. export OPENAI_API_KEY=...).

ParametersJSON Schema

Name	Required	Description	Default
`services`	No	Optional list of service names to export. If omitted, exports all stored keys.

TDQS

A3.7/5.0

Behavior2/5

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

No annotations provided. The description does not disclose important behavioral traits such as security implications (keys in plain text), output format, or behavior when no keys are stored.

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

Conciseness5/5

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

The description is a single sentence with an example, concise and to the point with no wasted words.

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

Completeness3/5

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

Without an output schema, the description does not specify the exact return format or error handling. It is adequate but leaves some gaps for an agent.

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?

The services parameter is well-documented in the schema. The description adds context by explaining that omission exports all keys and provides an example output.

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 clearly states the tool exports stored API keys as shell export statements, with an example. It distinguishes from siblings like get_api_key or list_services.

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

Usage Guidelines3/5

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

The description implies usage for shell environment export but does not explicitly clarify when to use vs alternatives like get_api_key (single key) or when not to use it.

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

get_api_keyA

Get a stored API key for a service. Returns the key if stored, or provisioning guidance if not.

ParametersJSON Schema

Name	Required	Description	Default
`service`	Yes	Service name (e.g. openai, twilio, stripe)

TDQS

A4/5.0

Behavior4/5

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

There are no annotations, so the description must disclose behavior. It accurately states that the tool returns the key if stored, otherwise provides provisioning guidance. This reveals the two possible outcomes and suggests it is a read-only lookup, which is sufficient for a simple retrieval tool.

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

Conciseness5/5

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

The description is extremely concise at two sentences, with the purpose front-loaded. Every word is necessary and there is no redundancy.

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?

Given the simplicity of the tool (one parameter, no output schema, no annotations), the description covers the core behavior adequately. It specifies the return value in both cases, which is sufficient for an agent to understand what to expect. However, it could have mentioned that the operation is read-only and does not modify state.

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 description coverage is 100% for the single 'service' parameter, which already includes examples. The description adds no extra meaning beyond restating 'for a service', so it meets the baseline but does not enhance parameter understanding.

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 clearly states the action ('Get a stored API key') and the resource ('for a service'). It distinguishes from siblings by specifying the two possible outcomes ('key if stored, or provisioning guidance if not'), which contrasts with other tools like store, provision, or remove.

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

Usage Guidelines3/5

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

The description implies the tool is used when retrieving a stored API key, but it does not explicitly state when to avoid this tool or mention alternatives like check_api_key or provision_api_key. The sibling list is not referenced for guidance.

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

list_servicesA

List all supported services with their status (whether a key is stored), category, description, and signup URL.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.3/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It correctly states the tool returns status, category, description, and signup URL, but does not explicitly confirm it is read-only or has no side effects. Given the sibling tools that mutate keys, this is adequate but lacks an explicit safety statement.

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

Conciseness5/5

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

The description is a single, well-structured sentence that front-loads the verb 'List' and clearly enumerates the returned fields. No wasted words.

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 zero parameters and no output schema, the description fully conveys what the tool does and what information is returned. For a list tool, this is complete and sufficient.

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?

There are no parameters, so baseline 4 applies. The description adds meaning by specifying the content of the returned items (status, category, description, signup URL), which is valuable beyond the empty schema.

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 uses a specific verb ('list') and resource ('all supported services'), and details exactly what information is returned (status, category, description, signup URL). This clearly distinguishes it from sibling tools that operate on individual API keys.

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?

The description implies usage: call this to see available services and whether a key is stored. It does not explicitly state when not to use it or mention alternatives, but the purpose is straightforward and the sibling tools are all about key management, not listing.

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

provision_api_keyB

Get step-by-step instructions and direct signup URL for acquiring an API key for a service.

ParametersJSON Schema

Name	Required	Description	Default
`service`	Yes	Service name

TDQS

B3.2/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. It states that instructions and URL are returned, but does not disclose if this operation is read-only, has side effects, requires authentication, or what happens if the service does not exist.

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?

Single sentence clearly conveys purpose. No filler or redundancy, but could be slightly more informative about the output.

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

Completeness3/5

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

Given simplicity (1 param, no output schema, no annotations), the description is adequate. However, it lacks details on the format of instructions/URL and error handling, and does not leverage context of sibling tools to clarify usage.

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 'service' with schema description 'Service name'. Schema description coverage is 100%, so the description adds no additional meaning beyond what the schema already provides. Baseline 3 is appropriate.

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 explicitly states the tool provides step-by-step instructions and a signup URL for acquiring an API key. The verb 'get' and resource 'instructions/URL' are specific, and the tool is clearly distinguished from siblings like get_api_key (which retrieves existing keys) and store_api_key (which stores keys).

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

Usage Guidelines2/5

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

No explicit guidance on when to use this tool vs alternatives. The description does not mention when not to use it, prerequisites, or mention siblings like list_services or check_api_key.

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

remove_api_keyB

Remove an API key from the vault.

ParametersJSON Schema

Name	Required	Description	Default
`service`	Yes	Service name

TDQS

B3.1/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. It only says 'Remove' without disclosing destructive nature, authentication needs, error handling (e.g., key not found), or side effects.

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?

One clear sentence, front-loaded with action. Could be slightly more informative without being verbose.

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

Completeness2/5

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

Simple tool but lacks return value details, error scenarios, or post-removal behavior. With no output schema, description should provide more context.

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% (service parameter described as 'Service name'). Description adds no extra meaning beyond schema. Baseline score of 3 is appropriate.

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 clearly states the action ('Remove') and the target ('API key from the vault'). It effectively distinguishes from sibling tools like list_services, get_api_key, store_api_key, etc.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives (e.g., check_api_key, provision_api_key). Missing when-not or prerequisites.

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

store_api_keyB

Store an API key in the encrypted vault.

ParametersJSON Schema

Name	Required	Description
`key`	Yes	The API key to store
`service`	Yes	Service name
`metadata`	No	Optional metadata (account info, notes, etc.)

TDQS

B3.1/5.0

Behavior2/5

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

No annotations provided, and the description does not disclose behavioral traits such as overwrite policy, encryption details, or security implications.

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?

Single sentence is very concise and front-loaded, but could be slightly more structured without sacrificing brevity.

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

Completeness2/5

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

Despite low complexity, the description lacks context about behavior, return values, and relationship to sibling tools, leaving gaps for a security-critical operation.

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 description coverage is 100%, so baseline is 3; the description adds no extra parameter information beyond what is in the schema.

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 clearly states the verb 'store' and the resource 'API key' in the encrypted vault, distinguishing it from siblings like list_services or get_api_key.

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

Usage Guidelines2/5

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

No guidance on when to use this tool vs. alternatives; missing context like prerequisites or typical use cases.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

7 tool updatesv0.1.0Jul 26, 2026
- First observedcheck_api_key
- First observedexport_env
- First observedget_api_key
- First observedlist_services
- First observedprovision_api_key
- First observedremove_api_key
- First observedstore_api_key

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: listing services, getting/storing/checking/provisioning/removing keys, and exporting. No overlap.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (e.g., list_services, get_api_key, store_api_key). The use of 'env' in export_env is a different noun but still fits the pattern.

Tool Count5/5

7 tools is well-scoped for managing API keys, covering all essential operations without being excessive or insufficient.

Completeness5/5

The tool surface covers the full lifecycle: discovery, storage, retrieval, verification, provisioning guidance, deletion, and export. No obvious gaps.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

ClawLinkOAuth
dev.claw-link
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
App Automation Workplace & Productivity
24
microservices.sh
sh.microservices
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
Cloud Platforms Agent Orchestration Developer Tools
21
OpenClaw MCP Ecosystem
io.github.yedanyagamiai-cmd
9 remote MCP servers on Cloudflare Workers for AI agents. Free tier + Pro API keys.
Agent Orchestration Cloud Platforms RAG Systems
3
UnifAPIOAuth
com.unifapi
Hosted MCP server for live public-data APIs and Skills for AI agents.
Open Data Search AI & Machine Learning
2

Related MCP Servers

ServeMyAPI
Security Developer Tools
Jktfe
F
license
Not graded
quality
D
maintenance
A personal MCP server for securely storing and accessing API keys across projects using the macOS Keychain, letting AI assistants and applications retrieve credentials through natural language.
Updated 3 months ago (2026-05-31 20:14 UTC)
25
-
Agentic Vault
Security Shell Access
AliProgrammin
A
license
Not graded
quality
C
maintenance
MCP server that lets AI agents call APIs without ever seeing the credentials, using a local encrypted vault and per-secret allowlist policies for HTTP requests and subprocess environment variables.
Updated 4 months ago (2026-04-26 15:14 UTC)
1
AGPL 3.0
safe-key-mcp
Security Shell Access Command Line
Yormede
A
license
Not graded
quality
C
maintenance
MCP server enabling AI agents to use secrets (API keys, tokens) via encrypted vault, executing HTTP/shell/SSH actions server-side while never exposing secret values to the AI.
Updated 2 months ago (2026-07-13 14:15 UTC)
MIT
AgentVault
Security Autonomous Agents Developer Tools
bch1212
A
license
Not graded
quality
C
maintenance
MCP server for AI-native credential management, enabling agents to securely store, retrieve, and manage API keys with encryption, spending budgets, and audit logging.
Updated 3 months ago (2026-06-06 12:32 UTC)
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/Gonzih/agent-keys'

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