doraeventfabric
Server Details
DORA OS EventFabric - 14-tool event stream for DORA compliance signals and pub/sub fabric.
- 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 2.8/5 across 14 of 14 tools scored. Lowest: 2/5.
Most tools have distinct purposes: rule management, event emission, subscription management, scheduling, webhook testing, and status monitoring. Potential overlap between 'health_check' and 'ping' but descriptions clarify health_check is more detailed. Overall clearly differentiated.
Naming conventions are mixed: some use verb_noun (create_rule, emit_event, list_schedules), others use noun_noun or adjective_noun (active_rules, event_log, health_check, webhook_status). 'Ping' is a single noun, inconsistent with others. The pattern is not fully consistent.
14 tools cover the key areas of event management: rules, events, subscriptions, schedules, webhooks, and health. The count is well-scoped and each tool serves a necessary function without redundancy.
Covers creation and listing for rules and subscriptions, but missing delete and update operations for rules and schedules. Also lacks a tool to list available event types or trigger an immediate scan. Some gaps but core workflows are functional.
Available Tools
14 toolsactive_rulesBInspect
Show all routing rules (event → Conductor action).
| 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 must carry the burden. It only states 'Show all routing rules', implying a read operation but without explicit declarations of side-effects, permissions, or rate limits. 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?
One short sentence that efficiently conveys the tool's purpose with a clarifying parenthetical. No wasted words or redundant 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?
For a parameterless tool that lists all routing rules, the description is concise and covers the essential action. However, with siblings that might also list events, the lack of differentiation hints at slight incompleteness. Still, given the tool's simplicity, it is adequately 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?
There are zero parameters, and schema coverage is 100% implicitly. The description adds no parameter information, but with no parameters, the baseline of 4 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?
Description clearly states the tool shows all routing rules with a parenthetical clarification of the mapping. It does not explicitly differentiate from siblings like 'create_rule' or 'event_log', but the verb 'show' and resource 'routing rules' imply a list operation, which is distinct enough.
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 (e.g., event_log or event_stats). The description lacks context for appropriate usage scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_ruleCInspect
Create custom routing rule.
| Name | Required | Description | Default |
|---|---|---|---|
| priority | No | ||
| event_type | No | ||
| description | No | ||
| conductor_action | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a write operation ('Create') but provides no information about side effects, idempotency, permissions required, or whether creation is additive vs. replacing existing rules. Without annotations, the burden falls entirely on the description, which falls short.
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 at 4 words, but this brevity sacrifices clarity and completeness. While not redundant, it fails to front-load necessary information that would help an agent decide whether to invoke this tool.
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, annotations, and parameter descriptions, the tool description is severely inadequate. It does not address return values, error conditions, or behavior constraints, leaving agents without critical execution context.
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%, and the description does not explain any of the four parameters (priority, event_type, description, conductor_action). Parameters are merely named in the schema with no additional meaning provided, leaving agents to guess their roles.
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 'Create custom routing rule' clearly states the action and resource, but lacks specificity. It does not distinguish whether this rule applies to events, subscriptions, or other routing contexts, leaving ambiguity when compared to sibling tools like 'emit_event' or 'subscribe'.
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 'active_rules' or 'emit_event'. The description omits any context about prerequisites, intended use cases, or situations where another tool should be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
emit_eventAInspect
Emit an event → auto-routes to Conductor based on rules. Types: cve_critical, cloud_outage, regulation_change, security_breach, sanctions_update, audit_notice, evidence_expired, drift_detected, sla_breach, finding_overdue, daily_check, weekly_drift_scan.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | ||
| source | No | Event source (webhook, internal, cron) | |
| entity_id | No | ||
| event_type | No | Event type (see types above) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond the schema by explaining that events are auto-routed to Conductor, but with no annotations, it fails to disclose important behavioral details such as idempotency, persistence, error handling, or whether events are logged, leaving the agent with incomplete knowledge of side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise, consisting of two short sentences that immediately convey the core action and event types. Every sentence adds essential information without 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?
Given the simplicity of the tool (no output schema, no required parameters), the description covers the main purpose and event types. Minor gaps remain around side effects (e.g., whether events are logged or states change), but it is largely sufficient for an emit action.
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 50% (source and event_type have descriptions, detail and entity_id do not). The description adds value by listing event types for the event_type parameter, but provides no additional information for detail or entity_id, failing to compensate for the missing schema descriptions.
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 'emit an event' and specifies that it auto-routes to Conductor based on rules, distinguishing it from siblings like 'event_log' (read-only) and 'create_rule' (rule creation). The list of specific event types further clarifies the scope.
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 emitting standard event types to trigger Conductor rules, but it lacks explicit guidance on when to use this tool versus alternatives (e.g., using webhooks directly) and does not provide when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
event_logCInspect
Query event history with filters.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| entity_id | No | ||
| event_type | 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 bear the full burden. It only implies a read operation ('Query') but lacks details on side effects, authorization, or performance implications.
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 (3 words) and front-loaded, but it sacrifices necessary detail for brevity. It could be restructured to include more information 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?
Given 3 parameters and no output schema, the description is woefully incomplete. It does not describe the output format, filter behavior, or any constraints, making it insufficient for correct tool invocation.
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?
With 0% schema description coverage, the description must clarify parameter meanings. It mentions 'filters' but does not explain any of the three parameters (limit, entity_id, event_type), leaving the agent to guess their roles.
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 'Query event history with filters,' providing a clear verb and resource. It distinguishes from siblings like emit_event (creation) and event_stats (statistics), indicating a read operation.
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, no context on prerequisites or limitations, and no explicit usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
event_statsCInspect
Event statistics: by type, source, status.
| 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, and the description lacks any behavioral details (e.g., read-only, destructive, auth needs, rate limits). It fails to convey the tool's operational characteristics.
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 short (one phrase), which is not sufficiently informative. Conciseness without completeness is detrimental.
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 and no annotations, the description should provide more details about return format or behavior, but it does not. It is wholly inadequate for a stats 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?
With zero parameters in the schema, baseline is 4, but the description implies filtering or breakdown by type, source, status, which contradicts the parameterless schema. This adds misleading 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 mentions 'Event statistics' and three dimensions (type, source, status), giving a vague sense of purpose. It is not a clear verb+resource statement and does not fully differentiate from siblings like event_log.
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 does not specify context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
health_checkCInspect
Server status.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description does not disclose behavioral traits such as whether the tool is read-only, its safety profile, or response format. For a health check, such details are critical.
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, consisting of two words. It is front-loaded but may be too brief to fully inform the agent.
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 simplicity (no parameters, no output schema), the description should at least clarify what 'Server status.' entails (e.g., boolean, JSON). It lacks completeness for effective tool 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?
The input schema is empty with 0 parameters, so the baseline is 4. The description does not need to add parameter info, and 'Server status.' is sufficient for the tool's purpose.
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 'Server status.' vaguely indicates the tool reports server health but lacks a specific verb+resource. It does not clearly distinguish from sibling tool 'ping' which likely serves a similar purpose.
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 like 'ping' or 'event_log'. The description provides no contextual hints for appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_schedulesCInspect
View scheduled scans.
| 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 convey behavioral traits. It only says 'View scheduled scans', implying a read operation but not stating whether it requires authentication, returns cached data, or has pagination. The agent has no insight into side effects or limitations.
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 concise (one sentence) but lacks substance. It provides only the bare minimum, which is acceptable for a simple query but insufficient for rich 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 annotations and output schema, the description should compensate. It does not mention return type, ordering, filtering, or any caveats. The description is incomplete for a tool that is one of many siblings.
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 tool has zero parameters, and schema coverage is 100%. Per guidelines, the baseline for 0 parameters is 4. The description adds no parameter info, but none is needed.
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 'View scheduled scans' specifies a clear verb-resource pair ('view' + 'scheduled scans') and distinguishes from siblings like 'schedule_scan' (create) and 'list_subscriptions' (webhook related). It could be more specific about what constitutes a 'scheduled scan', but it's effective.
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 such as 'schedule_scan' or other list tools. The description lacks context about prerequisites or scenarios, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_subscriptionsAInspect
Show all active subscriptions.
| 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 disclose behavioral traits. It only says 'Show', implying read-only, but does not explicitly state non-destructiveness, authentication requirements, or whether it returns a filtered list. The active scope is mentioned, but no additional traits like pagination or performance impact are covered.
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 immediately conveys the tool's purpose. It is front-loaded with the action and resource, with no extraneous words. Every part is necessary.
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 parameters, no output schema, and no annotations, the description is minimally sufficient but lacks detail. It does not describe the output format or what information a subscription includes, which could be important for an agent. For a simple list tool, this might be adequate, but more context would improve 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?
The input schema has no parameters, and schema coverage is 100% (all properties are accounted for). Per guidelines, 0 parameters sets a baseline of 4. The description adds no parameter information, which is acceptable since there are none to describe.
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 'Show all active subscriptions' uses a clear verb ('Show') and resource ('subscriptions'), and specifies the scope ('active'). This distinguishes it from sibling tools like 'subscribe' (creation) and 'unsubscribe' (deletion), making its purpose 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?
No guidance is provided on when to use this tool versus alternatives. Sibling tools like 'active_rules', 'list_schedules', 'webhook_status' exist, but no comparison or selection criteria are given. The description does not mention prerequisites, context, or when to avoid this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pingBInspect
Connectivity test.
| 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, and the description does not disclose any behavioral traits beyond being a test. It fails to mention whether the operation has side effects or requires permissions, leaving the agent without important safety 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?
The description is only two words, perfectly concise and front-loaded. Every word earns its place with no wasted content.
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 connectivity test with no parameters, the description is adequate but incomplete. It does not hint at the return value (e.g., success status or latency), which would be helpful for an agent relying on output.
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, so schema description coverage is effectively 100%. The description adds no additional meaning but none is required. Baseline score of 4 applies per rubric for zero-parameter tools.
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 'Connectivity test.' clearly states the tool's purpose with a specific verb and resource. However, it does not differentiate from the sibling tool 'health_check', which likely serves a similar function.
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 'health_check'. The description is entirely silent on usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
schedule_scanCInspect
Schedule periodic scans (daily_check, weekly_drift_scan).
| Name | Required | Description | Default |
|---|---|---|---|
| cron | No | Cron expression (default: 0 6 * * *) | |
| name | No | ||
| entity_id | No | ||
| event_type | 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 only says 'schedule periodic scans' without disclosing side effects, idempotency, or required permissions.
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 and very concise, but it lacks structure (e.g., no separate sections). It is not overly long, but could be more effective with brief details.
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 annotations, no output schema, and 4 parameters with minimal description, the description is incomplete. It fails to explain basic aspects like what a scan is or how results are obtained.
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 25%, and the description adds no detail about parameters beyond the examples. It does not explain cron, name, entity_id, or event_type, leaving the agent with insufficient context.
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 the tool schedules periodic scans and gives two examples (daily_check, weekly_drift_scan), making the verb and resource clear. It differentiates from siblings like list_schedules, but could be more explicit.
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 list_schedules or health_check. The description does not mention prerequisites or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
subscribeCInspect
Subscribe an oracle to an event type.
| Name | Required | Description | Default |
|---|---|---|---|
| tool | No | ||
| oracle | No | ||
| event_type | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only states the action without disclosing any behavioral traits such as side effects, idempotency, required permissions, or error conditions. Since no annotations are provided, the description carries the full burden, and it fails to inform the agent about the tool's behavior beyond the basic operation.
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 (5 words), but this brevity comes at the cost of informativeness. It does not earn its place because it fails to add value beyond the name. A good concise description would pack more useful information into a short space.
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 (3 parameters, no annotations, no output schema), the description is highly incomplete. It does not explain how parameters relate, what the tool returns, or any constraints. The agent would struggle to use this tool correctly based solely on the description.
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 three parameters (tool, oracle, event_type) with zero description coverage. The description only mentions 'oracle' and 'event_type' but omits 'tool' entirely, and provides no explanation of what each parameter represents or its expected format. This leaves the agent unable to correctly populate the parameters.
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 action (subscribe) and the objects (oracle, event type). It is specific and distinct from the sibling 'unsubscribe'. However, it is very brief and lacks additional context that could further improve clarity.
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 usage guidelines are provided. The description does not indicate when to use this tool, prerequisites, or alternatives. For example, it does not mention whether the oracle or event type must exist beforehand, or how this differs from other subscription-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
test_webhookCInspect
Simulate a webhook event to test routing.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | ||
| entity_id | No | ||
| event_type | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description fails to disclose any behavioral traits such as side effects, authorization requirements, or whether the event is actually sent. The word 'simulate' implies a test but gives no details on consequences.
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?
While short, the description is under-specified and sacrifices clarity for brevity. A single phrase is insufficient for a three-parameter tool with no other documentation.
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, no annotations, and 0% schema description coverage, the description is critically incomplete. The agent cannot reliably determine inputs, outputs, or side effects needed to use the 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 description coverage is 0%, and the description does not explain the three parameters (detail, entity_id, event_type). The agent has no semantic meaning for these fields, severely impairing 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?
Description uses a specific verb 'simulate' and identifies the resource 'webhook event' with a clear purpose 'to test routing'. However, it does not differentiate from sibling tools like emit_event or webhook_status, missing explicit comparison.
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, no prerequisites or context provided. The agent has no information about scenarios suitable for testing webhook routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
unsubscribeCInspect
Remove a subscription.
| Name | Required | Description | Default |
|---|---|---|---|
| subscription_id | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully disclose behavior. It only states 'Remove a subscription' without indicating whether it's destructive, reversible, or has side effects. Minimal disclosure.
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 at three words, but this brevity sacrifices content. It is front-loaded but too sparse to be fully helpful.
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 performs a removal action with one parameter and no output schema, the description lacks critical context like reversibility, impact on related data, or confirmation requirements. Incomplete for its 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 description coverage is 0% for the single param subscription_id. The description adds no meaning beyond the param name. It doesn't explain how to obtain the ID or its format.
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 'Remove a subscription' uses a specific verb and resource, clearly indicating the action. It distinguishes from siblings like subscribe (add) and list_subscriptions (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?
No guidance on when to use this tool versus alternatives (e.g., unsubscribe vs. deactivate?). No context provided for appropriate use cases or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
webhook_statusBInspect
Webhook health: events processed, rules active, supported types.
| 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 disclose behavioral traits. It mentions the data returned (events processed, rules active, supported types) but does not confirm if the operation is read-only, safe, or requires any authentication. Minimal behavioral context is provided.
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, consisting of a single phrase with no unnecessary words. Every word adds value.
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 parameterless tool, the description covers the three key aspects adequately. However, it could be improved by specifying if the status is real-time, what the output format looks like, or providing a brief example.
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 tool has zero parameters and schema coverage is 100%, so the description does not need to add parameter meaning. According to guidelines, 0 parameters yields a baseline of 4.
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 focus on webhook health and lists specific aspects (events processed, rules active, supported types), making its purpose evident. It distinguishes from sibling 'health_check' which is likely more general. However, lacking an explicit verb like 'get' or 'retrieve' slightly reduces clarity.
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 'health_check' or 'event_stats'. The description does not indicate situational appropriateness or prerequisites.
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!