Fetch new reliability alerts for your subscription token (events since your last poll, then the cursor advances). Use this after watch_tool without a webhook to react to outages/recoveries — no public endpoint required. Returns events with tool id, severity, and a link.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max events (default 50). | |
| token | Yes | The token returned by watch_tool. |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description explains the cursor advancement (events since last poll) and return fields (tool id, severity, link). It lacks details on rate limits or authentication requirements beyond the token, but the core behavior is transparent.
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, front-loaded with the action and resource, no wasted words. Each sentence adds meaningful 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?
The description explains the polling state (cursor advancement), return format, and prerequisite (watch_tool). For a simple tool with no output schema, it is sufficiently complete for an agent to use correctly.
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 both parameters (limit, token) with descriptions. The description adds value by explaining the token's origin from watch_tool and the default limit behavior, going 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 fetches new reliability alerts for a subscription token, specifying the resource (alerts) and action (fetch). It distinguishes itself from sibling tools like watch_tool (setup) and unwatch (teardown) by focusing on polling.
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?
Explicitly recommends using this after watch_tool without a webhook to react to outages/recoveries, and notes that no public endpoint is required. This provides clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool has a distinct, well-defined purpose: checking reliability, discovering tools, finding alternatives, getting recipes, routing tasks, etc. No two tools overlap in function.
All tool names follow a consistent verb_noun pattern with underscores (e.g., check_tool_reliability, route_task, watch_tool). The only minor deviation is 'how_to_use_glimind', which still follows a clear verb phrase convention.
With 15 tools, the set is well-scoped for a comprehensive meta-layer covering discovery, reliability checking, preparation, batch routing, reporting, and notifications. Each tool earns its place.
The surface covers the full workflow of discovering, checking, preparing, calling, and reporting on tools. A minor gap is the lack of a direct 'list all tools' catalog, but the discovery tools effectively fill this need.