dora
Server Details
DORAOracle — 15 tools for DORA Art.5-32: risk register, ICT incidents, TLPT, third-party.
- 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.6/5 across 15 of 15 tools scored.
Most tools have clearly distinct purposes, but 'cve_latest' and 'cve_search' both deal with CVEs, and 'kev_check'/'kev_list' overlap slightly; however, descriptions help differentiate them.
All tool names consistently use snake_case with a noun_noun or verb_noun pattern, e.g., 'breach_check', 'cve_search', 'dora_calendar'. No mixing of conventions.
15 tools is well-scoped for a DORA compliance server, covering incident assessment, threat monitoring, CVE, KEV, third-party risk, regulatory news, and more without being overwhelming.
The tool set covers all key DORA domains: incident reporting, threat intelligence (CERT, CVE, KEV), third-party risk, cloud status, regulatory news, and TLPT scenarios. No obvious gaps for an information aggregation tool.
Available Tools
15 toolsbreach_checkAInspect
HaveIBeenPwned breach database — check domain/company breach exposure. DORA Art. 18 incident assessment.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results 1-50 (default: 20) | |
| domain | No | Company domain e.g. 'meinbank.de' (optional — omit for latest breaches) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It only states the basic function (check exposure) without disclosing behavioral traits like rate limits, data freshness, authentication needs, or side effects. The description is too minimal for a tool with zero annotations.
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 succinct sentences: first states source and purpose, second adds regulatory context. No unnecessary words, front-loaded with key information.
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?
Accompanied by a clear name and input schema with defaults. Description explains purpose and context (DORA Art. 18). Lacks details about output structure (no output schema), but for a simple lookup tool with optional parameters, it is reasonably 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 is 100% with descriptions for both parameters (limit, domain). The tool description adds minimal extra meaning beyond the schema, only mentioning the regulatory context and the source. 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?
Clearly states the tool checks domain/company breach exposure using the HaveIBeenPwned database, with a specific regulatory context (DORA Art. 18). This distinguishes it from sibling tools like cve_search or kev_check, which focus on vulnerabilities.
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 usage for breach exposure checks and DORA incident assessment, but does not provide explicit guidance on when to use versus alternatives or when not to use it. No exclusions or alternative tool mentions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cert_advisoriesAInspect
CERT-Bund security advisories — authoritative DE source for ICT threats. DORA Art. 17 threat monitoring.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results 1-30 (default: 15) | |
| keyword | No | Filter by keyword e.g. 'Windows', 'Apache', 'Cisco' |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description lacks behavioral details such as data freshness, rate limits, authentication requirements, or any side effects. Only basic purpose and source are mentioned.
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-load the key information: source and use case. Every word adds value with no redundancy.
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 has no output schema and 2 parameters. Description covers primary purpose and source but fails to explain return format, ordering, or how results are paginated. Adequate but could be more complete for a simple 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?
Input schema covers 100% of parameters with descriptions for limit and keyword. Description adds no additional semantic context beyond the schema, meeting baseline for high coverage.
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 the tool as CERT-Bund security advisories, an authoritative German source for ICT threats, and ties it to DORA Article 17 threat monitoring, distinguishing it from sibling tools like CVE-specific or breach 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?
Description implies usage for DORA Art. 17 monitoring but does not explicitly state when to use this tool over alternatives like cve_latest or breach_check. No exclusions or prerequisites provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cloud_statusBInspect
Live status of AWS, GCP, Azure cloud providers. DORA Art. 28 third-party ICT risk monitoring.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max incidents per provider (default: 10) | |
| provider | No | Provider: aws, gcp, azure, all (default: all) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. The phrase 'Live status' is vague; it doesn't specify whether the tool performs network calls, whether it is read-only, rate limits, or what constitutes 'status' (e.g., incidents, outages, metrics).
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 exceptionally concise, consisting of two relevant sentences with no fluff or repetition. Every word adds value: the first sentence identifies the core function and the second adds regulatory context.
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 absence of output schema and annotations, the description is incomplete. It fails to explain what the output represents (e.g., list of incidents, status codes), how to interpret results, or any usage constraints. The DORA reference lacks explanation, limiting agent understanding.
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%, so the input schema already documents both parameters (limit, provider) with defaults and allowed values. The description adds no additional meaning or usage tips beyond what the schema provides, meeting the baseline.
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 explicitly states 'Live status of AWS, GCP, Azure cloud providers' which clearly conveys the tool's function: retrieving real-time health information from major cloud providers. The mention of 'DORA Art. 28 third-party ICT risk monitoring' adds regulatory context and helps distinguish it from sibling tools focused on specific security advisories or vulnerabilities.
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 checking cloud provider status but provides no explicit guidance on when to use this tool versus alternatives (e.g., breach_check, cve_latest). It lacks when-not scenarios or prerequisites, leaving the agent to infer context from the tool name and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cve_latestAInspect
Latest critical CVEs — daily DORA ICT risk briefing. Filter by severity and banking relevance.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Last N days (default: 7) | |
| limit | No | Max results 1-20 (default: 10) | |
| severity | No | CRITICAL, HIGH, MEDIUM (default: CRITICAL) | |
| banking_only | No | Filter to banking-relevant vendors only (default: false) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose behavioral traits such as read-only nature, rate limits, authentication needs, or how data is retrieved. The description carries the full burden for transparency but fails to address it.
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 no redundant information. Each sentence serves a clear purpose: stating the tool's core function and then listing filtering capabilities.
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 all parameters documented in the schema and no output schema, the description provides sufficient context for a simple query tool. However, it lacks usage guidelines and behavioral transparency, which are needed given the absence of annotations.
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?
All 4 parameters are described in the input schema (100% coverage), so the description adds minimal value beyond context. The mention of 'severity and banking relevance' reinforces the 'severity' and 'banking_only' parameters but does not clarify types or constraints 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 the tool retrieves 'latest critical CVEs' and positions it as a 'daily DORA ICT risk briefing'. It mentions filtering by severity and banking relevance, which differentiates it from the sibling 'cve_search' tool that likely supports broader historical 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?
The description implies use for daily risk briefings but lacks explicit guidance on when to use this tool versus alternatives like 'cve_search'. No exclusions or prerequisite conditions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cve_searchBInspect
Search CVEs by keyword, vendor or product. Returns CVSS scores, attack vectors, DORA pillar mapping.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Published within last N days (default: 30) | |
| limit | No | Max results 1-20 (default: 10) | |
| vendor | No | Vendor/product e.g. 'SAP', 'Cisco', 'Microsoft Exchange' | |
| keyword | No | Search keyword e.g. 'authentication bypass', 'remote code execution' | |
| severity | No | CVSS severity: CRITICAL, HIGH, MEDIUM, LOW |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavioral traits. It mentions output contents but not safety (read-only), potential side effects, rate limits, or authentication needs. Basic transparency is present but 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?
Single sentence, front-loaded with verb and resource, no unnecessary words. Highly concise.
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 search tool with 5 parameters and no output schema, the description is too brief. It omits return structure, pagination, how filters combine, and other behavioral details needed for correct usage.
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, so baseline is 3. The description adds 'DORA pillar mapping' not in schema, but does not clarify parameter interaction (e.g., AND/OR logic). Minimal added meaning.
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 searches CVEs by keyword, vendor, or product and returns specific information like CVSS scores and DORA mapping. It distinguishes from siblings like cve_latest which likely returns latest CVEs without 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?
The description implies usage for searching CVEs by given criteria but provides no explicit guidance on when to use this versus siblings like cve_latest or kev_check, nor any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
dora_calendarAInspect
DORA compliance milestones and upcoming deadlines for financial institutions. All Art. references included.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It indicates the tool returns milestones, deadlines, and Art. references, but does not disclose read-only nature, data source, or update frequency. Adequate but minimal.
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 purpose, adding one specific detail about Art. references. No fluff.
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, so description should explain return structure. It mentions milestones, deadlines, and Art. references, but misses format, date style, or ordering. Partially complete for a simple 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?
No parameters exist, so baseline is 4. Description does not need to add param info; schema coverage is trivially 100%.
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 'DORA compliance milestones and upcoming deadlines for financial institutions,' which is specific (verb+resource) and distinguishes it from sibling tools like breach_check or cve_latest.
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, nor any prerequisites or exclusions. The description simply states what it does without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
dora_newsBInspect
EBA/DORA regulatory news for banks. Topics: general, eba, incident, third_party, testing, guidelines, bafin, swift.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language: en or de (default: en) | |
| limit | No | Max articles 1-20 (default: 10) | |
| topic | No | Topic: general, eba, incident, third_party, testing, guidelines, bafin, swift, fintech |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description does not disclose behavioral traits like data freshness, read-only status, or rate limits. Only lists topics, lacking deeper behavioral context.
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?
Extremely concise single sentence with essential topic list. No wasted words; front-loaded with purpose.
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 with no output schema. Description covers purpose and topics but omits details about return format or pagination. Adequate but not 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?
Input schema has 100% parameter description coverage. The description's topic list adds some context but largely duplicates schema information. No additional meaning beyond 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 the tool retrieves EBA/DORA regulatory news for banks and lists specific topics. It distinguishes from sibling tools like breach_check or cve_latest, which cover different regulatory 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?
No guidance on when to use this tool vs alternatives. Lacks context for selection, such as when to prefer dora_news over other compliance tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
health_checkAInspect
DORAOracle server status and all backend connectivity checks.
| 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 carries the burden of behavioral disclosure. It indicates a read-only operation checking status and connectivity, which is transparent for a simple health check. However, it does not detail potential latencies or side effects, but these are minimal and expected.
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, front-loaded sentence of 12 words that contains all necessary information without any fluff.
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 health check tool with no parameters and no output schema, the description sufficiently covers what the tool does (server status and backend checks). It is complete given the tool's simplicity.
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%. The description does not need to add parameter information. A baseline of 4 is appropriate since there are no parameters to explain.
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 checks DORAOracle server status and all backend connectivity, specifying both the verb and resource. It distinguishes from sibling tools that focus on specific security or advisory checks.
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 checking server health and connectivity but does not provide explicit guidance on when to use versus alternatives, nor when not to use it. There are no exclusions or references to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
incident_timelineAInspect
Generate DORA-compliant ICT incident reporting timeline with exact deadlines. DORA Art. 19 major incident workflow.
| Name | Required | Description | Default |
|---|---|---|---|
| sector | No | Sector: banking, insurance, payment (default: banking) | |
| incident_time | No | ISO timestamp of incident e.g. '2026-03-19T14:00:00Z' (default: now) | |
| classification | No | Incident class: major, significant, minor (default: major) |
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 behavioral traits (e.g., read-only vs. mutation, auth requirements, error handling, or any side effects). Merely states 'generate' without clarifying side effects or constraints.
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-loading the core action and regulatory context. No extraneous words; every sentence 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?
Adequate for a simple tool with well-documented parameters, but lacks details about the output timeline structure or examples. Could be expanded to clarify what the timeline includes (e.g., milestones, deadlines).
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 clear parameter descriptions (sector, incident_time, classification). Description adds no additional semantic value beyond what the schema already provides, and the default values are specified 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?
Description clearly states 'Generate DORA-compliant ICT incident reporting timeline with exact deadlines', specifying the verb 'generate' and the resource 'timeline' with regulatory context. It distinguishes from sibling DORA tools like 'dora_calendar' or 'dora_news' by focusing on incident reporting deadlines.
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 usage for DORA Art. 19 major incident workflow but offers no explicit 'when to use' or 'when not to use' guidance. Does not mention alternatives or exclusions, leaving the agent to infer context from the DORA mention.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
kev_checkAInspect
Check if a specific CVE is in CISA KEV (actively exploited in the wild). Returns DORA incident classification guidance.
| Name | Required | Description | Default |
|---|---|---|---|
| cve_id | No | CVE ID to check e.g. 'CVE-2021-44228' (Log4Shell) |
Tool Definition Quality
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 discloses the core function (checking KEV and returning DORA classification) but lacks details on side effects, rate limits, authorization needs, or data freshness. For a read-only check, it is adequate but not thorough.
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 sentences, front-loaded with the core check, followed by return information. 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 the tool's simplicity (one parameter, no output schema), the description covers the main function and return type. It does not specify output format or edge cases, but is fairly complete for a single-purpose check.
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 the only parameter (cve_id) having a description. The description does not add additional meaning beyond the schema for the parameter itself. It mentions return classification but that is about output, not parameter semantics.
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 'Check if a specific CVE is in CISA KEV' and specifies the resource. It also mentions the return of DORA incident classification guidance, distinguishing it from siblings like kev_list and cve_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?
The description indicates when to use the tool (to check a specific CVE against KEV), but does not explicitly state when not to use it or compare alternatives. However, with sibling names like kev_list and cve_search, the context is understood.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
kev_listAInspect
CISA Known Exploited Vulnerabilities — actively exploited CVEs with patch deadlines. DORA Art. 9 patch compliance.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Added to KEV within last N days (default: 30) | |
| limit | No | Max results 1-50 (default: 15) | |
| vendor | No | Filter by vendor e.g. 'Cisco', 'Microsoft', 'SAP' | |
| overdue | No | Show only overdue patches (default: false) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description carries full burden. It states the tool shows active CVEs with deadlines but omits behavioral traits (e.g., read-only, caching, whether it queries live API). Basic but not misleading.
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?
Single sentence, no fluff. Could be slightly more structured (e.g., separate purpose from compliance context), but 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?
No output schema, but tool is relatively simple. Description could clarify what the result includes (e.g., CVE IDs, deadlines) and how it relates to compliance. Leaves some gaps for a 4-param 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 covers 100% of parameters with descriptions. Description adds no extra meaning beyond schema (e.g., does not clarify 'overdue' deadline or formatting of 'days'). Baseline score 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?
Title 'kev_list' combined with description clearly indicates listing known exploited vulnerabilities. Distinguishes from sibling kev_check (likely for individual checks) and other breach/threat 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?
Description hints at DORA compliance use case but does not explicitly state when to use kev_list over siblings like kev_check, breach_check, or cve_latest. Lacks direct guidance or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mitre_techniquesBInspect
MITRE ATT&CK techniques for DORA TLPT / TIBER-EU penetration testing. Maps to DORA Art. 26.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results 1-20 (default: 10) | |
| tactic | No | Filter by tactic: Initial Access, Lateral Movement, Impact, Persistence, etc. | |
| keyword | No | Search keyword e.g. 'ransomware', 'phishing', 'credential' |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only mentions domain relevance. It does not disclose behavioral traits like read-only nature, rate limits, or what the output contains (e.g., technique IDs, descriptions).
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?
Very concise with two short sentences. Front-loaded with purpose. Could be slightly more structured but 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?
No output schema exists, and the description fails to mention what the tool returns (e.g., technique names, IDs, descriptions, or how results are structured). Leaves agent guessing about response 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?
All three parameters have schema descriptions, and the description adds no extra meaning beyond 'Maps to DORA Art. 26', which does not directly enhance parameter understanding. 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 states the tool retrieves MITRE ATT&CK techniques specifically for DORA TLPT/TIBER-EU penetration testing and maps to DORA Article 26. It distinguishes itself from sibling tools like cve_search or threat_actors.
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 such as breach_check, threat_actors, or tlpt_scenarios. The description does not provide 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.
provider_riskAInspect
DORA Art. 28 ICT third-party risk assessment: CVE history, news, GLEIF registration, contractual checklist.
| Name | Required | Description | Default |
|---|---|---|---|
| provider | No | Provider name e.g. 'SAP', 'Salesforce', 'AWS', 'Temenos' |
Tool Definition Quality
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 lists components but does not disclose behavioral traits such as whether data is live, any side effects, rate limits, or authentication needs. The tool appears to be a read-only assessment aggregator, but this is not explicitly stated.
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 of 15 words, front-loading the key regulatory reference and purpose. Every part is essential 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?
Given the lack of output schema and annotations, the description partially covers what the tool does. It lists assessment categories but does not explain the return format, data sources, or any behavioral nuances. Adequate but leaves 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?
The input schema has one parameter 'provider' with a description. The tool's description adds meaningful context by specifying the regulatory framework (DORA Art. 28) and the types of assessments conducted, going beyond what the schema provides.
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's purpose: 'DORA Art. 28 ICT third-party risk assessment' and lists specific components (CVE history, news, GLEIF registration, contractual checklist). This distinguishes it from sibling tools like cve_search or dora_news which focus on individual aspects.
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 third-party risk assessment under DORA but does not explicitly state when to use this tool versus alternatives. No guidance on prerequisites or exclusions is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
threat_actorsBInspect
Feodo Tracker: live C2 botnet servers (Emotet, QakBot, etc.). Actionable IP blocklist for DORA Art. 9.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results 1-100 (default: 20) | |
| status | No | Filter by status: online, offline | |
| malware | No | Filter by malware family: Emotet, QakBot, Dridex, TrickBot |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only mentions 'live C2 botnet servers' and 'actionable IP blocklist' but does not describe update frequency, pagination, rate limits, or response format, which are critical for a live data tool.
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 uses only two sentences, clearly front-loading the tool's purpose and key details. It could benefit from a more structured format (e.g., bullet points), but overall achieves conciseness without 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?
Without an output schema or annotations, the description lacks details on return format (e.g., IP addresses, timestamps), pagination behavior, or sorting. The mention of 'actionable IP blocklist' hints at the output, but completeness is only adequate for a simple list 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?
The input schema has 100% parameter descriptions. The tool description adds context by naming malware families (Emotet, QakBot) referenced in the 'malware' parameter, but does not significantly extend beyond the schema's own descriptions. Baseline 3 is appropriate given high schema coverage.
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 live C2 botnet server IPs from Feodo Tracker, specifically naming malware families like Emotet and QakBot. It distinguishes itself by emphasizing actionable IP blocklist for DORA Art. 9, setting it apart from sibling threat tools like cve_latest or kev_list.
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 compliance (DORA Art. 9) and threat intelligence, but does not explicitly state when to use this tool versus siblings like breach_check or kev_list. No guidance on alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tlpt_scenariosAInspect
TIBER-EU threat scenarios for DORA resilience testing planning. Banking-specific attack simulations.
| Name | Required | Description | Default |
|---|---|---|---|
| focus | No | Focus area: swift, ransomware, insider, ddos, cloud (default: all) | |
| sector | No | Sector: banking (default: banking) |
Tool Definition Quality
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 only states the tool offers scenarios for testing planning but does not disclose behavioral traits such as whether it performs reads or mutations, authorization requirements, or side effects. Minimal information beyond 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?
Two short sentences, no redundant words, and front-loaded with key information. Every sentence is necessary and quickly conveys the tool's purpose.
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 gives high-level context (TIBER-EU, DORA, banking) but lacks details on output format, number of scenarios, or expected behavior. For a simple lookup tool with no output schema, this may be minimally adequate but leaves gaps for an AI agent.
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%, so baseline is 3. The description does not add any additional meaning to the parameters beyond what the schema already provides (focus and sector with defaults). No param-specific guidance is given.
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 'TIBER-EU threat scenarios for DORA resilience testing planning. Banking-specific attack simulations.' This specifies the verb (provides scenarios), resource (TIBER-EU threat scenarios), and domain (DORA, banking), which distinguishes it from siblings like breach_check or cve_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?
The description implies usage for resilience testing planning in a banking context but does not explicitly state when to use this tool versus alternatives like mitre_techniques or threat_actors. No exclusions or when-not guidance is provided.
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!