Read your team's hosted journal from an AI agent: every machine's streams, in hub order.
Scored across 10 tools
Most tools have clearly separate roles: listing streams, tailing logs, searching recent/historical logs, waiting, and interpreting. The only mild overlaps are search_logs vs search_history (both text search, different windows) and hub_status vs list_streams (both health/orientation views), so an agent might occasionally pick the wrong one.
Names are mostly verb_noun and all snake_case: list_streams, search_logs, tail_logs, wait_for. The deviations are noun compounds like hub_status and stream_guide and a bare verb like interpret, but they are still descriptive and predictable.
Ten tools is a well-sized surface for a log observability platform: orientation, search, tail, wait, analysis, and health are each covered by one or two focused tools. No tool feels redundant or unnecessary.
The set covers the core investigation workflow: check ingestion health, list streams, tail or search current logs, search history, wait for events, and get an interpretation. The main limitation is that it is read-only for webhooks and streams—no tools create or modify them—but that appears consistent with the board-style purpose.
Put yourself on the org's AGENTS blotter: who you are, what you are doing, how far along. Over the hosted endpoint this is recorded against your agent token and shown on the console.
| Name | Required | Description | Default |
|---|---|---|---|
| llm | No | The model you run on | |
| pct | No | Percent complete, when the job has a shape | |
| task | No | The overall job | |
| agent | Yes | Your name on the blotter | |
| level | No | Default INFO | |
| status | Yes | One line: what is happening right now |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It does disclose that the report is recorded against the agent token and shown on the console, which is useful. However, it does not mention side effects like overwriting previous reports, auth requirements beyond the token, rate limits, or what response to expect.
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, front-loaded with the core purpose, and has no filler. Every phrase earns its place by conveying function, scope, and destination of the data.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters and no output schema, the description provides enough high-level context for an agent to understand this is a self-reporting action. It explains the purpose and data destination, and the schema covers field-level details. A brief note on what happens after the call would have made it fully 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 coverage is 100%, so parameters are well documented. The description adds semantic grouping: 'who you are' maps to agent, 'what you are doing' to status/task, and 'how far along' to pct. This helps the agent select the right fields beyond the raw 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 states a specific verb and resource: 'Put yourself on the org's AGENTS blotter', and immediately clarifies the purpose as reporting who you are, what you are doing, and progress. This clearly distinguishes it from sibling tools that read logs, streams, or status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: this is for an agent to report its own identity, activity, and progress to an organizational console. It does not explicitly name alternatives or exclusions, but the context strongly implies when this tool is relevant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether the org's benches are sending and how much has arrived. Call this first when logs seem missing - it distinguishes "the bench is down" from "the app logged nothing".
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It appropriately reveals that this is a diagnostic/status probe rather than a log retrieval command, and that it distinguishes infrastructure failure from application logging failure. However, it does not disclose the output shape, whether any state is changed, or what 'benches' refers to, leaving some ambiguity for an agent.
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 no filler. The first sentence states the core function, and the second gives the actionable use case. The most important information is front-loaded, and 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 parameterless status-check tool, the description gives enough context for an agent to know when to call it and what question it answers. The only notable gap is the lack of output-schema detail, but the tool's simplicity means an agent can still use it correctly from the given information.
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 the schema coverage is 100%, so there is nothing for the description to add about inputs. The description instead provides useful operational meaning about what the tool checks. A baseline of 4 is appropriate for a parameterless tool.
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 ('Check'), a specific resource ('the org's benches'), and the exact information returned ('whether ... sending and how much has arrived'). It also draws a clear contrast with the app having 'logged nothing', which differentiates it from the log-focused sibling tools.
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 explicitly says when to use this tool: 'Call this first when logs seem missing'. It also clarifies the diagnostic distinction it resolves, which gives strong context for choosing it. It does not explicitly name alternative tools or give a 'when not to use' case, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ask super-log Cloud to READ the bench and tell you what happened, whether it matters, and what to do next - the same reading the console shows. audience technical (default) is for the engineer fixing it; executive is the C-suite reading. Covers the org's recent window across every stream; counts against the org's monthly pool. Waits up to wait_ms for the answer and says so if it is still being produced.
| Name | Required | Description | Default |
|---|---|---|---|
| force | No | Produce a fresh reading even if a recent one is cached | |
| wait_ms | No | How long to wait for the reading, default 30000, max 60000 | |
| audience | No | Default technical |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it delivers real behavioral disclosure: 'counts against the org's monthly pool' (quota cost), 'Waits up to wait_ms for the answer and says so if it is still being produced' (async/latency behavior), and 'Covers the org's recent window across every stream' (scope). It stops short of stating auth requirements or explicit non-mutating guarantees, though 'READ' implies read-only.
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 sentences with no filler: purpose first, then audience semantics, then scope/cost/wait behavior. The cost and async behaviors are packed into the back half efficiently. Nothing is redundant with the schema; the backtick-delimited parameter references keep it scannable.
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 no output schema, no annotations, and zero required parameters, the description covers purpose, scope, audience, quota impact, and wait behavior — a strong package. The gap is that the return value is never described beyond 'the same reading the console shows', and error cases are unaddressed, leaving some inference to the agent.
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, but the description adds genuine meaning: it explains audience (technical = engineer fixing it, executive = C-suite) and gives wait_ms behavioral context (waits, then reports if still producing). Only force is left to the schema, which already describes it adequately.
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+resource pair ('READ the bench') and clearly states the outcome: what happened, whether it matters, and what to do next. It reads distinctly from siblings like tail_logs and search_logs (raw retrieval) versus this interpretive analysis, though it never names a sibling 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?
Usage is implied rather than stated: 'the same reading the console shows' suggests when to call it, and the audience parameter hints at the consumer ('engineer fixing it' vs 'C-suite reading'). But no alternatives or exclusion conditions are named — an agent gets no explicit guidance on when to choose this over search_logs, tail_logs, or agent_report.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Summarise which log streams (topics) are active and their level mix. Cheap orientation - call this before tail_logs so you know what topics exist and where the errors are, instead of guessing topic names.
| Name | Required | Description | Default |
|---|---|---|---|
| window | No | How many recent events to summarise (default 1000, max 2000) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the burden. It adds 'cheap orientation' and 'Summarise', which imply low cost and aggregation, but it does not explicitly state read-only behavior, permissions, output format, or any side effects. The description is safe but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, with the core function stated first and the practical usage hint in the second. No fluff; every clause carries meaning.
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-optional-param tool with no output schema, the description covers the purpose, when to use it in a workflow, and why it is valuable (finding topics and errors). It does not describe the output structure, but the description is still sufficient for an agent to decide to invoke 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 description coverage is 100% for the single 'window' parameter, including default and max values. The description adds nothing about parameters beyond what the schema already states, so the 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 uses a specific verb ('Summarise') and resource ('log streams (topics)') and states exactly what it reports: active streams and their level mix. It explicitly names tail_logs as a sibling, which differentiates this tool from the log-tailing use case and gives clear 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?
It gives explicit guidance on when to call this tool: before tail_logs, to know what topics exist and where errors are, instead of guessing topic names. This clearly indicates the intended workflow and distinguishes it from the downstream tail_logs tool, though it does not cover all sibling alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The org's inbound webhook endpoints and what last arrived on each - the WEBHOOKS board.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 that the tool shows webhook endpoints and the last data received, implying a read-only informational return. However, it does not mention authentication, rate limits, potential side effects, or the exact shape of the output. For a simple listing tool, 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?
The description is a single, front-loaded sentence with no filler. It states the core purpose and the 'board' reference adds a useful mental model. 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?
Given the tool's simplicity (no parameters, no output schema), the description fully communicates need-to-know information: what it lists and what each entry includes. It could be more explicit about whether it returns raw payloads vs. summaries, but for an initial call this 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?
The tool has zero parameters, so the description adds no parameter-specific meaning, which is appropriate. The baseline of 4 applies because there is nothing to clarify beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('list') and resource ('webhook endpoints'), and adds what it reports ('what last arrived on each'). It distinguishes from siblings like list_streams by explicitly naming webhooks, so an agent can tell it apart without opening schemas.
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 purpose implies when to use it (when you need to inspect inbound webhook endpoints), but it does not explicitly state when not to use it or mention alternatives. It gives enough context for an agent to infer the use case, but lacks explicit exclusions or comparisons to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the cloud journal: hours or days of history, up to a week. This is the tool for "what happened at 3am" - tail_logs and search_logs only see the last hour.
| Name | Required | Description | Default |
|---|---|---|---|
| level | No | Minimum level | |
| limit | No | Max events (default 50, cap 200); the NEWEST matches | |
| since | No | Start of the window: 30m, 2h, 3d, 03:00 (today, UTC), 2026-08-22, or a full ISO timestamp. Max 7d. | |
| topic | No | Exact topic, a prefix ending in a dot, or * | |
| trace | No | One correlation id, across every stream | |
| contains | No | Case-insensitive substring of the whole event, fields included |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. It adds useful temporal context (the week-long window, the '3am' scenario), but it does not disclose return format, how the six filters combine, result ordering, or any caveats. The 'up to a week' claim duplicates the schema's 'Max 7d' rather than adding new behavioral information.
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: purpose and scope first, then the sibling differentiator. Every clause earns its place, and the most decision-relevant information (the time window and the competing tools' limitation) 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 has meaningful complexity — six optional filters, correlation tracing, topic prefix matching — and no output schema. The description handles tool selection well but is thin on usage depth: it does not clarify what the response looks like, how filters interact, or the behavior when no filters are given. Adequate for choosing the tool, but an agent would still rely entirely on the schema to use 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%, with every one of the six parameters already documented in detail (level enum, limit default/cap, since formats and max window, topic prefix rules, trace across streams, contains semantics). The description adds only marginal temporal framing around the 'since' parameter and does not materially enhance what the schema already states, 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 and resource ('Search the cloud journal') plus an explicit scope ('hours or days of history, up to a week'). It distinguishes itself from siblings by naming tail_logs and search_logs and their one-hour limitation, so an agent can select it correctly without opening schemas. The 'what happened at 3am' example reinforces the use case.
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 names the two competing siblings (tail_logs, search_logs) and the condition that selects them over this tool ('only see the last hour'), which is exactly the when-not-to-use guidance. The temporal differentiator is front and center, leaving no ambiguity about when search_history is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find events matching text across the last hour - use when you know what the message says (an exception, an order id, a URL) but not which stream it is in.
| Name | Required | Description | Default |
|---|---|---|---|
| level | No | Optional minimum level | |
| limit | No | Max matches (default 50, cap 200) | |
| topic | No | Optional topic or prefix to narrow the search | |
| contains | Yes | Text to find (case-insensitive) |
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 time window ('across the last hour') and the search behavior, which is useful. However, it does not mention the return format, pagination, or any side effects. For a search tool this is a reasonable baseline, but the lack of richer context (e.g., results structure) prevents 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 a single sentence that is front-loaded with the action and time constraint, then adds the use-case context. It is concise with no wasted words. Slightly less crisp than the best examples but still effective.
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 has four params, all documented in the schema, and no output schema. The description explains the main use case and time scope but does not describe what the result looks like (e.g., list of matching events). For a search tool, this is a gap but not critical—agents can infer. Overall it is adequate but not fully 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%, meaning all four parameters are documented in the schema. The description adds minimal extra meaning beyond the schema—it only paraphrases the 'contains' parameter and adds the time context. Per the baseline, 3 is appropriate since the schema already 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 clearly states the verb 'Find events matching text' and specifies a resource (events/messages) and a time constraint ('across the last hour'). It also implies cross-stream search by noting 'but not which stream it is in', which distinguishes it from stream-specific tools like tail_logs. However, it does not explicitly name a sibling, 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?
Provides explicit guidance on when to use: 'use when you know what the message says (an exception, an order id, a URL) but not which stream it is in.' This gives a clear condition for selection. Missing is an explicit 'do not use when' statement or alternatives, so it's not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detailed documentation for a bench capability, before working with an unfamiliar topic: what its events and metrics mean, how to read them, and the gotchas. No arguments lists everything; name one entry or a playbook for the detail.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | A stream entry (power, dl, build, fs, vitals, gpu, os-app, net, history, alarms, agents, ...) or a playbook (triage, follow-a-trace, silent-stream, ...) |
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 clearly states this is read-only documentation (no side effects), and describes behavior: returns high-level info with no args, detailed info with a name. It doesn't disclose edge cases like invalid names, but given it's a doc tool, that's minor. It adds meaningful context about how the tool behaves (summary vs detail).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, two sentences. It front-loads the purpose and then states usage guidance. No filler. Slightly could be structured with bullets, but it's 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 documentation tool with one optional parameter and no output schema, this is fairly complete. It explains what it does, what it returns at a high level (events/metrics meaning), and how to use it (name or empty). It doesn't list all possible values, but the schema already does with examples. Sibling tools like list_streams suggest that listing all entries is handled elsewhere, so this tool's scope is clear.
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 schema has 100% coverage, describing the 'name' parameter with examples. The description reinforces that the parameter is optional and specifies the two kinds of values (entries, playbooks) and the behavior difference. It adds value by explaining the no-arg behavior, which is not in 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 states a specific purpose: documenting a bench capability's events, metrics, reading them, and gotchas. It clearly indicates the tool provides reference documentation, not execution. It distinguishes from siblings by focusing on documentation/interpretation of streams, though it's slightly vague on what 'guides' exactly entails.
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 explicitly says 'No arguments lists everything' and instructs to name one entry or playbook for detail. It sets expectations for when to call without arguments vs with a name. It doesn't explicitly compare to alternatives but the sibling list (interpret, list_streams, etc.) implies this is for detailed docs, and the wording implies it's for unfamiliar topics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read recent log events, newest last. ALWAYS narrow with topic and/or level - an unfiltered tail of a busy bench is noise. topic is exact (cpp.clock) or a prefix ending in a dot (expo.).
| Name | Required | Description | Default |
|---|---|---|---|
| level | No | Minimum level; ERROR is the usual choice when hunting a bug | |
| limit | No | Max events (default 50, cap 200) | |
| topic | No | Exact topic, or a prefix ending in a dot | |
| contains | No | Only events whose text contains this (case-insensitive) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the behavioral burden. It discloses that events are recent, ordered newest last, and that unfiltered queries can produce noisy output, and explains topic matching semantics. It lacks a precise time window definition, but the essential traits are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no filler. The core purpose is front-loaded, and the narrowing rule and topic format each earn their own sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tail tool with no output schema, the description covers purpose, ordering, filtering guidance, and topic format. The only minor gap is that 'recent' is not defined as a time window, which is acceptable for a tail utility.
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 applies. The description reinforces using level and topic for narrowing and gives an illustrative example for topic matching, but it adds no parameter semantics beyond what the schema already documents.
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 ('Read recent log events') and specifies ordering ('newest last'), which clearly distinguishes it from a historical search tool like search_logs. The purpose is immediate and not a tautology.
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 explicit guidance to always narrow with topic and/or levelheb, and warns that an unfiltered tail is noise. It does not name alternative tools or when-not-to-use conditions, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Block until an event matching the filters arrives, or time out. Use this after triggering an action instead of sleeping and polling.
| Name | Required | Description | Default |
|---|---|---|---|
| level | No | Optional minimum level, e.g. ERROR | |
| topic | No | Optional topic or prefix | |
| contains | Yes | Text the event must contain (case-insensitive) | |
| timeout_ms | No | How long to wait (default 30000, max 60000) |
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 blocking behavior, timeout, and event-matching semantics. However, it doesn't mention what happens on timeout (error vs empty result), whether events are consumed/destroyed, or how it interacts with the event stream. These are meaningful gaps for a blocking 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, zero filler. The core behavior is front-loaded, and the usage guidance is concise. 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 blocking tool with no annotations and no output schema, the description should clarify timeout behavior and return semantics. It states the timeout exists but not what the agent should expect on timeout or failure. Given the tool's simplicity, this is a moderate gap, not a severe one.
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 conceptual framing of 'filters' and 'event matching' but doesn't add syntax or format details beyond 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 uses a specific verb ('Block') with a clear resource ('an event matching the filters') and states the timeout behavior. It distinguishes itself from polling/sleeping approaches, which helps an agent understand its unique role among sibling tools.
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 explicitly says 'Use this after triggering an action instead of sleeping and polling.' This gives clear when-to-use guidance and implicitly contrasts with alternatives like tail_logs or search_logs. It could name a specific sibling, but the guidance is strong enough.
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.
agent_reporthub_statusinterpretlist_streamslist_webhookssearch_historysearch_logsstream_guidetail_logswait_forRead a project's prompts, logs and agents, and send new work to the agent on your own machines.
Hosted self-curating shared memory that keeps your agents working like a high-performing team
Read-only NodeRooms Agent discovery, safety policy, public indexes, and arrival contract.
Configure AI agents, give them knowledge and tools, and read back every generation they run.
Add one secure layer between your agents and this server.
