CorroborateMe
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CORROBORATE_ME_API_KEY | Yes | Your CorroborateMe API key (starts with `aa_`). Used as a Bearer token to authenticate to the hosted MCP endpoint at https://corroborateme.com/mcp. Obtain it from the CorroborateMe console or via the agent bootstrap + machine-pay flow. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| agent_bootstrapC | Start humanless company onboarding (returns bootstrap token flow info) |
| budget_getB | Remaining quotas for the authenticated company |
| billing_checkoutB | Create Stripe Checkout URL (or local bypass grant) |
| billing_machine_payD | Agent prepaid unlock when MPP enabled / local bypass |
| billing_portalD | Stripe Customer Portal URL |
| keys_createB | Mint a new aa_ API key (shown once) |
| oauth_client_createA | Register an OIDC relying-party client (enableEndSession on; post-logout URIs default from redirect origins) |
| integration_upsertC | Store encrypted integration secret (Google/Apple/etc.) |
| integration_listA | List integrations (prefixes only, no secrets) |
| create_login_linkA | Mint one-time human login URL. Choose notify methods: webhook, redirect, post_message, form_post (poll+sse always on). Default reuses company cookie (Continue-as); set force_reauth for fresh login. No SMS. |
| get_login_statusA | Poll login-link session status (includes notify errors) |
| retry_login_webhookC | Retry signed webhook delivery after a failed notify |
| webhook_allowlist_addA | Allowlist a callback URL prefix (https webhooks/redirects or cursor:// deep links) |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 13 tools
Each tool targets a distinct resource and action: login lifecycle, webhook management, integrations, billing, keys, and OAuth. Even related tools like get_login_status and retry_login_webhook serve clearly different purposes (status check vs. retry), so there is no realistic ambiguity.
All names are snake_case, but the verb/noun order is inconsistent—some are verb-first (create_login_link, get_login_status) while others are noun-first (budget_get, keys_create, integration_list). This mixed convention reduces predictability, though the names remain readable and self-explanatory.
13 tools is well within the ideal 3-15 range for a server with this breadth (authentication, billing, integrations, key management, OAuth). Each tool appears justified and none feel redundant or superfluous for the scope.
The tool surface covers core creation and retrieval workflows (create/login status, keys_create, billing_checkout), but lacks lifecycle operations such as revoking keys, deleting OAuth clients, or removing webhook allowlist entries. These gaps could force agents to hit dead ends in real-world scenarios.