protectwith-kb
Server Details
AI-security knowledge as MCP: standards-mapped tools (OWASP, NIST, MITRE) for AI agents.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.5/5 across 8 of 8 tools scored. Lowest: 2.9/5.
Each tool has a clearly distinct purpose: checklist generation, text classification, compliance mapping, single entity retrieval, listing, framework ID mapping, relationship traversal, and semantic search. No two tools overlap in functionality.
All tools share the 'kb_' prefix, but the suffixes mix verbs (classify, get, list, search) with nouns (checklist, compliance_map, map, related). This inconsistency, especially having two 'map' variants, reduces predictability.
Eight tools are appropriate for a knowledge base server, covering core operations (get, list, search) and specialized functions (checklist, classify, compliance, mapping, relationships). Not too few or too many.
The tool set covers essential read-only operations for a security knowledge base: retrieval, listing, search, classification, compliance mapping, and relationship traversal. Minor gaps like filtered search or batch operations are acceptable for this scope.
Available Tools
8 toolskb_checklistBInspect
Build an actionable security checklist of controls and guidance for a described component, query, or segment. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Optional tag filters (reserved for future use) | |
| query | No | Natural-language description of the component to review | |
| segment | No | Segment identifier to scope the checklist (e.g. 'llm-app') |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states 'Read-only,' which is positive but insufficient. No mention of side effects, permissions, or output behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no fluff. The core action and read-only nature are front-loaded, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a three-parameter tool with no output schema or annotations, the description is minimally adequate. It explains the tool's purpose and read-only nature, but omits output format and usage context, leaving gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description mirrors the parameter names without adding new meaning. It does not clarify parameter interactions or constraints, such as whether query and segment are mutually exclusive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool builds an actionable security checklist for a component, query, or segment, using strong action verbs. It distinguishes itself from sibling tools like kb_search or kb_classify by focusing on checklist generation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lacks guidance on when to use this tool versus its siblings. It does not mention when not to use it or provide context for choosing it over alternatives like kb_search or kb_compliance_map.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
kb_classifyAInspect
KB-grounded advisory threat classification for a piece of text. Returns the top-k matching threats with recommended controls. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| k | No | Number of threat matches to return (default 3) | |
| text | Yes | Text to classify against known threats |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. States 'read-only' and describes return type, but does not disclose potential errors, rate limits, or side effects. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with front-loaded purpose. No redundant text; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and no annotations, so description should compensate. Does not specify return format structure (e.g., fields like threat name, controls, severity) or error handling. Incomplete given tool complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (both parameters have descriptions). Description adds no new meaning beyond what schema provides, maintaining baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'classify' with specific resource 'KB-grounded threats' and output 'top-k matching threats with recommended controls'. Differentiates from siblings like kb_list or kb_search by focusing on threat classification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies use case ('advisory threat classification') but no explicit guidance on when to choose over siblings or when not to use. Lacks alternatives and exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
kb_compliance_mapAInspect
Map security controls to compliance requirements they satisfy (e.g. SOC 2, ISO 27001, NIST). Optionally filter by framework. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Natural-language query to find relevant controls (used when control_ids is not provided) | |
| framework | No | Filter compliance results to a specific framework (e.g. 'SOC 2', 'ISO 27001', 'NIST') | |
| control_ids | No | Explicit list of control IDs to map |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It explicitly labels the operation as 'Read-only', which is helpful. However, it does not mention any other behaviors such as pagination, performance, or response structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence that front-loads the action and purpose. Every word is necessary, with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 optional parameters and no output schema or annotations, the description covers the essential: purpose, read-only nature, optional filter. It could hint at the output format (e.g., list of mappings) to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage for parameters is 100%, so the baseline is 3. The description adds no extra meaning beyond the schema; it merely restates the optional filtering by framework, which is already described in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Map' and clearly identifies the resource ('security controls to compliance requirements') with concrete examples (SOC 2, ISO 27001, NIST). It distinguishes itself from sibling tools like kb_map by specifying the domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states the core action and optional filtering but provides no guidance on when to use this tool versus alternatives like kb_list or kb_search. The context is clear but lacks exclusions or recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
kb_getAInspect
Fetch one entity by its id. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Entity id |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It declares read-only behavior adequately but does not disclose error handling (e.g., missing ID) or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the verb and resource. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is simple (one parameter, no output schema). Description covers the core operation adequately for a basic fetch but could mention return format for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage for its single parameter 'id' described as 'Entity id.' Description adds no additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Fetch one entity by its id,' with a specific verb and resource. Sibling tools like kb_list and kb_search imply distinct actions, so differentiation is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
States 'Read-only,' indicating appropriate use. Does not explicitly state when not to use or list alternatives, but sibling tool names provide context. Lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
kb_listBInspect
List all entities of a given type. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | Entity type (e.g. 'threat', 'control', 'cloudflare') |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only mentions 'Read-only,' which is minimal. No disclosure about pagination, limits, or response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the purpose. However, it could include more contextual details without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 parameter and no output schema, the description adequately tells the agent the action and read-only nature. Missing optional details like ordering.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the single parameter 'type' with examples. The description adds no extra meaning beyond the schema, so baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all entities of a given type' with a specific verb and resource, and the 'Read-only' note adds context. It distinguishes from siblings like kb_get and kb_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 versus alternatives. The sibling tool names imply different operations, but the description doesn't differentiate them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
kb_mapBInspect
Map a framework external id (e.g. LLM01) to threat, controls, and Cloudflare primitives. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| external_id | Yes | Framework reference id (e.g. 'LLM01', 'OWASP-ML01') |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It mentions 'Read-only' to indicate no side effects, but fails to disclose authentication requirements, rate limits, or output format. The minimal disclosure is insufficient for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys the essential purpose and read-only nature. No unnecessary words or redundancy. Highly concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should hint at the return structure. It mentions mapping to 'threat, controls, and Cloudflare primitives' but does not specify if the output is a list, object, or other format. The tool has seven siblings, but the description does not clarify how this tool complements them or the scope of mapping.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage and already describes the parameter 'external_id' with examples. The description repeats an example ('e.g. LLM01') but adds no meaningful new information beyond what the schema provides. Baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Map' and the resource: mapping a framework external id to threats, controls, and Cloudflare primitives. It distinguishes from siblings like kb_get or kb_list by specifying a unique mapping operation, and explicitly notes it is read-only.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you need to map an external ID) and marks the tool as read-only, but it does not explicitly state when to use this tool versus alternatives like kb_search or kb_get. No exclusions or when-not scenarios are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
kb_searchBInspect
Semantic search over the security knowledge base. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| k | No | Number of results to return (default 5) | |
| type | No | Filter results to this entity type (e.g. 'threat') | |
| query | Yes | Natural-language search query |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description marks the tool as read-only, a key behavioral trait. With no annotations provided, this disclosure is helpful but lacks additional details such as rate limits, authentication requirements, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (two sentences) and front-loaded with the core purpose, wasting no words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is brief and covers the essential context (semantic search, read-only). However, without an output schema, it does not clarify the return format or default behavior, leaving some gaps for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters. The description adds no new information beyond the schema, so it meets the baseline. The phrase 'semantic search' aligns with the query parameter description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs semantic search over a security knowledge base and is read-only. The verb 'search' and resource are explicit, but it does not differentiate from sibling tools like kb_list or kb_get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description only notes it is read-only, but does not specify scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!