Rudow's mcp server lets your AI assistant — Claude, Cursor, Windsurf, VS Code and others — query your Rudow projects directly: logs, metrics, incidents and semantic search.
Scored across 17 tools
Most tools are clearly distinct (incident vs log vs metric vs route drilldown), but metrics_overview and metrics_summary substantially overlap, both returning request volume, error rate, latency, and top routes. query_logs vs query_logs_batched is also a close pairing, though the descriptions differentiate them adequately. The overview/summary redundancy is the main source of possible misselection.
Names follow two readable patterns: verb_noun for actions (list_projects, get_incident, query_logs, aggregate_logs) and a metrics_* namespace for metric sections (metrics_levels, metrics_routes, metrics_trends). The mix of patterns is understandable and largely predictable, with minor outliers like failed_ingest_summary.
17 tools is on the high side but justified by the rich observability domain (logs, metrics, incidents, SDK setup, semantic search). The only real excess is the overlapping metrics_overview/metrics_summary pair, which could be consolidated. Otherwise each tool covers a distinct slice.
Log querying, metrics breakdowns, incident inspection, SDK setup, and ingest troubleshooting are well covered for a diagnostic/read-oriented server. Minor gaps exist around incident lifecycle actions (no acknowledge/resolve) and lack of any write/configuration operations, but these are reasonable for an agent-facing diagnostic surface.
Count log entries grouped by a dimension over a recent window. Call this to spot trends, e.g. error rate or status-code distribution.
| Name | Required | Description | Default |
|---|---|---|---|
| minutes | No | Window size in minutes (default 60). | |
| group_by | No | Dimension to group counts by. | |
| project_id | Yes | The project to query. Call list_projects first to see which ids you can use. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the whole burden. It implies a read-only aggregation but doesn't state the window cap (43200 min), whether results are truncated, or anything about the shape of the returned counts; the 'recent window' phrasing is the only behavioral signal.
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 the operation front-loaded and an example that earns its place. No filler or 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?
All three params are documented and there's no output schema, so no return-value explanation is required. Still, for an aggregation tool with no annotations, the description doesn't clarify response shape (e.g. counts per group value) or the default window behavior, leaving a modest gap.
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 enumerate/range details are already in the schema. The description reinforces the grouping ('by a dimension') and window concept but adds no syntax or default guidance beyond that, so baseline 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?
States a specific verb and resource (count log entries) plus the grouping and window scope, which tells an agent exactly what it returns. It doesn't name the overlapping metrics_* siblings (metrics_levels, metrics_routes), so differentiation is left to inference.
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?
'Call this to spot trends, e.g. error rate or status-code distribution' gives a positive usage cue. However, it never says when NOT to use it versus the many metrics_* and query_logs siblings that likely overlap, so an agent still has to guess.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Summary of failed ingest requests over a recent window: count of validation failures, most recent failure, and error details. Use this to troubleshoot SDK/client issues or payload format problems.
| Name | Required | Description | Default |
|---|---|---|---|
| minutes | No | Window size in minutes (default 60). | |
| project_id | Yes | The project to query. Call list_projects first to see which ids you can use. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It usefully discloses the returned summary components and the recent-window scope, but it does not explicitly state that this is a read-only operation, nor does it mention permissions, rate limits, or response format beyond the high-level contents.
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 tight sentences, front-loading what the tool returns and then giving the troubleshooting context. There is no wasted text.
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 low-complexity, two-parameter summary tool with fully documented parameters, the description adequately explains what the summary contains and when to use it. The lack of an output schema is partially mitigated by the description naming the main returned fields, though an explicit read-only note 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?
Schema description coverage is 100%, so the schema already documents both parameters, including the minutes default and project_id guidance. The description adds only the vague phrase 'recent window' and does not add syntax or usage detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly names the resource ('failed ingest requests') and specifies the summary contents: validation-failure count, most recent failure, and error details. It does not distinguish itself from sibling tools such as aggregate_logs or query_logs, 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?
It gives an explicit use case: troubleshooting SDK/client issues or payload format problems. However, it does not name alternative tools or state when not to use it, which keeps it at a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the log entries immediately before and after a timestamp, to see the context around a specific event.
| Name | Required | Description | Default |
|---|---|---|---|
| n | No | Entries on each side (default 10, max 50). | |
| around_iso | Yes | ISO-8601 timestamp to center the window on. | |
| project_id | Yes | The project to query. Call list_projects first to see which ids you can use. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. 'Fetch' implies a read operation and the description explains the before/after window behavior, but it does not disclose ordering, inclusion of the exact timestamp, error behavior, or return 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 definition is a single, front-loaded sentence with no wasted wording. It immediately states what is fetched, the windowing behavior, and the intended use.
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 purpose and windowing behavior are clear, and the schema fully documents the parameters. However, with no annotations and no output schema, the description leaves return ordering, permissions, and result characteristics unstated, which limits completeness for a log-query 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 100%, so all three parameters are already documented in the schema. The description reinforces the timestamp-centering and window concept but adds no parameter syntax or constraints beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: fetch log entries immediately before and after a timestamp. It also states the intended outcome, seeing context around a specific event. It is clear, but it does not explicitly distinguish itself from siblings such as query_logs or semantic_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'to see the context around a specific event' gives a clear usage context for the tool. However, it does not name alternatives or state when not to use it in favor of query_logs, query_logs_batched, or semantic_search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full detail of one incident: why it fired (signals with observed vs usual), top error groups, timeline.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | The project to query. Call list_projects first to see which ids you can use. | |
| incident_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully describes the return contents (signals with observed vs usual, top error groups, timeline), but does not state read-only behavior, permission requirements, failure modes, or whether the result is paginated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence listing exactly the key return categories. There is no filler, and the most important scoping fact—one incident—comes first.
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 lookup with no annotations or output schema, the description adequately explains the return contents. However, it omits parameter sourcing and behavioral details, leaving meaningful gaps for an agent deciding whether and how to call it.
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 50%: project_id is documented in the schema, but incident_id has no description. The tool description adds no parameter meaning, such as incident_id format or where to obtain it via list_incidents, so it fails to compensate for the schema gap.
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 it returns full detail for a single incident, including why it fired, error groups, and timeline. This distinguishes it from list_incidents, which covers multiple incidents, though the verb is implicit rather than 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?
The description implies the tool is for inspecting one incident in depth, but it gives no explicit guidance on when to use it versus list_incidents or other sibling tools. There are no exclusions, prerequisites, or alternative-routing hints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List incidents Rudow detected for this project (newest first). Use to answer what's broken now or recently.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | ||
| project_id | Yes | The project to query. Call list_projects first to see which ids you can use. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses ordering (newest first) but not the default status behavior (does it include resolved incidents?), pagination/limits, result cap, or 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?
Two short sentences, front-loaded with the resource and scope, with zero filler. Brevity works in its favor structurally, though it leaves little room for the behavioral detail other dimensions want.
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 that is likely the entry point for incident triage, the definition omits default filtering behavior, result volume, and what an incident record contains. With no output schema and no annotations, the description should do considerably more of the work.
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 50%: project_id is documented in the schema, but the status parameter is absent from both the schema description and the tool description. The enum values (open/resolved) are self-explanatory, but the description adds no guidance on when or how to use the filter.
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?
States a specific verb and resource ("List incidents"), plus scope ("for this project") and ordering ("newest first"). It is distinguishable from get_incident by the plural/listing framing, but no sibling is named explicitly.
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?
"Use to answer what's broken now or recently" gives a real use case, but no exclusions or alternatives (e.g., when to prefer get_incident for detail or query_logs for raw evidence). It also never says when to filter by open vs resolved.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the projects you have access to. Call this first to get a project_id to pass to the other tools.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It discloses the key trait — results are permission-scoped to the caller's access — but says nothing about pagination, ordering, whether archived/inaccessible projects appear, or what fields each entry contains. For a zero-parameter read this is adequate but thin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler: the first defines the output set, the second states the calling order and the value to carry forward. The most actionable instruction (call this first) is placed prominently.
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 trivial no-argument tool with no output schema, the description covers purpose, ordering, and the identifying field to extract. Only the enumeration of returned project fields is left unspecified, which is a minor gap given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters means there is nothing to document, so the baseline is 4. The description still adds value by naming project_id as the salient output the agent must reuse, telling it what to extract from the response.
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?
States a specific verb and resource ('List the projects') plus an access scope ('you have access to'), which no sibling tool covers — the sibling set is all logs/metrics/query tools. An agent can identify the tool's role as a discovery entry point without opening the schema.
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?
'Call this first to get a project_id to pass to the other tools' gives explicit sequencing and the downstream purpose of the result, which is exactly the guidance an agent needs for a prerequisite tool. It stops short of stating exclusions or when it can be skipped, so it is not a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get setup info for Rudow's client SDKs (Node.js backend, Python backend) — package name, install command, a minimal config/usage snippet, and how to obtain a project ingest API key. Use this to help a user add logging to their own codebase: install the right package for their stack and write the snippet into their code yourself — this tool only returns information, it does not install anything or touch the user's files. It never creates or reveals an ingest API key; the user must generate one manually from the dashboard (see key_instructions in the result) and paste it in themselves.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and does so clearly: this is an information-returning tool, not an installer or file mutator, and it never creates or exposes an ingest API key. It also explains the required manual key-generation path via key_instructions in the result.
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 front-loaded with the resource and return contents, followed by usage guidance and then safety constraints. The sentences are information-dense and each earns its place by clarifying either scope or permitted agent behavior.
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?
Although there is no output schema, the description enumerates the important return values: package name, install command, minimal config/usage snippet, key instructions, and how to obtain an ingest key. Combined with explicit usage boundaries, it gives the agent enough context to call and use the tool 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?
The tool has zero parameters and an empty input schema, so there is no parameter syntax or meaning to explain. The description appropriately focuses on what information the tool returns rather than on nonexistent inputs.
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 and resource: get setup info for Rudow's client SDKs, including package names, install commands, snippets, and API-key instructions. It is clearly distinct from the sibling tools, which focus on logs, metrics, projects, and search rather than SDK integration.
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 explicitly tells the agent when and how to use the tool: help a user add logging, install the package for their stack, and write the snippet into their code. It also states what the tool does not do, namely install packages, touch files, or create/reveal an ingest key, and directs the user to generate the key manually from the dashboard.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Response time distribution: histogram showing the spread of latencies (p50, p75, p90, p95, p99). Use this to understand if latency is consistent or if there are outliers and slow queries.
| Name | Required | Description | Default |
|---|---|---|---|
| minutes | No | Window size in minutes (default 60). | |
| project_id | Yes | The project to query. Call list_projects first to see which ids you can use. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses the output shape and interpretation well, but it does not explicitly state that this is a read-only query, nor does it mention permissions, data freshness, rate limits, or windowing behavior.
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 compact sentences with no waste. It front-loads what the tool returns and follows with the intended interpretation.
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 read-style metrics query with a fully described schema, the description is largely complete: it explains both the output and the analytical purpose. It could be stronger by noting the default time window or differentiating from sibling metrics tools, but nothing critical for invocation 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 description coverage is 100%, so project_id and minutes are already documented in the schema. The description adds no additional parameter guidance such as default behavior or usage constraints, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific metric produced: a response time distribution histogram with p50, p75, p90, p95, and p99 latencies. It is more specific than a generic metrics tool, though it does not explicitly distinguish itself from sibling tools like metrics_summary, metrics_overview, or metrics_routes.
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 a clear intended use case: understanding whether latency is consistent or has outliers and slow queries. However, it does not name alternatives or state when another sibling metrics tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Distribution of log levels: count and percentage of debug, info, warn, error, and fatal entries. Use this to understand the severity profile of logs and if error rates are elevated.
| Name | Required | Description | Default |
|---|---|---|---|
| minutes | No | Window size in minutes (default 60). | |
| project_id | Yes | The project to query. Call list_projects first to see which ids you can use. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral burden. It usefully states the returned breakdown and diagnostic purpose, but it omits that the query is scoped by the minutes window/default 60 and does not explicitly state that it is a read-only metrics read.
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 output definition and followed by the use case. There is no wasted text and the structure is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but the description explains the output distribution well enough. The fully described two-parameter schema covers the inputs, though the description could be more complete by mentioning time-window scoping and read-only behavior.
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 project_id and minutes. The description adds no parameter semantics beyond listing the log levels returned, which is the expected baseline when the schema is complete.
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 operation and resource: distribution of log levels with counts and percentages for debug, info, warn, error, and fatal. It is clear what the tool computes, though it does not explicitly distinguish itself from sibling metrics tools such as metrics_distributions or metrics_overview.
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 an explicit use case: understanding the severity profile of logs and checking whether error rates are elevated. It does not provide when-not conditions or direct alternatives, so it falls short of full sibling routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Overview section of metrics: total requests, error count & rate, average/p95 latency, and top error routes. Use this for a quick health snapshot focused on request volume and performance.
| Name | Required | Description | Default |
|---|---|---|---|
| minutes | No | Window size in minutes (default 60). | |
| project_id | Yes | The project to query. Call list_projects first to see which ids you can use. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose what data comes back, which is genuinely useful, but it says nothing about read-only semantics, permissions, default window behavior, or cardinality of the top-error-routes list.
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 returned fields and followed by the use case. No filler, though the first sentence is a dense enumeration rather than a crisp statement of purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter read tool with full schema coverage and no output schema, the description covers both the returned metrics and the intended use case. The main gap is the absence of routing guidance against the many sibling metrics tools.
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%, including the default of 60 minutes and the pointer to list_projects for project_id. The description adds no parameter-level meaning beyond what the schema already states, 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?
The description names the specific contents returned (total requests, error count & rate, average/p95 latency, top error routes) and frames the resource as an overview section of metrics. It is clear what the tool does, but it does not explicitly distinguish itself from close siblings like metrics_summary or metrics_trends.
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?
"Use this for a quick health snapshot focused on request volume and performance" implies the usage context but names no alternatives or exclusions. With seven sibling metrics_* tools in the set, an agent still has to guess why it would pick this over metrics_summary or metrics_levels.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Top routes by request volume and error count. Shows which endpoints are getting the most traffic and which are failing most often. Use this to identify hot spots and problem areas.
| Name | Required | Description | Default |
|---|---|---|---|
| minutes | No | Window size in minutes (default 60). | |
| project_id | Yes | The project to query. Call list_projects first to see which ids you can use. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden and does not meet it. It never states how many routes are returned, how the ranking is sorted or bounded, that the operation is read-only, or how errors are counted (rate vs absolute). The default 60-minute window is left entirely 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?
The ranking criterion is front-loaded, which is good, but the second sentence ("Shows which endpoints are getting the most traffic and which are failing most often") is a near-restatement of the first and does not earn its place. Three short sentences with one redundant.
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 and no output schema, an agent learns nothing about return shape: top-N cardinality, ordering, whether counts are per-route only or broken down, or the time window semantics. For a metrics tool with zero structured behavioral coverage, the description is thinner than it needs to be.
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%, with both the window minutes and project_id already documented in the schema, including the pointer to list_projects. The description adds no parameter meaning beyond that, so baseline 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?
The description names a specific resource and ranking criterion: top routes by request volume and error count. An agent knows exactly what data this returns. However, it never distinguishes itself from close siblings like route_drilldown, metrics_overview, or metrics_trends, so the agent must guess which route-related tool to pick.
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?
"Use this to identify hot spots and problem areas" gives implied usage but no explicit when-to-use versus alternatives. With route_drilldown, metrics_trends, and metrics_summary all available, the agent gets no routing logic — for instance, whether to come here first for an overview before drilling into one route.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Computed health overview from telemetry: request volume, error rate (4xx/5xx), average and p95 latency, the top routes by traffic and errors, and the latest process metrics (memory, event-loop lag, uptime). Call this to answer how the app is performing or whether it is healthy.
| Name | Required | Description | Default |
|---|---|---|---|
| minutes | No | Window size in minutes (default 60). | |
| project_id | Yes | The project to query. Call list_projects first to see which ids you can use. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool computes a read-only summary and lists what the response includes, but it does not mention permissions, freshness/staleness, rate limits, or whether the summary is cached.
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 and front-loads the returned metrics before the usage guidance. The metric enumeration is dense but each item earns its place by telling the agent what to expect in the response.
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?
Because there is no output schema, the description needs to explain return values, and it does so by enumerating the main metrics returned. It remains somewhat incomplete about response shape, units, and how the time window affects each metric, but it is sufficient for selecting and calling 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 coverage is 100%, so project_id and minutes are already documented, including the default window and the requirement to call list_projects. The description adds no parameter-level meaning beyond the schema, which is the expected baseline when the schema does the heavy lifting.
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 gives a specific verb/resource combination: a computed health overview from telemetry, and enumerates the exact metrics included (volume, error rate, latency, top routes, process metrics). It is clear what the tool produces, but it does not explicitly distinguish itself from close siblings like metrics_overview or metrics_routes.
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 clearly states when to use the tool: to answer how the app is performing or whether it is healthy. It does not name alternatives or exclusions, so the agent must infer that route-specific or trend-specific siblings serve narrower questions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Trends section: request volume, error rate, and latency over time in bucketed intervals. Call this to understand how performance has changed and spot degradation or recovery patterns.
| Name | Required | Description | Default |
|---|---|---|---|
| minutes | No | Window size in minutes (default 60). | |
| project_id | Yes | The project to query. Call list_projects first to see which ids you can use. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the aggregation shape (bucketed intervals over time) and the three metric families, which is useful. However, it says nothing about the default window, maximum range behavior, cost, or the shape of the returned series—gaps that matter for a query tool with zero annotation coverage.
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, zero filler, with the resource and metric scope front-loaded and the intent following immediately. 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?
With no annotations and no output schema, the description should ideally say something about the return shape (per-bucket series per metric) and default behavior. It covers what data is produced but not how it comes back, leaving an analysis-oriented agent to guess at the response structure.
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% and both parameters are documented in the schema (minutes default 60, project_id with a hint to call list_projects). The description's only added semantic is "bucketed intervals," which loosely relates to the minutes window but does not explain bucket granularity or how the window maps to buckets.
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?
States a concrete verb-like action (view trends) and names the three metrics returned (request volume, error rate, latency) over bucketed time intervals. It is distinguishable from siblings like metrics_distributions or metrics_summary by its time-series focus, but it never names those siblings to sharpen the distinction.
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?
"Call this to understand how performance has changed and spot degradation or recovery patterns" gives a usage intent, but there is no explicit when-not guidance and no comparison to metrics_overview, metrics_summary, or metrics_levels, which an agent must choose between. Usage is implied rather than routed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch matching log entries for this project, newest first. Use to inspect specific errors or recent activity. Call this when you need the actual log lines.
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | Case-insensitive substring match on the message. | |
| level | No | Filter by severity level. | |
| limit | No | Max rows to return (default 50, max 200). | |
| source | No | Filter by source, e.g. 'backend' or 'browser'. | |
| minutes | No | Only entries from the last N minutes. | |
| before_iso | No | Only entries before this ISO timestamp (cursor pagination). | |
| project_id | Yes | The project to query. Call list_projects first to see which ids you can use. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose result ordering ("newest first") and project scoping, which the schema does not state. It says nothing about pagination mechanics, default/max result sizes, permissions, or rate limits — several of which appear only in parameter descriptions — so the behavioral picture is partial.
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 sentences, front-loaded with the core action and ordering. The third sentence ("Call this when you need the actual log lines") largely restates the second, so there is minor redundancy but nothing padded or buried.
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, so the description should convey what comes back; it says only "log entries" and their ordering, without mentioning fields, structure, or how to page through results. For a 7-parameter read tool with no annotations, the definition is adequate but leaves the agent guessing at the response shape and pagination workflow.
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 every parameter including the required project_id and the before_iso pagination cursor is documented in the schema. The description adds no filtering semantics, combination rules, or format details beyond that, which is the expected baseline when the schema does the heavy lifting.
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?
States a specific verb and resource ("Fetch matching log entries for this project") plus an ordering guarantee ("newest first"). The phrase "actual log lines" implicitly contrasts with aggregate_logs/aggregate-style siblings, but it never names them, so the differentiation is suggested rather than 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?
"Use to inspect specific errors or recent activity" and "when you need the actual log lines" give an implied when-to-use signal, and the emphasis on raw lines hints that aggregation tools are for other cases. However, no sibling is named and there is no explicit exclusion or alternative routing, leaving the agent to infer query_logs vs aggregate_logs vs query_logs_batched vs semantic_search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a time-bucketed sample over a larger window. Useful when logs are high-volume: returns a balanced slice across time buckets instead of only the very latest lines.
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | Optional substring filter across message and attributes. | |
| limit | No | Total max rows returned (default 400). | |
| minutes | No | Window size in minutes (default 60). | |
| per_bucket | No | Max rows per bucket (default 20). | |
| project_id | Yes | The project to query. Call list_projects first to see which ids you can use. | |
| bucket_minutes | No | Bucket width in minutes (default 5). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does disclose the meaningful non-obvious trait: rows are sampled per time bucket rather than taken from the newest lines only, so results are not a contiguous tail. However it says nothing about ordering, pagination, cost/rate limits, or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, zero waste, with the sampling behavior front-loaded ahead of the rationale. Everything stated earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a 6-parameter read tool, but with no output schema and no annotations the description should say more about the shape of returned rows and the relation between limit and per_bucket. The sampling intent is covered; the result contract is not.
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 is 3, and the description genuinely adds meaning to the bucket parameters by explaining that output is a 'balanced slice across time buckets' — clarifying how bucket_minutes and per_bucket interact with the window. It still does not relate limit to per_bucket × bucket count.
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?
States a specific verb and resource ('fetch a time-bucketed sample') plus the scope ('over a larger window'), and explains the distinguishing sampling behavior versus 'only the very latest lines'. It never names the obvious sibling query_logs, so an agent must infer the boundary itself.
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?
Gives a usage condition ('useful when logs are high-volume'), which is real but implicit guidance. It does not name query_logs or fetch_window as alternatives, nor state when to prefer those instead, leaving the sibling routing decision to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deep dive into a specific route: request count, error rate, average and p95 latency, errors by status code. Call this after seeing a problematic route in metrics_routes to get details.
| Name | Required | Description | Default |
|---|---|---|---|
| route | Yes | The route path to drill down into, e.g. '/api/v1/chat'. | |
| minutes | No | Window size in minutes (default 60). | |
| project_id | Yes | The project to query. Call list_projects first to see which ids you can use. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the disclosure burden; it does so by listing exactly what the call returns (counts, error rate, latency percentiles, status-code breakdown) in lieu of an output schema. It stops short of stating behavior for unknown routes, empty windows, or whether the aggregate is read-only/cached, but the return-content disclosure is solid for a query tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the return payload then the routing instruction; every clause earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, workflow, and output contents despite having no output schema or annotations. The only gap is unspecified edge-case behavior (missing route, zero-traffic window), which is minor for a read-only metrics query.
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 route, minutes, and project_id are already documented, including the default window and the hint to call list_projects. The description adds no parameter detail beyond what the schema provides, so the baseline 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?
States a specific verb ("Deep dive") and resource (a specific route) and enumerates the exact metrics returned: request count, error rate, average/p95 latency, errors by status code. It explicitly contrasts with the sibling metrics_routes, so an agent can distinguish the two without opening either schema.
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 says "Call this after seeing a problematic route in metrics_routes to get details," naming the alternative tool and the condition that selects it. The workflow relationship (overview first, drilldown second) is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find log entries whose meaning is similar to a natural-language description, using vector similarity (not substring matching). Use this when the user describes a problem in their own words rather than citing exact log text — e.g. 'requests failing because the database was down'. Covers all logs once they have been embedded (a background job embeds new logs shortly after ingest).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results to return (default 20, max 50). | |
| query | Yes | Natural-language description of what to find. | |
| project_id | Yes | The project to query. Call list_projects first to see which ids you can use. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden; it discloses the retrieval model and, importantly, the eventual-consistency caveat that new logs are only searchable after a background embedding job. It omits ordering/relevance scoring, result shape, and the fact that this is a read-only operation, which is a gap for a no-annotation tool but not a serious one.
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 focused sentences: what it is, when to use it, and the freshness constraint. Front-loaded with purpose and no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-param read tool with no output schema and no annotations, the description covers purpose, usage, and the main operational caveat (embedding lag). It stops short of describing result ordering or relevance scores, which an agent would want to know without an output schema.
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% (limit defaults/max, project_id guidance, query meaning all documented in the schema), so the baseline of 3 applies. The description adds only the semantic framing of 'query' as natural language, no new limit or project_id behavior.
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?
States a specific verb and resource (find log entries) plus the mechanism (vector similarity, explicitly 'not substring matching'), which distinguishes it from query_logs/query_logs_batched without naming them. The example query makes the semantics concrete.
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?
Gives an explicit when-to-use rule (user describes a problem in their own words rather than citing exact log text) with an illustrative example. It implies but never names the alternative tool to use for exact-text lookups, so routing is left slightly to inference.
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_incidentlist_incidentsaggregate_logsfailed_ingest_summaryfetch_windowlist_projectslist_sdksmetrics_distributionsmetrics_levelsmetrics_overviewmetrics_routesmetrics_summarymetrics_trendsquery_logsquery_logs_batchedroute_drilldownsemantic_search
Add one secure layer between your agents and this server.