cybershield
Server Details
CyberShield - 12 cybersecurity tools: NIS2 mapping, MITRE ATT&CK, vulns, threat intel.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- ToolOracle/cybershield
- GitHub Stars
- 0
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.2/5 across 12 of 12 tools scored. Lowest: 2.2/5.
Each tool targets a distinct security domain: compliance (ISO, NIS2, DORA), risk assessment, incident response, threats, phishing, password policy, etc. No two tools have overlapping purposes; descriptions clearly differentiate them.
All tool names use snake_case with a descriptive, often domain-first pattern (e.g., cve_risk_score, iso27001_gap). The naming convention is uniform, making it easy to infer each tool's focus.
With 12 tools, the set is well-scoped for a cybersecurity advisory server. Each tool covers a key area without redundancy or bloat, fitting a typical range of 3-15 tools for focused servers.
The tool surface covers major security assessment and compliance needs (risk, regulations, incidents, threats). Minor gaps exist (e.g., no tool for vulnerability scanning or network assessment), but the core workflow is well-supported.
Available Tools
12 toolsattack_surface_checkCInspect
Attack surface assessment checklist. Web apps, remote access, cloud, IoT, email. Prioritized security checks.
| Name | Required | Description | Default |
|---|---|---|---|
| iot_devices | No | ||
| cloud_services | No | ||
| employee_count | No | ||
| web_applications | No | ||
| remote_access_vpn | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It does not disclose whether the tool is read-only, destructive, requires authentication, or what side effects occur. It only labels itself as a 'checklist' without behavioral details.
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?
Description is a single sentence that front-loads the purpose and lists key categories. It is concise but lacks structure (e.g., no bullet points or sections). Could be improved but is not 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?
With no output schema, annotations, or parameter descriptions, the description leaves significant gaps. It does not explain what results are returned, how to interpret 'prioritized security checks', or whether input combinations are meaningful. Incomplete for a tool with 5 parameters.
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 0%, but description partially compensates by listing categories that map to 4 of 5 parameters (web apps, remote access, cloud, IoT). However, 'employee_count' is not mentioned, and no parameter details (e.g., how booleans affect output) are provided.
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 is for 'attack surface assessment checklist' and lists specific areas (web apps, remote access, cloud, IoT, email), giving a clear purpose. It distinguishes from sibling tools focusing on specific risks or compliance by being a broad assessment.
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. No mention of prerequisites, ideal scenarios, or exclusions. The description simply implies general security assessment use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cve_risk_scoreCInspect
CVE risk prioritization combining CVSS, EPSS, KEV catalog, exploit availability. Returns weighted priority score with patching SLA.
| Name | Required | Description | Default |
|---|---|---|---|
| cve_id | No | ||
| cvss_score | No | ||
| epss_score | No | 0-1 EPSS probability | |
| in_kev_catalog | No | ||
| public_exploit | No | ||
| internet_facing | No | ||
| affected_systems | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits. It only states what it combines and returns, but does not mention whether it is read-only, requires network access, or if it modifies any data. The behavioral profile remains opaque.
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 gets straight to the point. It front-loads the key purpose and return value. However, it could be slightly more structured with separate mentions of inputs and outputs.
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 return value is vaguely described as 'weighted priority score with patching SLA,' leaving out specifics like format or range. No output schema exists, so the description should compensate. Additionally, with 7 optional parameters and no required ones, the tool's behavior around missing inputs remains unclear.
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 description coverage is only 14% (only epss_score described). The description hints at the factors (CVSS, EPSS, KEV, exploit) but does not map them to specific parameters or add meaning beyond their names. For example, it does not clarify how `internet_facing` or `affected_systems` influence the score.
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 it performs CVE risk prioritization by combining CVSS, EPSS, KEV, and exploit availability. This distinguishes it from sibling tools like 'risk_matrix' which is more general. However, it does not explicitly mention that it operates on a single CVE ID.
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 is provided on when to use this tool versus alternatives like 'risk_matrix' or 'threat_landscape'. The context implies it is for CVE-specific risk assessment, but explicit usage context is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
dora_ict_riskCInspect
DORA Art. 5-12 ICT risk management compliance check. 8 articles assessed with specific requirements per article.
| Name | Required | Description | Default |
|---|---|---|---|
| learning_evolving | No | ||
| response_recovery | No | ||
| detection_measures | No | ||
| ict_risk_framework | No | ||
| communication_plans | No | ||
| ict_asset_inventory | No | ||
| protection_prevention | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'compliance check' but does not disclose whether the tool is read-only, requires authentication, or has side effects. This is insufficient.
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 efficiently conveys the core purpose. However, it lacks structure such as listing the 8 articles or detailing output format.
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 7 boolean parameters, no output schema, and no annotations, the description is severely incomplete. It does not explain how to interpret results, the meaning of each parameter, or the tool's behavior.
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 7 boolean parameters with zero description coverage, and the tool description does not explain any parameter meaning. The description adds no value beyond the field names.
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 a compliance check for DORA articles 5-12, specifically ICT risk management. Among siblings like nis2_compliance, this is distinct and unambiguous.
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 use for assessing compliance requirements per article, but does not provide explicit guidance on when to use this tool over alternatives or mention any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
incident_playbookBInspect
Incident response playbook for ransomware, data breach, phishing compromise. Phase-by-phase actions with legal obligations.
| Name | Required | Description | Default |
|---|---|---|---|
| incident_type | No | ransomware | data_breach | phishing_compromise |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations provided, so the description bears full responsibility for behavioral transparency. The description implies the tool returns information (actions, legal obligations) but does not state whether it is read-only, if it makes any changes, or if it requires permissions. For a tool that likely retrieves static playbook content, this is a minor gap but still leaves uncertainty.
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 purpose and content without extraneous words. It is front-loaded and efficient, earning 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?
Given the tool's simplicity (one optional parameter, no output schema), the description adequately covers what it does and what it produces. It could potentially mention that output is textual or structured, but the mention of 'phase-by-phase actions' gives a reasonable expectation. It is nearly complete for its complexity level.
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 description coverage is 100%, as the single parameter has a description listing the allowed values. The tool description reiterates these types but does not add additional meaning beyond the schema. The baseline of 3 is appropriate since the schema already documents the parameter well.
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 provides an incident response playbook for specific incident types (ransomware, data breach, phishing compromise) and mentions phase-by-phase actions with legal obligations. This is a specific verb-resource combination that distinguishes it from siblings, as no other tool in the list offers playbooks.
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 does not provide any guidance on when to use this tool versus alternatives. It does not mention prerequisites, scenarios, or what to do if the incident type is not listed. The sibling tools include many incident-related items (e.g., phishing_indicators, risk_matrix), but no contrast is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
iso27001_gapBInspect
ISO 27001:2022 Annex A gap analysis. All 93 controls across 4 themes, new 2022 controls highlighted, certification process.
| Name | Required | Description | Default |
|---|---|---|---|
| controls | No | Optional: status of specific controls |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full behavioral disclosure. It only describes the content (controls, themes, certification) but does not disclose behavior such as whether the tool is read-only, what it returns, or any side effects. Critical behavioral traits are missing.
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 packs in scope, themes, highlights, and process. It is concise and front-loaded with key information, though slightly more structure could improve readability.
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 the complexity of a gap analysis with 93 controls and certification process, the description lacks details on output format, how highlights are presented, and steps to use the tool. Without an output schema, more complete contextual information is needed.
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 one optional nested object parameter 'controls' with a description that matches the schema's own description. Since schema coverage is 100%, the baseline is 3, and the 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?
The description clearly states it is an ISO 27001:2022 Annex A gap analysis covering all 93 controls across 4 themes, highlighting new 2022 controls, and mentions certification. This distinctly identifies the tool's purpose and differentiates it from sibling compliance tools.
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 for ISO 27001 gap analysis but provides no explicit guidance on when to use or when not to use this tool versus alternatives like nis2_compliance or dora_ict_risk. The context is implied but not directly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
nis2_complianceBInspect
NIS2 Directive (EU 2022/2555) compliance assessment. All 10 Art. 21 measures, entity classification, penalties, incident reporting.
| Name | Required | Description | Default |
|---|---|---|---|
| sector | No | ||
| mfa_deployed | No | ||
| access_control | No | ||
| employee_count | No | ||
| risk_management | No | ||
| incident_handling | No | ||
| business_continuity | No | ||
| cryptography_policy | No | ||
| annual_turnover_meur | No | ||
| supply_chain_security | No | ||
| cyber_hygiene_training | No | ||
| vulnerability_management | No | ||
| incident_reporting_process | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full burden. It does not disclose whether the tool is read-only, what computations are performed, how results are returned, or any side effects. Only states the high-level purpose.
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?
A single sentence that packs key information without extraneous words. Could be improved by separating concerns (purpose, parameters, output) but is efficient overall.
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?
Despite having 13 parameters and no output schema, the description is very brief. It does not explain what the tool returns (e.g., a compliance score, report, or list of gaps) nor how to interpret the boolean inputs. For a tool of this complexity, more detail is needed.
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 description coverage is 0%, so the description must compensate. It mentions 'All 10 Art. 21 measures' and 'entity classification' but does not map specific parameters to these concepts. Some parameters (e.g., sector, annual_turnover_meur) are implied by 'entity classification' but not explicitly linked.
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?
Clearly states it is a compliance assessment for EU NIS2 Directive, covering specific articles (Art. 21), entity classification, penalties, and incident reporting. This distinguishes it from siblings like 'dora_ict_risk' or 'iso27001_gap' which address different regulatory frameworks.
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 siblings or when not to use it. Does not provide context about prerequisites, required vs optional parameters, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
nis2_incident_reportCInspect
NIS2 incident notification template. 24h early warning, 72h notification, 1-month final report templates.
| Name | Required | Description | Default |
|---|---|---|---|
| severity | No | ||
| incident_type | No | ||
| affected_services | No | ||
| cross_border_impact | No | ||
| affected_users_estimate | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not disclose any side effects, authentication needs, or whether the tool creates, stores, or sends reports. Behavioral impact is unclear.
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?
One sentence, but extremely brief and omits essential details. While concise, it sacrifices completeness.
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, no annotations, and parameter descriptions missing. The description fails to provide a complete picture of what the tool does or returns.
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?
0% schema description coverage. The description does not explain any of the 5 parameters (severity, incident_type, etc.), which is crucial for correct invocation.
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 states it's a 'NIS2 incident notification template' with deadlines, but does not explicitly state whether it creates, retrieves, or fills templates. The verb is implied, lacking specificity.
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 siblings like nis2_compliance or incident_playbook. No context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
password_policyAInspect
Generate password policy per NIST SP 800-63B (2024) and BSI recommendations. Modern best practices — no forced rotation.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully convey behavior. It mentions the policy follows specific standards and includes 'no forced rotation', but does not describe what output is returned, whether the operation is safe/mutative, or any other behavioral traits. The description is minimally informative.
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 conveys all necessary information. There is no wasted text.
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 the tool has no inputs and no output schema, the description is nearly complete. It states what the tool generates and which standards it follows. However, it could be slightly improved by briefly describing the output format.
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?
There are no parameters, and schema coverage is 100% by default. The description does not need to add parameter information. The baseline for 0 parameters is 4, and the description meets this.
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 generates a password policy, specifies recognized standards (NIST SP 800-63B 2024, BSI recommendations), and highlights modern best practices. It is distinct from sibling tools which cover other security and compliance topics.
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 the tool is used to obtain a password policy, but it does not explicitly state when to use it versus alternatives or provide any exclusions. There is no guidance on context or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
phishing_indicatorsAInspect
Analyze email/URL for phishing indicators. Scores sender, urgency, attachments, URL patterns. Returns verdict and recommended actions.
| Name | Required | Description | Default |
|---|---|---|---|
| subject | No | ||
| sender_email | No | ||
| suspicious_url | No | ||
| creates_urgency | No | ||
| asks_for_credentials | No | ||
| has_unexpected_attachment | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, but description covers main behaviors: scoring sender, urgency, attachments, URL patterns, and returning verdict/actions. Does not mention that it is read-only or non-destructive, but no contradictions.
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 and key details. No wasted 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?
Covers core functionality, inputs, and outputs (verdict and recommended actions). Could mention that all parameters are optional or that tool is read-only, but still adequate for selection.
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 description coverage is 0%, so description compensates by listing scoring categories (sender, urgency, etc.) which map to parameters like sender_email, creates_urgency. However, no per-parameter details beyond implied mapping.
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?
Clearly states it analyzes email/URLs for phishing indicators, scores various aspects, and returns verdict and actions. Distinguishes from siblings focused on different security areas.
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 for phishing analysis but provides no explicit when-to-use, when-not-to-use, or alternative tools. Lacks guidance on context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
risk_matrixBInspect
Risk assessment matrix (likelihood × impact). ISO 31000/27005 methodology. Provide risks for assessment or get template.
| Name | Required | Description | Default |
|---|---|---|---|
| risks | No | JSON array [{name, likelihood(1-5), impact(1-5)}] |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes the methodology but does not disclose whether the tool is read-only, what it returns, or any side effects. The description adds little beyond the name.
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: first defines the tool, second states usage options. No wasted words; information is 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?
For a simple single-parameter tool with no output schema, the description covers purpose and parameter usage. However, it omits return format or structure, leaving the agent to guess the output of 'assessment' vs 'template'.
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% and already documents the 'risks' parameter. The description adds value by explaining that omitting risks returns a template, which clarifies optional behavior not in 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 identifies it as a risk assessment matrix using ISO 31000/27005 methodology, and states it can assess provided risks or return a template. It distinguishes from sibling tools which are more specific (e.g., CVE, DORA). However, the verb is implicit and could be more direct.
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 says 'Provide risks for assessment or get template' but gives no guidance on when to prefer this over sibling tools like cve_risk_score or dora_ict_risk. No exclusions or context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
security_metricsBInspect
Security KPI/metrics dashboard template. MTTD, MTTR, patch compliance, phishing rate. Board-ready reporting guidance.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It states 'dashboard template' but does not disclose whether the tool performs a read operation or has side effects. There is no mention of authentication, rate limits, or output behavior (e.g., whether it generates a report or returns raw data).
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 short sentences. The first sentence states the tool's purpose and key metrics; the second adds context about board readiness. 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?
Given no output schema, the description should clarify what the tool returns. It mentions 'dashboard template' and 'reporting guidance' but not whether it returns a static template, placeholder values, or live data. Completeness is adequate for a simple tool but leaves ambiguity.
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 zero parameters, so the description need not explain params. It adds value by listing the metrics included (MTTD, MTTR, patch compliance, phishing rate). For a parameterless tool, this is sufficient, though it could elaborate on the template's structure.
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 identifies the tool as a security KPI/metrics dashboard template, listing specific metrics like MTTD, MTTR. This distinguishes it from sibling tools (e.g., attack_surface_check, cve_risk_score) which are more granular. However, the term 'dashboard template' lacks specificity about whether it returns data or a skeleton.
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 phrase 'Board-ready reporting guidance' implies a use case for executive reporting. However, no explicit guidance is provided on when to use this tool versus alternatives like threat_landscape or risk_matrix. There is no mention of prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
threat_landscapeAInspect
Current cyber threat landscape overview per ENISA categories. Top 8 threats with sector relevance and mitigations.
| Name | Required | Description | Default |
|---|---|---|---|
| sector | No | energy|finance|healthcare|manufacturing|public_admin|general |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions 'current' and 'ENISA categories' but does not explain data source, update frequency, or limitations. The behavior is partially transparent but lacks detail.
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 is concise and front-loaded with the key action. It could be slightly more structured but is efficient.
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 the tool's simplicity (one optional parameter, no output schema, no annotations), the description covers the main aspects: what it does, the categories, and what it returns (threats, relevance, mitigations). It is mostly 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?
The schema covers the sector parameter fully with an enum description. The description adds 'sector relevance' but no additional semantic meaning beyond the schema. Baseline 3 is appropriate.
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 specifies the tool's purpose: providing a current cyber threat landscape overview based on ENISA categories, listing top 8 threats with sector relevance and mitigations. It distinguishes from siblings like attack_surface_check and cve_risk_score.
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 for getting a broad threat overview but does not explicitly state when to use this tool over alternatives like incident_playbook or risk_matrix. No exclusions or conditions are mentioned.
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!