Real-time error logging for Cloudflare Workers, Next.js & Vercel. Catch silent crashes, $500 cost spikes, and every AI call with logs inside Cursor & Claude.
Scored across 10 tools
Tools are mostly distinct, but there is minor overlap between get_ai_calls and get_ai_summary (both about AI usage, one individual, one aggregate), and between get_cost_summary and get_ai_cost_trend (both cost-related but different scopes). Descriptions clarify, so no real confusion.
All tools follow a consistent verb_noun pattern with snake_case, using get_ for retrieval, list_ for listing, query_ for search, and resolve_ for action. Naming is uniform and predictable.
10 tools is well-scoped for an observability server covering logs, AI usage, costs, and alerts. Each tool serves a clear purpose with no redundancy.
The surface covers logging (query, stats, errors, traces), AI metrics (calls, trends, summary), Cloudflare costs, and alert management (list, resolve). Minor gap: no direct tool to fetch a single log by ID, but query_logs with filters can achieve that.
Get recent individual AI/LLM calls with model, provider, tokens, cost, latency, and status. Helps answer 'what did my last AI calls look like?' or 'show me failed AI calls'.
| Name | Required | Description | Default |
|---|---|---|---|
| hours | No | Lookback hours (1-168, default 24) | |
| limit | No | Max results (1-200, default 50) | |
| model | No | Filter by model name (e.g., 'gpt-4o', 'claude-3-5-sonnet') | |
| provider | No | Filter by provider (e.g., 'openai', 'anthropic', 'workers-ai') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the tool returns individual calls with specific attributes and implies recency via 'recent' and the hours parameter. It does not disclose pagination behavior, ordering, or whether failed calls are included by default, but the schema covers the hours/limit mechanics. This is adequate 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?
Two sentences, front-loaded with the core action and return fields, followed by concrete example queries. Every sentence earns its place and there is zero 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?
For a read-only list tool with 100% schema coverage and no output schema, the description covers what the tool returns and when to use it. It could mention ordering (e.g., newest first) or that failed calls are included, but nothing critical is missing for an agent to call it 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 description coverage is 100%, so the schema already documents all four parameters. The description adds the context that these parameters filter the returned call list, but it does not add meaning beyond the schema's own descriptions. 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 states a specific verb ('Get') and resource ('recent individual AI/LLM calls') and enumerates the exact fields returned (model, provider, tokens, cost, latency, status). It also gives example natural-language queries, which makes the tool's purpose unmistakable. It is clearly distinct from siblings like get_ai_summary or get_cost_summary, which aggregate rather than list individual calls.
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 concrete example questions ('what did my last AI calls look like?' or 'show me failed AI calls') that signal when to use this tool. It does not explicitly name alternatives or state when not to use it, but the examples plus the sibling names make the intended context clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get hourly time-series of AI/LLM cost and call count. Helps answer 'is my AI spend trending up?' or 'when did my AI costs spike?'.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Lookback window in days (1-7, default 7) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It adds useful context ('hourly time-series', includes both cost and call count), but does not state data ordering, timezone, inclusion of partial hours, or any response shape. Acceptable for a simple read-only-style query tool, but several traits are left implicit.
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 tight sentences with zero filler. The core definition is front-loaded, and the second sentence gives practical usage context 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?
For a one-parameter read tool with a clear output concept ('hourly time-series of cost and call count'), the description is nearly sufficient. It lacks explicit sibling differentiation and output details, but the schema covers the parameter and the description covers the return shape sufficiently.
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 days parameter is fully documented in the input schema with range and default. The description itself adds no extra parameter-specific meaning, so the baseline of 3 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 uses a specific verb ('Get') and resource ('hourly time-series of AI/LLM cost and call count'), clearly distinguishing this trend-focused tool from sibling summary or log tools. The example questions further pin down its 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?
Provides clear context through the questions 'is my AI spend trending up?' and 'when did my AI costs spike?', signaling trend/spike analysis use cases. However, it does not explicitly name alternatives like get_cost_summary or get_ai_summary, nor give 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.
Get AI/LLM usage summary: total cost, tokens, calls, errors, and latency. Pass group_by='model' or group_by='provider' for per-model or per-provider breakdowns. Helps answer 'how much am I spending on AI?' or 'which model has the most errors?'.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Lookback window in days (1-90, default 7) | |
| group_by | No | Break down by 'model' or 'provider'. Omit for aggregate totals. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It communicates the aggregate scope and optional breakdown behavior, but does not disclose response shape, pagination, units, or limitations (e.g., no filtering by user/workspace). Core behavior is clear, but deeper traits are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero filler. The first sentence front-loads the action and output metrics; the second packages grouping instructions and use-case examples efficiently.
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 2-parameter, 0-required tool with no output schema, the description covers what, how, and why: all returned metrics are listed and the optional grouping is explained. It doesn't specify the exact response structure for grouped results or units, but these are minor given the schema's thorough parameter documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema already fully documents days (default 7, 1-90) and group_by (enum, omit for aggregate). The description adds only minimal extra meaning by framing group_by as per-model/per-provider breakdowns, which largely restates the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource ('Get AI/LLM usage summary') and enumerates exact metrics returned: total cost, tokens, calls, errors, and latency. It clearly distinguishes itself from siblings like get_ai_calls (individual calls) and get_ai_cost_trend (trend analysis) by presenting itself as the aggregate summary tool.
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?
It gives concrete trigger questions ('how much am I spending on AI?', 'which model has the most errors?') that tell an agent when to select this tool. However, it never explicitly names alternatives or states when NOT to use it, so some ambiguity remains against similar siblings like get_cost_summary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Cloudflare cost burn metrics for this project: today's estimated spend, 7-day total, average/max cost per request, and spike count. Helps answer 'how much am I spending on Workers right now?'.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Lookback window in days (1-90, default 7) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of explaining behavior. It discloses that this is a read-only cost summary and lists the computed metrics. It could add caveats about estimate precision or data freshness, but for a simple getter it is reasonably 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?
The description is two sentences with no filler. The first sentence front-loads the operation and result metrics; the second sentence frames the use case in user language. Everything present contributes 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 one-parameter read tool with no output schema, the description covers the purpose, result metrics, and the question it answers. It does not describe the exact response shape, but that is partially mitigated by the metric list. It could also briefly distinguish itself from cost-related siblings, but the core context is sufficient.
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 `days` parameter is already well documented with default, minimum, maximum, and meaning. The description adds no additional parameter-level semantics, which is acceptable given the schema does the work.
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 specific verb and resource: get Cloudflare cost burn metrics for this project. It then enumerates the exact metrics returned (today's estimated spend, 7-day total, average/max cost per request, spike count), making the tool's purpose unambiguous and distinguishable from sibling tools like get_ai_cost_trend.
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 provides clear usage context by mapping the tool to the user question 'how much am I spending on Workers right now?'. It does not explicitly name alternative tools or when not to use them, so it stops short of full 5-level guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get aggregate statistics: total count, level breakdown, source breakdown.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | End time (ISO 8601 or YYYY-MM-DD) | |
| from | No | Start time (ISO 8601 or YYYY-MM-DD) | |
| hours | No | Lookback hours (1-168, default 24) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It does reveal that the tool returns aggregate statistics rather than raw logs and names the breakdown dimensions, but it does not mention side effects, permissions, pagination, pagination, or response format, and read-only behavior is only implied by 'Get'.
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 zero filler, leading with the action and immediately enumerating the three relevant output categories. Every phrase 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 tool with three optional, fully documented parameters and no output schema, the description gives the essential purpose and result shape at a high level. It is still missing usage routing versus siblings, and it does not describe the output format, leaving it adequate but not 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 description coverage is 100%, so the schema already provides meaning for to, from, and hours, which justifies a baseline of 3. The description adds no parameter-level detail beyond saying the tool is about aggregate stats.
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 ('Get') and resource ('log stats), and it lists the concrete outputs (total count, level breakdown, source breakdown), making the purpose clear. It doesn't explicitly name or differentiate itself against a sibling like query_logs, so it stops short of full differentiation.
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 about when to use this tool versus alternatives such as query_logs, get_recent_errors, or get_cost_summary. The aggregation wording implies a general use case, but no explicit when-to-use or when-not-to-use guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get recent ERROR and FATAL logs with optional stack traces.
| Name | Required | Description | Default |
|---|---|---|---|
| hours | No | Lookback hours (1-168, default 24) | |
| limit | No | Max results (1-1000, default 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. The phrase 'with optional stack traces' is confusing because the input schema has no parameter to enable or disable stack traces; the behavior is not actionable. Other aspects like read-only nature, ordering, and timezone handling are also undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence with no wasted words. The verb and resource are front-loaded, and the optional feature is appended concisely. Structure is highly 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?
For a simple two-parameter tool, the description and schema cover basic invocation. However, the stack trace ambiguity and the absence of sibling routing or output format details leave gaps, especially since there is no output schema and no annotations to fill them.
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 parameters hours and limit are fully documented in the schema. The description adds no extra parameter semantics, and the 'optional stack traces' mention could mislead the agent into expecting a parameter that does not exist.
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 verb ('Get') and specific resource ('ERROR and FATAL logs') with an additional feature ('optional stack traces'). It inherently distinguishes from siblings like get_log_stats (aggregations) and get_trace (specific trace), leaving no ambiguity about what this tool retrieves.
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. The description does not mention that query_logs is for broader search, get_log_stats is for statistics, or get_trace is for a specific trace, leaving the agent to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all logs for a specific request trace by traceId. Shows the full request flow through your Worker — useful for debugging 'find the request that caused this traceId'. Returns logs in chronological order.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (1-500, default 100) | |
| trace_id | Yes | The traceId to look up |
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 the tool returns logs in chronological order, which is a behavioral trait, and the verb 'Get' implies a read-only operation with no side effects. However, it does not mention things like authentication requirements, rate limits, or whether the traceId must be unique. For a retrieval tool, the disclosure is adequate but not rich enough to warrant a higher score.
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 concise sentences. The first states the core purpose with a specific action and target, and the second adds a valuable use case and a key output behavior. Every clause earns its place with zero fluff, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 parameters, one optional) and has no output schema. The description explains what it returns (logs in chronological order) and why it is useful. It does not detail the structure of the logs (fields, formatting), but given the narrow scope and the presence of sibling tools for broader queries, this is a minor gap. For a developer-agent, this is enough to call it 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 description coverage is 100% — both trace_id and limit have descriptive text in the schema, so the baseline is 3. The description adds no additional parameter semantics beyond restating 'by traceId' and confirming the chronological order of results, which does not clarify parameter formats or dependencies beyond what the schema already 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 states a specific verb ('Get all logs'), a specific resource ('a specific request trace by traceId'), and adds distinctive details ('full request flow through your Worker', 'in chronological order'). It clearly separates this from the broad query_logs and other siblings, leaving no ambiguity about what this tool retrieves.
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 a clear usage context: 'useful for debugging find the request that caused this traceId'. This implies when to use it (when you have a traceId and want the full flow), but it does not explicitly name alternatives or state when not to use it. The context is strong enough to guide an agent toward this tool over siblings like query_logs or get_recent_errors.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List tracked error/fatal alerts for this project, ranked by occurrence count. Each alert has a fingerprint that can be passed to resolve_alert.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (1-100, default 20) | |
| resolved | No | Filter by resolved state. Omit for all, true for resolved, false for active. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses the scope, the error/fatal filter, ranking, and the fingerprint linkage, but it does not describe the return shape, pagination behavior, or whether resolved alerts are included by default. The resolved filter is left to the schema.
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, no filler. The primary action is front-loaded and the resolver linkage is a useful addition. Every word 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 list tool with two optional parameters and full schema coverage, the description is nearly complete. It identifies the output concept (fingerprint) and connects it to resolve_alert. A return-format description would push it to a 5, but it is not essential for correct 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?
Schema description coverage is 100%, so the baseline is 3. The description adds no parameter-specific semantics beyond the schema, but it does not need to because the schema already explains limit and resolved. No additional meaning is lost.
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 specific verb ('List'), resource ('tracked error/fatal alerts'), scope ('for this project'), and ordering ('ranked by occurrence count'). It is clearly distinguishable from generic log or cost tools and even hints at the follow-up action via the fingerprint.
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 this is the tool for browsing alerts and mentions that fingerprints can be used with resolve_alert, but it does not explicitly say when to choose this over get_recent_errors or query_logs, nor when to avoid it. Context is clear, but exclusions are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search and filter logs for a project. Supports filtering by level, source, time range, and text search.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | End time (ISO 8601 or YYYY-MM-DD) | |
| url | No | Filter by URL or request path (e.g., '/api/checkout', '/auth/callback') | |
| from | No | Start time (ISO 8601 or YYYY-MM-DD) | |
| level | No | Log level: TRACE, DEBUG, INFO, WARN, ERROR, FATAL | |
| limit | No | Max results (1-1000, default 100) | |
| query | No | Text search in message field | |
| source | No | Source tag (e.g., 'worker.auth') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only restates the filtering capabilities already visible in the input schema. It does not disclose result ordering, pagination, whether it returns raw logs or summaries, default time-range behavior, or any other operational details beyond the schema.
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 fluff. It front-loads the core action and then lists the filtering dimensions efficiently. It is concise, though it could be marginally improved by adding a note about what the tool returns.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema and no annotations, the description does not explain return values, result format, ordering, or default behavior. With seven optional parameters and no output schema, the description is too thin to fully prepare an agent to invoke the tool and interpret results 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 description coverage is 100%, so the schema already documents all seven parameters clearly. The description's mention of 'level, source, time range, and text search' merely summarizes the schema properties without adding new meaning. Per the calibration baseline, a 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 states a specific action ('Search and filter logs') and a resource ('for a project'), which clearly identifies the tool's function. It also lists the key filtering dimensions. However, it does not explicitly differentiate this tool from sibling tools like get_log_stats or get_recent_errors, so it falls 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?
The description provides clear context: this tool is for searching and filtering logs. It implies the appropriate use case without ambiguity. However, it offers no exclusions or references to alternative tools, so it stops short of fully explicit usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mark an alert as resolved so further notifications are silenced until the error recurs. Pass a fingerprint from list_alerts. Resolving primes the next occurrence to re-notify (it does not permanently mute).
| Name | Required | Description | Default |
|---|---|---|---|
| environment | No | Environment tag (defaults to empty string). | |
| fingerprint | Yes | The alert fingerprint from list_alerts. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden. It openly explains that resolution is temporary, that notifications are silenced until recurrence, and that the next occurrence will re-notify. This is meaningful behavioral disclosure beyond a simple action statement.
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?
Three short, focused sentences with no filler. The action and effect are front-loaded, followed by the prerequisite and the critical 'does not permanently mute' caveat. 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 mutation tool with two parameters and no output schema, the description covers the purpose, the required input source, and the nuanced re-notification behavior. It could mention error behavior for invalid fingerprints, but nothing essential for calling the tool correctly is missing.
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%, so the baseline of 3 applies. The description repeats the fingerprint parameter's source (list_alerts) but adds no new parameter-level meaning beyond the schema, and it does not elaborate on the environment parameter beyond what the schema already states.
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 ('Mark an alert as resolved') and immediately states the observable effect: notifications are silenced until the error recurs. This clearly differentiates it from read-only sibling tools like list_alerts and get_recent_errors.
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 clear context for when to use the tool and explicitly instructs the agent to pass a fingerprint from list_alerts. It doesn't enumerate alternatives or exclusions, but the usage context is unambiguous and the prerequisite is stated.
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.
get_ai_callsget_ai_cost_trendget_ai_summaryget_cost_summaryget_log_statsget_recent_errorsget_tracelist_alertsquery_logsresolve_alert
Add one secure layer between your agents and this server.