Watchdog for unattended AI agents: alerts, evidence checks and a verifiable proof per run.
Acknowledge an alert by id.
| Name | Required | Description | Default |
|---|---|---|---|
| alert_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states that an alert is acknowledged, implying a state change, but does not disclose side effects, idempotency, authorization requirements, or what happens if the alert is already acknowledged.
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 one short, front-loaded sentence with no filler or repetition. It could be considered under-specified from a completeness standpoint, but as a concise statement of the core action it is appropriately efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and a schema that does not describe its parameter, the description is too sparse to fully enable correct invocation. An agent may not know the meaning of acknowledgement, the return value, error conditions, or the workflow for obtaining an alert_id.
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 0% description coverage and only specifies that alert_id is an integer. The description adds 'by id,' which loosely relates the parameter to the operation, but it does not explain how to obtain a valid alert_id, what range or meaning it has, or any constraints beyond the schema's type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Acknowledge an alert by id.' This clearly identifies the action and target, and it distinguishes this tool from siblings like runvouch_alerts and the run-lifecycle tools, which focus on other operations.
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 gives no guidance on when to use this tool versus alternatives, nor does it mention prerequisites such as where to obtain an alert_id. It implies 'use when you want to acknowledge an alert,' but does not provide workflow context or direct the agent to a sibling like runvouch_alerts for finding alert IDs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open (un-acknowledged) alerts: MISSED, FAILED, NO_EVIDENCE, BUDGET_RUN, BUDGET_DAY, RETRY_STORM, DRIFT, STALLED.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool readOnlyHint=true, so the safety profile is covered. The description adds behavioral detail by stating that only un-acknowledged alerts in specific categories are surfaced, but it does not disclose response shape, pagination, or what differentiates this from runvouch_status.
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 compact sentence with no filler, and the scope condition is stated before the category list. The category list is long but necessary for precision, so the overall density is good.
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 zero-parameter, read-only listing tool, the description names the exact output categories and the open/un-acknowledged filter, which is enough for an agent to invoke it correctly. It would be more complete with an explicit statement of what the response contains, but the low complexity reduces the need.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and 100% schema description coverage, so there is nothing for the description to explain. Per the zero-parameter baseline, a 4 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 identifies the resource (alerts) and narrows scope to open/un-acknowledged ones, enumerating eight concrete alert types. It lacks an explicit verb like 'list' or 'retrieve', and 'open' is ambiguous between adjective and command, so it doesn't fully meet the highest bar.
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 given about when to use this tool instead of siblings such as runvouch_ack, runvouch_status, or runvouch_runs. The alert category names imply a monitoring use case, but the description never states selection criteria or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report that a run ended, with status and evidence dict (name -> bool or {type:'url',url}). Green run without evidence alerts.
| Name | Required | Description | Default |
|---|---|---|---|
| cost | No | ||
| run_id | Yes | ||
| status | No | ||
| tokens | No | ||
| evidence | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It mentions one behavioral consequence ('Green run without evidence alerts') but does so ambiguously, and it omits output behavior, idempotency, failure cases, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The first sentence is concise and front-loaded, which is good. However, the second sentence is cryptic ('Green run without evidence alerts') and needs more clarity to be genuinely useful, so not every sentence earns its place effectively.
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 five parameters, nested evidence objects, no annotations, and no output schema, the description is too thin for an agent to invoke the tool confidently. It lacks guidance on return values, alert behavior, and how this endpoint fits into the overall run lifecycle.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning beyond the raw schema. It usefully explains the evidence dict format (name -> bool or {type:'url',url}), but it says nothing about cost, tokens, or the required run_id, leaving several parameters underspecified.
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 a clear action — 'Report that a run ended' — with a specific resource and relevant payload (status and evidence). It is understandable in isolation, though it does not explicitly distinguish itself from siblings like runvouch_run_proof or runvouch_status.
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?
There is no guidance on when to call this tool versus runvouch_run_start, runvouch_run_proof, or runvouch_status. The phrase 'Green run without evidence alerts' hints at a condition but does not clearly state when to use the tool or which alternative to prefer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tamper-evident proof of a finished run: hashed record, Merkle path, day root, chain hash and OpenTimestamps status. Verify offline with templates/verify_proof.py.
| Name | Required | Description | Default |
|---|---|---|---|
| run_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already covers the safety profile, and the description adds meaningful context beyond it: the internal structure of the proof (Merkle path, day root, chain hash) and the offline verification path. It also implies the run must be finished for the proof to exist. This is useful behavioral context, with no contradiction of the annotation.
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 sentences totaling roughly 30 words, with the core purpose front-loaded and zero filler. The first sentence defines the deliverable and its contents; the second provides the actionable verification pointer. 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?
For a simple read-only tool with a single parameter and no output schema, the description covers the essential ground: it lists what the proof contains (serving as the return-value description) and how to verify it offline. Minor gaps remain — the source of run_id and behavior for unfinished runs — but both are reasonably inferable from 'proof of a finished run.'
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, with only an undocumented required run_id string, so the description carries the documentation burden. It partially compensates by establishing that the proof concerns 'a finished run,' making it clear run_id refers to that run's identifier. However, it never explicitly names or explains the parameter, its format, or how an agent might obtain a valid run_id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource — a tamper-evident proof bundle for a finished run — and enumerates its contents (hashed record, Merkle path, day root, chain hash, OpenTimestamps status), which distinguishes it from siblings like runvouch_status and runvouch_runs. However, the primary action verb is implicit; it never explicitly states whether the tool generates, retrieves, or returns the proof.
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?
Usage context is implied: 'proof of a finished run' signals the tool is for completed runs and the verification workflow is described via 'verify offline with templates/verify_proof.py.' However, no sibling tools are named and there is no explicit statement of when to choose this over runvouch_status or runvouch_runs, leaving tool-selection guidance to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent runs of one agent.
| Name | Required | Description | Default |
|---|---|---|---|
| agent | Yes | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already communicates that this is a safe read operation, and the description does not contradict it. The description adds minimal context ('recent', 'one agent'), but does not disclose ordering, time window, pagination, or how limit affects results. With annotations covering the safety profile, this is acceptable but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a five-word fragment with zero filler words and no wasted structure. Every word contributes meaning, and the key scoping ('one agent') is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no parameter descriptions, the description must carry more weight. It fails to explain what a 'run' looks like in the result, how 'recent' is defined, or what limit controls. An agent can likely make a basic call, but it cannot fully anticipate the response or the semantics of the optional parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the bare schema. It only maps 'one agent' to the agent parameter and says nothing about the format or required identifier. The limit parameter is entirely unmentioned, leaving its role as page size, maximum count, or truncation unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource ('recent runs') and its scope ('one agent'), which lets an agent distinguish it from siblings like runvouch_run_start/end/proof and runvouch_status. However, it lacks an explicit verb such as 'list' or 'retrieve', so it falls just short of a 5.
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 given on when to use this tool versus alternatives like runvouch_alerts or runvouch_status. It is only implicit that this is a history/query tool, with no explicit when-to-use, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report that a run of agent started. Returns run_id.
| Name | Required | Description | Default |
|---|---|---|---|
| agent | Yes | ||
| source | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the return value and the fact that this reports a start event, but does not say whether the call persists data, whether it is idempotent, what side effects occur, or how `run_id` is produced. This leaves significant behavioral ambiguity.
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 with no wasted words. It states the core action and key return information in a front-loaded manner, making it easy to parse quickly.
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?
There is no output schema and no annotations, so the description must compensate; it does not. Missing details include parameter semantics (`source`), behavioral side effects, how `run_id` is generated or returned, and how this tool relates to the sibling lifecycle tools like `runvouch_run_end`.
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 only clarifies that `agent` refers to the running agent. The `source` parameter is completely unexplained, and no guidance is given about the relationship between the two parameters or their expected formats.
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 names a specific action—reporting that a run of `agent` started—and notes the return value `run_id`. This clearly distinguishes the tool from siblings like `runvouch_run_end`, though it does not explicitly name its sibling counterpart.
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 `runvouch_run_end`, `runvouch_run_proof`, or other sibling tools. The intended use is implied by the name and description, but no context, exclusions, or alternatives are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Health of all watched agents: state (ok/alert/failed/unproven/running/waiting), last run, 24h cost, open alerts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, and the description adds useful context: it is a read-only snapshot covering all watched agents with specific state values and time/cost fields. There is no contradiction with annotations. It does not mention ordering or response shape, but for a no-parameter, read-only status tool this is adequate.
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 one compact, front-loaded sentence followed by a colon-delimited list of returned content. It wastes no words while conveying scope and the main output fields. This is a model of efficient tool description.
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 zero parameters, readOnly annotations, and no output schema, the description supplies the key return dimensions (state, last run, 24h cost, open alerts), which is enough for an agent to call and interpret the result. Missing details like sorting or pagination are immaterial for a no-argument status snapshot.
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?
This tool has zero parameters, so the schema is trivially 100% covered and there is nothing for the description to add about inputs. Per the calibration baseline, zero-parameter tools receive a 4 because input semantics are moot.
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 names the resource ('all watched agents') and the exact content categories (state, last run, 24h cost, open alerts). It clearly signals a health/status snapshot tool and is distinguishable from siblings like runvouch_alerts or runvouch_runs. The only minor gap is the lack of an explicit verb like 'Get' or 'List', but the intent is 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 explicit 'when to use' guidance or named alternatives, which matters because siblings like runvouch_alerts and runvouch_runs cover overlapping content. The description implies this is the general overview tool, but it does not state exclusions or selection conditions. An agent can infer likely usage, but the guidance is not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
runvouch_ackrunvouch_alertsrunvouch_run_endrunvouch_run_proofrunvouch_run_startrunvouch_runsrunvouch_statusClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
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
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
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.
No comments yet. Be the first to start the discussion!
Monitoring that agents set up for themselves — cron jobs, CI/CD pipelines and AI agent runs.
Pre-execution governance for AI agents. Deterministic PASS/FAIL/REVIEW verdicts, replayable proof.
Bitcoin-anchored, tamper-evident audit log for AI agents — record, disclose and verify actions.
Dead-man switch monitors for cron & AI agents with dependency-cascade alerts. No account needed.
Add one secure layer between your agents and this server.
Tools target distinct resources (alerts, runs, status, proofs), but runvouch_alerts and runvouch_status both surface open alerts, and runvouch_runs overlaps somewhat with runvouch_status's run-history display. Descriptions are specific enough to prevent serious misselection.
All tools share the runvouch_ prefix, but the style mixes bare verbs (runvouch_ack), noun lists (runvouch_alerts, runvouch_runs), and noun-verb compounds (runvouch_run_start, runvouch_run_end). The names are readable, but there is no single consistent verb_noun convention.
Seven tools is a well-scoped size for a run-vouching/alerting server. Each tool serves a clear operational purpose: starting/ending runs, retrieving proof/history, and managing alerts.
The core lifecycle is covered: start run, end run with evidence, retrieve proof, list runs, check status, list/ack alerts. Minor gaps exist such as no detailed alert/run getter or evidence modification, but agents can complete main workflows without dead ends.
