mcp-keelgrc
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| KEEL_API_KEY | Yes | Required. API key for Keel workspace. Create one under Integrations -> API keys in your Keel workspace. | |
| KEEL_BASE_URL | No | Optional. Base URL for the Keel API. Defaults to https://app.keelgrc.com. Set it for a self-hosted or preview workspace. | https://app.keelgrc.com |
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 |
|---|---|
| keel_whoamiA | Verify the API key and return the connected Keel organization as {"org":{"id","name","tier"}}, where "tier" is the plan (free / starter / pro / enterprise / msp). Use this first to confirm which workspace you are acting on. |
| keel_list_controlsA | List the workspace security controls. Each item has "id", "key", "name", "description", "state", "ownerEmail" and "ownerName". Note the status field is named "state", and its values are not_started / in_progress / implemented / gap / not_applicable. |
| keel_readinessA | Get the audit-readiness summary for ISO/IEC 27001:2022 — this endpoint covers that framework only, not whichever framework the workspace has applied. Returns "framework", "version", "readiness" (percent, integer), "total", "applicable", "covered", "inProgress", "gap", "unaddressed" and "notApplicable". |
| keel_list_tasksA | List the workspace compliance tasks. Each item has "id", "title", "description", "status" (open / in_progress / done), "dueAt", "createdAt", "relatedEntityType" and the assignee as "assigneeId" / "assigneeName" / "assigneeEmail". |
| keel_create_taskA | Create a compliance task in the workspace. Returns the new task id. Note: an unparseable dueAt is silently ignored by the API and the task is created without a due date, so send a valid ISO-8601 value or omit it. |
| keel_list_risksA | List the workspace risk register. Each item has "id", "title", "description", "category", "likelihood", "impact", "inherentScore", "treatment", "residualLikelihood", "residualImpact", "residualScore", "status", "owner", "ownerEmail", "level" (low / medium / high), "mitigatingControls" and "implementedControls". Sorted by status first (open before closed), then level, then score — so an open low risk appears above a closed high one. |
| keel_create_riskA | Add a risk to the workspace risk register. Returns the new risk id. Likelihood and impact are on a 1-5 scale. |
| keel_list_vendorsA | List the third-party vendors tracked in the workspace, with "id", "name", "website", "contactEmail", "tier", "inherentTier", "residualTier", "status", "dataAccess", "notes", "lastReviewedAt" and "reviewDue". |
| keel_create_vendorB | Add a vendor to the workspace vendor register. Returns the new vendor id and tier. |
| keel_list_peopleA | List the workspace personnel directory, with "id", "source", "externalId", "email", "fullName", "jobTitle", "department", "groups", "managerEmail", "status" and "lastSyncedAt". |
| keel_upsert_personA | Add a person to the workspace directory, or update them if the email already exists. Idempotent: the response includes "created" (true for a new record, false for an update). Only manually-created records are updated — a person synced from an identity provider is returned unchanged. |
| keel_list_policiesA | List the workspace policies, with "id", "key", "title", "status", "version", "updatedAt", "approvedAt", "reviewDue" and "ownerMembershipId". |
| keel_create_policyA | Create a policy from Markdown. Returns the new policy id, key and title. The key is derived from the title when not supplied; a policy is identified by its key, so reusing a key targets the existing policy. |
| keel_list_evidenceB | List collected evidence, with "id", "type" (file / link), "title", "description", "filename", "sizeBytes", "contentType", "url", "collectedAt" and "expiresAt". |
| keel_add_evidence_linkA | Attach a URL as evidence, optionally against a control. This tool covers link evidence only — uploading a file is a multipart request the REST API supports but this stdio server does not, so use the Keel app or the REST API directly for file evidence. |
| keel_list_webhooksA | List the workspace webhook subscriptions, with "id", "targetUrl", "event" and "createdVia". The signing secret is never returned. |
| keel_create_webhookA | Subscribe a target URL to Keel events. Use event "all" to receive every event. The URL must be a public HTTPS endpoint — the API rejects http://, localhost and private network addresses. |
| keel_delete_webhookA | Delete a webhook subscription by id. Idempotent — deleting an id that does not exist also succeeds, so a success result does not prove a subscription was removed. Call keel_list_webhooks to confirm. |
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 18 tools
Each tool maps to a distinct resource and action; there is no meaningful overlap between list, create, delete, and upsert operations. The few convenience names like whoami and readiness are also unambiguous.
All tools share the keel_ prefix and mostly follow a verb_noun pattern such as list_risks, create_task, and delete_webhook. keel_whoami and keel_readiness are minor deviations from that pattern.
18 tools is slightly above the typical well-scoped range, but the broad Keel GRC domain of risks, vendors, tasks, policies, evidence, people, and webhooks justifies the count. Each tool appears to serve a purpose with no obvious filler.
The set is read-and-create heavy but lacks update and delete operations for core entities like tasks, risks, vendors, and policies, which are common lifecycle actions in a GRC workflow. Evidence file upload is also unsupported, requiring fallback to external tools.