clavis-mcp-server
# Clavis MCP Server
Secure credential management for Claude Desktop and MCP servers.
## Features
- π Encrypted credential storage (AES-128-CBC + HMAC-SHA256, via Fernet)
- π‘οΈ Server-side credential injection β the raw key never enters the conversation
- π Automatic OAuth token refresh
- π‘ Thin forwarding layer β rate limiting, audit logging, and usage tracking are all handled by the Clavis server
## Installation
```bash
npx @clavisagent/mcp-server
```
Or install globally:
```bash
npm install -g @clavisagent/mcp-server
```
## Usage with Claude Desktop
Add the following to your Claude Desktop configuration file (`claude_desktop_config.json`):
```json
{
"mcpServers": {
"clavis": {
"command": "npx",
"args": ["-y", "@clavisagent/mcp-server"],
"env": {
"CLAVIS_API_KEY": "eyJ..."
}
}
}
}
```
## Usage with Claude Code
```bash
claude mcp add clavis -- npx -y @clavisagent/mcp-server
```
## Configuration
| Variable | Required | Default | Description |
|---|---|---|---|
| `CLAVIS_API_KEY` | yes | β | Your Clavis JWT, from `POST /v1/auth/login`. Not the `cla_β¦` key shown at sign-up. |
| `CLAVIS_API_URL` | no | `https://clavisagent.com` | Base URL of your Clavis instance. Set this for self-hosted deployments. |
## Available Tools
| Tool | Description |
|---|---|
| `call_service` | **Recommended.** Make an API call with server-side credential injection β the credential is injected into the upstream request server-side, so the raw key never enters the conversation. |
| `get_credentials` | Legacy. Returns the raw access token or API key for a named service. Prefer `call_service`. |
| `list_services` | List all services with stored credentials |
| `check_credential_status` | Check the status and expiry of credentials for a service |
### Security note
Prefer `call_service` over `get_credentials`. `call_service` keeps the secret
server-side, so a prompt injection has no credential in context to exfiltrate.
`get_credentials` places the raw key in the conversation and exists only for
callers that must hold the token themselves.
## License
MIT
TDQS
Scored across 4 tools
Each tool has a clearly distinct purpose: call_service proxies requests with server-side credential injection, get_credentials returns raw tokens for non-proxy use, list_services enumerates configured services, and check_credential_status inspects vault state without external calls. The overlap between call_service and get_credentials is explicitly addressed with usage guidance, so an agent can select correctly.
All tool names follow a consistent verb_noun pattern in lower_snake_case: call_service, get_credentials, list_services, check_credential_status. The verbs are distinct and clearly map to each tool's function.
With four tools, the set is tightly focused on core Clavis operations: using credentials, retrieving them, listing services, and checking status. This is the right granularity for a credential-management serverβnot bloated, not thin.
The tool surface covers the full lifecycle of interacting with Clavis-managed credentials: calling an upstream service, retrieving a raw credential when necessary, discovering available services, and checking status/rate limits. Missing features like credential creation or rotation are handled automatically by Clavis, so these are not gaps for the agent.