mcp-keelgrc

Official

by Keel-GRC

Overview Schema Related Servers Score Discussions

JavaScript

Remote

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.2.0
Disambiguation5/5
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.
Naming Consistency4/5
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.
Tool Count4/5
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.
Completeness3/5
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.
Average 4.1/5 across 18 of 18 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does reveal the core side effect: creating a vendor in the register, and it usefully specifies the return contract (new vendor id and tier). However, it does not disclose whether duplicate names are rejected, whether authorization is required, whether the operation is idempotent, or what happens on validation failure.
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 two short sentences with no filler or redundant phrasing. Every sentence earns its place: the action and scope are stated first, and the return value is captured in the second sentence. It is appropriately sized for a simple create operation.
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?
The tool has 7 parameters, no output schema, and no annotations, yet the description only covers the action and a partial return value. It does not explain how the optional fields interact, what defaults apply beyond tier, or how errors are surfaced. An agent could make a minimal call with 'name', but would be under-informed for richer vendor creation scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 43%, so the description needed to compensate for the many undocumented fields (notes, status, website, contactEmail, etc.), but it does not mention any input parameters at all. The schema already describes name, tier, and dataAccess, but the remaining parameters are left unexplained by both the schema and the description. With low schema coverage and no compensation, this dimension is weak.
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 states a specific verb ('Add'), a resource ('vendor'), and a scope ('workspace vendor register'), making the tool's purpose unmistakable. It also calls out that the tool returns the new vendor id and tier, which is a concrete outcome. This sufficiently distinguishes it from siblings like keel_list_vensors or other create_* tools.
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 implies when to use the tool (when a vendor needs to be added) but offers no explicit guidance regarding prerequisites, alternatives, or exclusion criteria. It does not name any sibling tool or explain when a different tool should be used instead. An agent is left to infer the usage from the verb and resource rather than being told.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. 'List' implies a read operation, but the description does not explicitly state that no data is modified, nor does it disclose pagination, ordering, rate limits, or auth prerequisites. It focuses almost entirely on output fields rather than behaviorial context.
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 a single sentence that starts with the core purpose ('List collected evidence') and then lists output fields. While the field list is long, it is relevant and compact. It earns its place because no output schema exists to carry that information. Minimal waste, though formatting could be cleaner.
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?
For a simple list tool with one optional parameter and no output schema, the description provides the return field names, which is helpful. However, it omits any statement about pagination, result size limits, ordering, or the 'since' filtering behavior (which is only in schema). It is adequate but not fully self-contained.
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 sole optional 'sinc e' parameter, so the input schema already documents the meaning. The description adds no additional parameter guidance, but it does not need to since the baseline of 3 applies when schema fully covers the parameter semantics.
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?
States the specific verb 'List' and resource 'collected evidence' and enumerates the exact fields returned. This clearly distinguishes it from every sibling list/create tool, so an agent can identify it without opening the schema. No ambiguity remains across the keel family.
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 does not explicitly mention alternatives or when-not-to-use exclusions. Usage is implied by the resource name and verb: to get collected evidence, use this tool. No competing list tool targets evidence, so an agent would likely infer correctly, but the description itself offers no explicit routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the behavioral disclosure burden. It does reveal the output field set, which is useful, and 'List' implies a read-only operation. However, it does not mention authentication needs, pagination, ordering, rate limits, or failure behavior, so behavioral transparency is only partially addressed.
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, dense sentence that front-loads the primary verb and resource, then lists the concrete output fields. Every part of the sentence contributes useful information, with no repetition or filler.
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?
For a simple list tool with one optional parameter and no output schema, listing the returned fields helps compensate for the missing output schema. Still, there is no mention of pagination limits, result ordering, or whether the list represents all personnel or only active ones, leaving minor but real gaps for an agent.
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?
The schema description coverage is 100%, so the single optional query parameter is already fully documented as a case-insensitive substring filter over name and email. The tool description adds no additional meaning beyond this, so the 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 tool's action ('List') and resource ('workspace personnel directory'), and enumerates the exact fields returned. This makes its purpose immediately distinguishable from sibling tools such as keel_whoami, keel_list_vendors, and keel_list_webhooks.
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?
There is no guidance about when to use this tool versus its alternatives, no mention of prerequisites, and no exclusions. The only clue is the tool's name and the sibling list, which requires the agent to infer the right context on its own.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral transparency burden. It does disclose a useful quirk: the status field is named 'state' and lists its allowed values. However, it does not mention read-only expectations, pagination, ordering, or whether the result set is limited in any way.
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 compact and front-loaded with the core purpose. The field enumeration and the state-value caveat are both useful and are stated without wasted words or 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?
For a simple list operation with one optional parameter and no output schema, the description covers the returned fields and the important state-value nuance. It lacks only generic list-behavior details such as pagination or explicit read-only confirmation, which are minor given the tool's simplicity.
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?
The single optional 'query' parameter has 100% schema description coverage, so the schema already explains it as a case-insensitive substring filter. The tool description adds no additional parameter semantics, making the baseline score of 3 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 uses a specific verb, 'List', and names the exact resource, 'workspace security controls'. It distinguishes itself from sibling list tools like keel_list_policies and keel_list_evidence by clarifying which workspace objects it returns. It also enumerates the item fields, leaving no ambiguity about what a control is.
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 is given about when to use this tool versus its siblings, such as keel_list_policies or keel_list_evidence. An agent must infer the intended use from the resource name and description. There are no exclusions, prerequisites, or alternative routing hints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 clearly states a read-type 'List' behavior and specifies the returned fields, but it does not disclose ordering, pagination, default filters, whether only certain statuses are returned, or any permissions/rate-limit considerations.
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 focused sentence that states the operation, the resource, and the return fields with no unnecessary filler. It is concise and front-loaded.
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 simple one-parameter list tool with no output schema, the description's field enumeration plus the schema's query filter documentation is sufficient for correct invocation. Minor gaps such as pagination or ordering exist, but they are not critical for basic use.
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?
The single optional query parameter is fully documented in the input schema with 'Optional case-insensitive substring filter over the policy title.' Because schema_description_coverage is 100%, the description does not need to repeat this; the baseline of 3 applies and the description adds no parameter-level value.
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 ('workspace policies') and enumerates the returned fields, making the operation unmistakable. It is clearly distinct from sibling list tools such as keel_list_vendors or keel_list_risks because it names the exact resource.
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 intended usage is implied: use this tool to list workspace policies, and the resource name separates it from sibling list tools. However, there is no explicit guidance on when to choose this over alternatives, no exclusions, and no mention of prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 does disclose a key behavioral constraint: the API rejects http://, localhost, and private network addresses. But it does not mention idempotency, behavior for duplicate subscriptions, or response/error semantics, leaving several behavioral traits undisclosed.
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?
Two sentences with no filler. The core action is front-loaded, and each subsequent sentence adds a distinct piece of useful information (event option and URL requirement). It is perfectly sized for the tool's simplicity.
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 description adequately covers the key requirements for calling the tool: target URL and event selection. However, it omits what happens when the optional 'event' parameter is not supplied (no default behavior stated), and with no output schema, it doesn't mention what the API returns on success or failure. These gaps make it adequate but not complete.
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 schema descriptions already cover both parameters (100% coverage), so the baseline is 3. The description adds value by specifying the exact rejection behavior for non-public URLs, which goes beyond the schema's 'public HTTPS URL' phrasing, and it reinforces the 'all' event option.
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, 'Subscribe', and names the resource, 'a target URL to Keel events', making the tool's purpose immediately clear. It distinguishes itself from sibling tools like keel_delete_webhook and keel_list_webhooks by focusing on creation/subscription.
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 gives practical usage context: how to receive all events via event 'all' and the mandatory public HTTPS requirement. However, it does not explicitly say when to use this tool versus siblings like keel_list_webhooks or keel_delete_webhook, so the choice is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosure. It clearly scopes the operation to workspace-tracked vendors and enumerates all returned fields, giving the agent an accurate picture of the output. It does not mention sorting, pagination, or access requirements, but 'List' sufficiently signals a read-only operation.
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?
A single sentence that front-loads the verb and resource, then enumerates the returned fields. The field list is slightly long but directly useful since there is no output schema. No filler or unnecessary wording.
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 simple list tool with one optional parameter and no output schema, the description is nearly complete: it explains the return values explicitly and the schema handles the parameter. Minor omissions like default ordering or whether all statuses are included keep it from a perfect score.
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%, and the query parameter's description ('Optional case-insensitive substring filter over the vendor name') fully documents its meaning. The tool description adds no extra parameter context, so the baseline 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 states a specific verb ('List') and resource ('third-party vendors tracked in the workspace'), making the tool's function immediately clear. It also differentiates itself from sibling tools like keel_whoami and keel_readiness, which serve unrelated purposes.
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?
When to use the tool is implied by its clear purpose: if an agent needs the vendor list, this is the tool. However, there is no explicit guidance about when not to use it or why it should be preferred over alternatives, though sibling tools are obviously distinct in function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must cover behavior itself. It usefully discloses the return value (new risk id) and the 1-5 scale for likelihood/impact. However, it does not mention validation, defaulting behavior, permission requirements, or what happens on invalid input, so behavioral transparency is adequate but not rich.
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?
Two short sentences, front-loaded with the primary action and resource, followed by the most decision-relevant details (return value and scale). No filler or repetition of schema content.
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 straightforward create tool with a rich input schema, the description covers the core outcome (risk created, id returned) and the key value constraint. It is slightly thin on preconditions and error behavior, but it is complete enough for an agent to invoke the tool correctly given the detailed schema.
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 91%, so the schema already documents nearly all parameters. The description adds the 1-5 scale context, but that is already present in the schema descriptions for likelihood and impact. It does not add significant semantic value beyond 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 uses a specific verb ('Add') with a specific resource ('risk to the workspace risk register') and explicitly notes the return value. This clearly distinguishes it from sibling creation tools like keel_create_task and keel_create_policy without needing to inspect schemas.
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 makes it clear this tool is for creating risks in the risk register, which is sufficient context for selecting it over sibling create tools. It does not explicitly state when not to use it or name alternatives, but the resource-based framing provides clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It discloses what the tool returns (id, key, title), explains the key derivation rule, and reveals the important idempotent/upsert-like behavior that reusing a key targets an existing policy. It could go further by clarifying whether updating replaces or merges the existing policy, but it provides meaningful behavior beyond the schema.
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 two sentences with no filler. The primary action is front-loaded, and the second sentence delivers the most important caveat about key reuse. Every clause earns its place.
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 there is no output schema and no annotations, the description compensates by stating the return fields and the key identity rule. The input schema fully documents all parameters, including the markdown/description fallback and fields limits. It is not exhaustive about permissions or exact update semantics, but it is sufficient for an agent to invoke the tool correctly in most cases.
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?
Schema coverage is 100%, so the baseline is 3. The description adds genuine value by clarifying the key parameter: it is derived from the title when omitted, and because policies are identified by key, reusing one targets the existing policy. This is substantive semantic information not present in the schema 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?
The description states a specific verb and resource, 'Create a policy from Markdown', and clearly separates this from the read-only list_policies and other create_* siblings by naming the policy resource. It also adds the key-reuse behavior that makes the operation more than a plain create.
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 when to use the tool: when a policy should be created from Markdown. However, it does not explicitly name alternatives or state when not to use it, such as when merely listing or deleting policies. The sibling tools are all distinct resources, so the usage context is inferable but not explicitly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description correctly carries the behavioral burgen. It reveals the critical edge case that an unparseable dueAt is silently ignored, and tells the agent to send valid ISO-8601 or omit it. It also clarifies the return value. It does not describe error responses or authorization, but this is sufficient for a simple create operation.
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 two sentences long with no filler. The action is front-loaded, the return value is stated, and the important edge case is appended compactly. Every sentence earns its place.
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 simple create tool with three flat parameters and no output schema, this description is nearly complete. It covers the operation, the return contract, and the one non-obvious behavioral trap. It does not discuss authentication or error stauses, but those are rarely essential for a straightforward create call.
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?
Schema description coverage is 100%, so the schema already documents all three parameters. The description adds meaningful behavior beyond the schema by warning about the silent handling of invalid dueAt values. This extra guidance goes beyond the baseline for a fully documented 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 and resource: 'Create a compliance task in the workspace.' It also specifies the return value, 'Returns the new task id,' which removes ambiguity. The resource is distinct from sibling tools like keel_create_risk or keell_create_vendor, so an agent can tell it apart.
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 usage is implied by the name and description: use it to create a compliance task rather than list tasks or create other entities. It does not explicitly state when to prefer it over alternatives, nor list excluded cases. This is adequate but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It notably states that the signing secret is never returned, which is a key safety/privacy guarantee. It also lists the exact fields returned, giving a clear picture of the tool's behavior. A simple read-only list tool needs no more than this.
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?
Two concise sentences. The first sentence front-loads the action and resource, the second adds a single crucial caveat. Every word earns its place; no filler.
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 zero-parameter list operation, the description covers the resource, the key response fields, and an important behavioral guarantee. It does not mention pagination, but that may not apply, and the sibling context clarifies the tool family. Overall it is complete enough for correct invocation.
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 tool has zero parameters, so the baseline for this dimension is 4. The description adds no parameter semantics because none are needed; the input schema is empty and fully covered.
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 ('List') and resource ('workspace webhook subscriptions'), and explicitly enumerates the returned fields. This distinguishes it from sibling tools like keel_create_webhook and keel_delete_webhook, which handle mutation of the same resource.
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 when to use the tool: whenever webhook subscriptions need to be listed. However, it does not explicitly mention alternatives or state when not to use it, leaving the routing logic to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral transparency burden. It discloses a non-obvious idempotency behavior: deleting a non-existent id still succeeds, so success does not prove removal. This is valuable context beyond what the schema shows, though it does not cover auth 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. The core action is front-loaded, and the critical idempotency caveat plus verification step are presented compactly in the second sentence.
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?
For a simple single-parameter delete operation with no output schema, the description is complete enough. It explains the action, the surprising success semantics, and how to confirm the outcome, covering everything an agent needs to invoke and verify the call.
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?
The input schema already documents the only parameter, id, as 'The webhook subscription id to remove' with 100% coverage. The description's 'by id' adds little beyond the schema, so 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?
The description uses a specific verb and resource: 'Delete a webhook subscription by id.' It is unambiguous and clearly distinguishes this tool from siblings like keel_create_webhook and keel_list_webhooks.
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 gives actionable guidance by warning that a success result does not confirm deletion and explicitly recommends calling keel_list_webhooks to verify. It does not explicitly list when not to use the tool, but the single-purpose delete operation makes that less critical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It covers return contents thoroughly and discloses the exact sort order (status first, then level, then score) with an illustrative example. It does not mention pagination, authentication, or error behavior, but for a zero-parameter list tool this is strong transparency.
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 efficiently structured: the core purpose is front-loaded, followed by the complete field list and then the sorting rule. Every sentence contributes useful information and there is no redundant filler.
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?
For a simple list tool with no parameters and no output schema, the description fully compensates by naming all return fields and specifying ordering. An agent has enough context to invoke the tool and interpret the result without further clarification.
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 tool has zero parameters and the schema coverage is 100%, so there are no parameter semantics for the description to add. The description instead adds value by explaining the output structure, which is the most relevant semantic information for this call.
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 names a specific verb ('List') and a specific resource ('the workspace risk register'), and enumerates the fields returned, so an agent can distinguish it from sibling list tools such as keel_list_vendors or keel_list_controls. The scope is unambiguous.
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 clearly implies this tool should be used when the agent needs the contents of the risk register. However, it does not explicitly say when to prefer this over sibling list tools or mention any exclusions or preconditions, so usage guidance is reasonable but only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and does it well. It discloses idempotency, the 'created' response field, and the significant edge case that IdP-synced people are not updated. This goes well beyond a bare verb+resource 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 two tight sentences with no filler. The core purpose is front-loaded, and the idempotency and identity-provider behavior are stated efficiently.
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 7-parameter mutation tool with no annotations and no output schema, the description is largely complete: it covers behavior, idempotency, and a key edge case. It loses a point because several parameters receive no description-level guidance, leaving agents to rely on parameter names and the enum values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 29%, and the description does not compensate by explaining the five undocumented parameters. Only email identity-key behavior is implied by the prose. The remaining parameters have self-evident names but the description adds no semantic detail beyond 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 states a specific action ('Add a person to the workspace directory, or update them if the email already exists') tied to a clear resource and an upsert semantic. It is unambiguous and easily distinguished from sibling tools like keel_list_people.
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 makes clear when to use the tool: to add a person or update an existing manually-created person. It also gives an explicit when-not: records synced from an identity provider are returned unchanged. It does not name an alternative tool, but none is obviously needed among the siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description correctly carries the behavioral disclosure burden. It reveals a meaningful limitation: multipart file upload is unsupported by this stdio server and routes the user elsewhere. It could additionally state what the tool returns or what happens on duplicate links, but the disclosed constraint is valuable and accurate.
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?
Two compact sentences: the first states the core action, the second adds the critical limitation and alternative. Every sentence earns its place and the key scope constraint is front-loaded.
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 simple link-attachment tool, the description covers what the tool does, its scope, and its main exclusion. The parameter schema covers the remaining invocation details. It does not describe response/return behavior, but no output schema exists and the action is simple enough that this is not a significant gap.
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?
The input schema already documents all four parameters with clear descriptions, so the schema-description coverage is high. The tool description adds only that a control target is optional, which is already visible in the schema. It does not clarify the difference between controlId and controlKey, but the schema descriptions handle that adequately.
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+resource pair ('Attach a URL as evidence') and immediately scopes itself to link-only evidence, distinguishing it from general evidence creation or file upload tools. It also names the optional control target. This is clearly differentiated from sibling evidence/control tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool (link evidence only) and when not to use it (file evidence), and names the alternatives: the Keel app or the REST API. That is an explicit when/when-not/alternatives statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No anotations are provided, so the description carries the burden. It goes beyond a simple statement by listing exact output fields and status enum values. It doesn't discuss pagination or ordering, but for a read-only list with no parameters, this is adequate transparency.
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, front-loaded sentence. It conveys the operation, resource, and output structure without wasted words, making it easy to scan.
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 no output schema, the description provides the complete return-value shape, including field names, status values, and assignee fields. For a zero-parameter listing tool, this is sufficient for an agent to call it correctly.
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 tool has zero parameters, so the baseline is 4. The description need not explain parameter semantics, and the input schema confirms no parameters exist.
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 opens with a specific verb, 'List', and a clear resource, 'workspace compliance tasks'. It enumerates the item's fields, making the tool's purpose unambiguous and distinguishing it from sibling list tools targeting different resources.
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 provides clear context: use this tool to retrieve workspace compliance tasks. It doesn't explicitly mention alternatives, but the list of sibling tools makes the distinction obvious, and there is no competing task-listing tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the exact return fields, including types ('readiness' as percent integer), and the framework scoping constraint. It doesn't state auth, rate limits, or errors, but for a no-parameter read endpoint this is a solid level of disclosure.
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?
Two sentences with no filler: the first states purpose and scope, the second enumerates the response fields. Every part adds value and the most important scoping caveat is front-loaded.
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?
For a simple no-parameter read endpoint with no output schema, the description is fully self-sufficient: it identifies the exact framework, clarifies the exclusion, and lists every return field. Nothing an agent needs to decide to call this tool is missing.
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 tool takes zero parameters and the schema is empty, so there are no parameter semantics to explain. The description implicitly confirms this by not mentioning any inputs, and per the baseline for 0-param tools, no additional description is needed.
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?
States a specific verb ('Get') and resource ('audit-readiness summary for ISO/IEC 27001:2022'), and explicitly narrows the scope to that framework only, distinguishing it from any workspace-applied framework. The sibling tools are all different resources (whoami, list vendors, controls, etc.), so this description clearly identifies what this tool does.
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 clearly communicates when to use this tool: when you need the readiness summary specifically for ISO/IEC 27001:2022, not the framework the workspace has applied. It doesn't name alternative tools for other frameworks, but the sibling list shows no overlapping readiness tools, so the exclusion is sufficient context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of conveying behavior. It transparently states the operation (verify API key, return connected organization) and explains the tier field's possible values. It does not discuss error cases like invalid keys, but for a zero-parameter read-only identity tool this is a minor 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?
The description is a compact single sentence that front-loads the core purpose and immediately states when to use the tool. It includes only necessary information—return shape, tier enum, and usage guidance—with 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?
For a tool with no parameters, no annotations, and no output schema, the description is fully self-contained: it names the operation, gives the exact JSON response shape, enumerates the tier values, and provides clear usage context. An agent has everything needed to call it correctly and interpret the result.
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 tool has zero parameters, so the baseline is 4; there is no parameter meaning the description needs to add. The schema already covers all params vacuously, and the description appropriately skips param documentation in favor of output details.
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 states a specific verb ('Verify') and resource (API key / connected Keel organization), and specifies the exact returned structure including id, name, and tier with plan values. This clearly distinguishes it from sibling tools like keel_list_vendors or keel_create_task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs 'Use this first to confirm which workspace you are acting on,' providing a clear when-to-use directive. Even though no alternatives are named, the identity-check nature of the tool makes this guidance decisive and sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![keelgrc-mcp MCP server](https://glama.ai/mcp/servers/Keel-GRC/keelgrc-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Keel-GRC/keelgrc-mcp)

Score Badge

Copy to your README.md:

[![keelgrc-mcp MCP server](https://glama.ai/mcp/servers/Keel-GRC/keelgrc-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Keel-GRC/keelgrc-mcp)

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/Keel-GRC/keelgrc-mcp'

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