Relia

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare the generic safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=false); the description adds real substance by disclosing the external side effect on PagerDuty and the escalation consequence, plus the confirm gate. It stops short of explaining the non-idempotent behavior flagged by idempotentHint=false (what happens on a repeat ack) or whether the incident must be assigned to the caller.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One tight sentence with the action and its consequence front-loaded and the confirm gate as the final clause. No filler, no restatement of the title.

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 ideally would say what an ack returns, but for a simple state-changing action it covers purpose, side effects, and the safety gate adequately. Minor gaps are the project-scoping condition and the outcome on repeated acknowledgment.

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, including confirm's meaning. The description only reinforces that confirm=true is mandatory rather than adding syntax, format, or edge-case meaning beyond the schema; 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?

Names a specific verb ('Acknowledge') and resource ('an incident's alert') plus the concrete effect of the action (stopping escalation, acknowledging PagerDuty). That effect cleanly separates it from neighbors like relia_get_incident (read) and relia_mark_fixed (post-resolution), so an agent can pick it 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?

The description establishes the operative context — acknowledging an active alert before the on-call rotation escalates — and states the hard prerequisite that nothing happens without confirm: true. It does not name an explicit alternative or a when-not-to-use case (e.g., use relia_mark_fixed once resolved), which keeps it below a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds genuinely non-obvious context beyond them: answers are evidence-citing, and each call consumes the project's Ask Relia allowance, which flags a cost/quota dimension the agent should weigh. It does not disclose latency, determinism, or what happens on exhausted allowance, which keeps it short of a 5.

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 capability and followed by three compact parenthetical examples that carry most of their informational weight. Minor space spent on illustrative quotes, but no sentence is 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?

With no output schema, the description must characterize the return value, and it goes only as far as 'answers cite their evidence'. For an open-ended NL answer tool an agent would benefit from knowing the shape of a response (prose vs. structured), typical latency, and behavior when allowance runs out or the project is ambiguous.

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%: the `project` parameter is documented in the schema as only needed for multi-project tokens, while `question` has no schema description at all. The description partially compensates by demonstrating the kind of natural-language question expected, but adds no guidance on scope, length, or phrasing limits beyond the examples.

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?

Names a specific verb (ask a question) and a specific resource (the product's live data) and grounds it with three concrete example questions, so an agent can immediately tell this is a natural-language query interface rather than a metrics endpoint. It does not name the sibling tools (relia_uptime, relia_logs, relia_dashboard) that answer narrower versions of the same questions, so the differentiation from siblings is implied rather than stated.

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 examples imply when this is useful (diagnostic questions spanning uptime, API latency, and error causes), and 'Uses the project's Ask Relia allowance' hints that it is a metered resource worth conserving. However there is no explicit guidance on when to prefer a targeted sibling like relia_uptime or relia_logs over this open-ended tool, nor any exclusion condition.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds real behavioral value on top: result ordering (newest first) and the exact composition of the feed, including that incidents appear only when they 'began' in the window. It stops short of disclosing result caps or how large windows are truncated.

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?

A single dense sentence that front-loads the core answer ('What changed lately, newest first') before the enumeration. The nested colons and em dash make it slightly harder to parse than necessary, but no sentence is wasted.

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 only two fully documented optional parameters and rich annotations, the main remaining burden is describing the return content, which the description does by enumerating the three change classes. There is no output schema, so a brief note on item shape or result limits would have closed the last 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%, and both parameters (hours with its default 48 and project scoping) are fully documented in the schema itself. The description adds no further semantics about the time window or project scoping, 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 resource (a merged change feed) and enumerates its three constituent classes: deploys Relia saw, changes reported to Relia, and incidents that began. The phrase 'newest first' plus the incident framing distinguishes it from relia_list_incidents and relia_report_change without the agent needing to open any 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?

Gives a concrete triggering question — 'did my deploy break anything?' — which is a strong, recognizable use case. It does not, however, name an alternative or state when to prefer relia_list_incidents or relia_get_incident instead, so there is no exclusion guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds real value beyond that by explaining why findings may be partial ('Parts show up once the app has run and been used') and that each category reports the step still missing, which tells the agent how to read sparse results.

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 data inventory and followed by the caveat about when data appears. The category list is long but each item earns its place as an enumeration of what will be returned.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description does the job of describing return contents by category and noting the 'step left when missing' detail. The phrase 'the step left when missing' is slightly opaque and it never says whether results are per-project aggregates or time-bounded, but for a zero-required-parameter read tool it is largely sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the single optional 'project' parameter is fully documented in the schema, including the multi-project token condition. The description only alludes to scoping via 'from this project' and adds no format or selection guidance, 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 states concretely what is reported: requests per service, browser sessions, source maps, identified users, and AI agent runs that have arrived in Relia from this project. That is a specific resource inventory rather than a restatement of the name. It does not, however, distinguish itself from nearby siblings such as relia_setup or relia_status, so an agent must infer the split.

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 only implied: 'Parts show up once the app has run and been used' hints that this is an onboarding/verification check to run after the app has been exercised. There is no explicit when-to-use statement and no named alternative (e.g. relia_setup for configuration guidance vs this for observed data), leaving the routing decision to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Adds a genuinely important behavioral fact beyond the annotations: nothing is created unless confirm is true, which tells the agent this is a gated, founder-consent-bound mutation. Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=false, so the safety profile is covered; the description could still mention that repeat calls create duplicates or what happens on failure, hence not a 5.

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, no filler, with the creation precondition front-loaded and the confirm requirement immediately after. Every clause 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 three-parameter creation tool with annotations covering safety, the description plus schema is nearly sufficient to call it correctly. It omits any indication of what a successful call returns (no output schema exists) or what happens if a project already exists, which are the only real gaps.

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 name, confirm, and timezone are already fully documented, and the description only restates the confirm gating. It adds no meaning about name constraints or the timezone's role beyond what the schema says, 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 ('Create a new Relia project') plus a precondition ('for a repository that has none yet') that separates it from the read-only relia_projects sibling. It does not name the sibling to use when a project already exists, so the differentiation is implied 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?

Gives clear triggering context: call this only when a repository has no project yet, and only with confirm: true. It stops short of naming an alternative (e.g., relia_projects or relia_setup) for the already-exists case, but the when-to-use condition is unambiguous.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description goes beyond them by specifying the shape of what comes back panel by panel, including comparative change vs the prior period. It stops short of disclosing payload size, latency, or how project/service scoping narrows the result set.

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?

A single sentence that front-loads the core idea ('One team dashboard read out panel by panel') and then spends its length on a compact enumeration of panel types. Nothing is redundant with the schema or annotations, and every clause carries information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description must carry the return-value burden, and it does so by naming the panel families and the comparison semantics. Given four fully documented parameters and complete annotations, the remaining gap is minor: no hint about read cost, panel count, or behavior when a panel is empty.

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 each of the four parameters (including the range enum defaulting to the dashboard's own) is already documented. The description adds no parameter-level guidance such as how 'service' partial narrowing behaves or what a project-scoped read omits, 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?

The description makes clear this reads a single team dashboard and enumerates the panel content returned (current metric plus delta, rankings, monitors/checks/promises, open incidents, deploy/incident commentary). The singular 'One team dashboard' implicitly contrasts with the list-oriented relia_dashboards sibling, though it never names that tool 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 only implied: the focus on 'One team dashboard' suggests this is the per-dashboard read rather than the dashboard listing, and the panel inventory hints at what questions it answers. There is no explicit when-to-use, when-not-to-use, or named alternative among the many siblings (relia_status, relia_uptime, relia_dashboards).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), so the description's job is payload context — and it delivers: ids are included, there are two dashboard categories, and entries carry reasons like at risk, just deployed, busiest. It stops short of describing ordering, pagination, or what happens with an empty result set.

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?

A single sentence with no filler, and the core content (what is listed) is front-loaded. The nested parentheticals make it a slightly dense read, but nothing is wasted.

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 one optional parameter fully documented, no output schema, and annotations carrying the safety profile, the description covers what an agent needs: what comes back (dashboard entries with ids) and why any entry matters. Nothing essential to correct 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 coverage is 100% and the project parameter is already documented as a project id or name needed for multi-project tokens. The description adds nothing about scoping across projects, so the schema does all the work — 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?

The description names the resource and its two populations precisely: team-made dashboards (with ids) and Relia's per-service dashboards, plus a triage signal for each. It implicitly contrasts with the singular relia_dashboard sibling by being the enumeration, but never states that contrast 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?

There is no when-to-use / when-not-to-use statement and no routing to alternatives such as relia_dashboard for opening a single dashboard. The only hint is the 'why each one is worth opening' phrasing, which implies a triage purpose but leaves the agent to infer it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish read-only, idempotent, closed-world behavior, and the description adds genuinely new context: results are grouped with literal values stripped (normalized query shapes), sorted by total time descending, and include N+1 detection semantics. It does not mention result limits or pagination, which keeps it short of a 5.

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?

A single dense sentence that front-loads the resource and grouping mode, then enumerates outputs and the N+1 special case. No filler, and the parenthetical explanation of N+1 is the one piece of jargon that needed unpacking.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the return-value burden and does so by listing the exact fields returned plus ordering. The remaining gap is scoping behavior (how project/service narrow results) and result size, but for a read-only analytics tool this is largely sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 67%, and the description adds nothing about the three parameters — no mention of range, project scoping, or what 'service' filters. The schema documents range (default 24h) and project, but service is undocumented in both places, which the description does not compensate for.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the resource (database queries), the aggregation mode (grouped without literal values), and the metrics returned (calls, p95, failures, example slow/failed traces, N+1 patterns). It is clearly distinguishable from siblings like relia_trace or relia_logs, though it never explicitly contrasts itself with them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no statement of when to use this versus relia_trace, relia_logs, or relia_vitals — an agent must infer from the metric list that this is for DB query performance investigation. No prerequisites, exclusions, or alternative routing are given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. What the description adds beyond them is the substantive part: the comparison window (7 days vs prior week), the drop-off focus, and the reason categories (errors, failed requests, slow page, struggling, devices). With no output schema present, this return-content detail is the description's main contribution.

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?

A single dense sentence that front-loads the subject ('The journeys Relia follows') before enumerating metrics and reason categories. Every clause carries information, though the parenthetical example list and trailing 'plus goals…' clause make it a long read.

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-parameter, read-only, no-output-schema tool, the description covers what an agent needs: what data comes back, the time window, and the diagnostic breakdown. The only real omission is how this differs from the other analytics siblings.

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?

There is only one optional parameter and the schema documents it at 100% coverage, including the conditional rule about tokens spanning multiple projects. The description adds nothing about the project parameter, so it sits at the baseline for a fully documented 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 names a concrete resource (conversion funnels such as checkout and sign up) and states exactly what it reports: completion counts for the last 7 days versus the prior week, the step with the biggest loss, and the reasons for leaving. It is not tautological, but it never contrasts itself with near-neighbors like relia_dashboard or relia_vitals, so the agent must infer the boundary.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit when-to-use statement and no named alternative. The phrase 'goals no funnel follows yet' hints at a coverage-gap use case, but the agent gets no guidance on choosing this tool over relia_dashboard or relia_status, nor on any prerequisite such as having funnels configured.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly/idempotent/openWorld=false, so the safety profile is covered. The description adds a genuinely useful non-obvious trait: it consumes the project's monthly fix-plan allowance the first time and is cached thereafter — a quota/cost behavior not in annotations.

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 output content front-loaded and the quota/caching caveat trailing. No filler; each clause carries information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only tool with no output schema, the description conveys what the response contains (root cause, files/lines, change, verification) and the caching/quota behavior. The only real gap is the undocumented incident_id parameter.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 50%: the 'project' param is documented but 'incident_id' has no description. The description mentions 'of an incident' but does not clarify the incident_id's role or the multi-project scoping requirement, leaving the coverage gap uncompensated.

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?

Specific verb+resource: produces concrete fix steps 'written from its evidence: root cause, files and lines, the change, how to verify' for a given incident. It's clearly distinguishable from relia_get_incident (retrieval) by describing the generated output, though it doesn't explicitly name the alternative.

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 — the output describes a remediation plan that naturally follows diagnosis, and the caching note hints at repeat calls. But it never states when to use this vs relia_get_incident, relia_ask, or relia_mark_fixed, and gives no prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds real value by disclosing response composition (plain-language narrative, per-layer evidence with example trace ids, correlated deploys), which is beyond annotations. It says nothing about not-found behavior, permissions, or payload size.

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?

A single front-loaded sentence with a compact enumerated list of returned content; no filler. The colon-separated list is dense but readable and puts the subject 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?

With no output schema, the description does carry the burden of explaining returns and does so adequately. But for a tool whose required argument is an opaque id, it omits how to discover that id or what happens on an unknown id, leaving a practical gap before invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 50%: project carries a description, but incident_id is a bare string. The description never mentions incident_id, its format, or where to obtain it, so it fails to compensate for the coverage gap. Project scoping is likewise left entirely to 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?

It states the resource (one incident) and enumerates precisely what the response contains: what happened, impact, next steps, timeline, per-layer evidence with trace ids, and nearby deploys. That is far more specific than a title restatement and implicitly separates it from relia_list_incidents. It never uses an explicit retrieval verb or names a sibling, so it stops 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?

There is no guidance on when to call this versus relia_list_incidents (to find an id) or relia_trace / relia_changes (to drill into evidence). Nothing says where an incident_id comes from, nor are any exclusions or prerequisites given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely useful behavior beyond that: default sort order ('most important first') and the shape of each returned row (ids, severity, users affected, fix state). It does not mention default status filtering (open) or the 10-item default limit, which matter for interpretation of results.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One compact sentence, front-loaded with the resource and the ordering, with no filler. It is arguably too terse to be fully self-sufficient, but nothing is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description usefully enumerates the returned fields and the sort order, and the schema carries parameter defaults and enum semantics. What is missing is guidance on the default open-only scope and result paging, but the core call is answerable.

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 (limit, status, project) are documented in the schema with defaults and enum values. The description adds nothing about parameters, 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?

Specific verb + resource ('Incidents Relia raised') with scope narrowing ('Relia raised' vs. any incident), and it previews the returned fields. It implicitly contrasts with relia_get_incident (singular fetch), though it never names that sibling.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No statement of when to use this versus relia_get_incident for a single incident, or versus relia_status/relia_ack workflows. Usage is only inferable from the name and the word 'Incidents'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), so the description correctly spends its words elsewhere: it discloses the aggregation model and the per-group payload shape, which matters because there is no output schema. It stops short of stating result caps, ordering, or how patterns are clustered.

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?

A single sentence that front-loads the result shape, then appends the alternate mode after a semicolon. No filler, no restatement of the title.

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 6-parameter, no-required, schema-thin read tool, the description supplies the essentials: what comes back, how it is grouped, and how to drill into one pattern. Remaining gaps (search semantics, default window, result limits) are modest and partly covered by the range parameter's own default note.

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?

At 33% schema coverage the description must compensate, and it does well for the least obvious parameter by explaining that `pattern` is a message-pattern key returning that pattern's latest lines. But `search` (the ambiguous one — message text? pattern text?) and `level` are left entirely to the schema, so the compensation is partial.

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 resource (WARN/ERROR log lines from the app), a specific transformation (grouped by message pattern), and the fields exposed per group (count, last seen, code location, example traces). An agent can tell this is the aggregated log-view tool rather than a raw trace or metric tool, though no sibling (e.g. relia_trace) is named to sharpen the contrast.

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 two-mode rule: call as-is for grouped patterns, 'pass `pattern` for that pattern's latest lines'. That resolves the main branching decision inside the tool. It does not say when to prefer this over relia_trace or relia_session, so the guidance is contextual rather than exhaustive.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only say this is a non-read, non-destructive, possibly non-idempotent write; the description adds real behavior beyond that — the call kicks off an automated traffic watch and yields a verified/failed verdict. It does not say whether re-calling is safe or how partial failures are reported, despite idempotentHint=false.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no filler, with the timing condition first and the blocking gate second. Nothing could be cut without losing 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 4-param mutation tool with no output schema, the description covers purpose, timing, and the critical gate. It leaves gaps on idempotency and on what a 'still happening' outcome means for the incident's state, but nothing essential to making the call is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description earns a step above it by stating the consequence of confirm: false ('nothing happens'), which is more than the schema's guidance of when to set it true.

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?

Uses a concrete verb plus resource ('tell Relia an incident is fixed') and explains the follow-on effect (Relia watches traffic to verify). It does not explicitly distinguish itself from near-neighbors like relia_set_verdict or relia_report_change, so an agent must infer which is the right one.

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 clear timing condition ('After the fix is live') and a hard precondition ('Nothing happens without confirm: true'), which tells the agent exactly when the call is appropriate. It stops short of naming alternatives for the cases where the fix isn't live or the incident is the wrong one.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover readOnly, idempotent, non-destructive and closed-world, so the bar is lower. The description adds genuinely new behavioral context: results are limited to what the token can read (authorization scoping) and it enumerates the returned fields, which matters because there is no output schema. Pagination and empty-result behavior are still unmentioned.

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 resource and scope, with the return fields inline. The second sentence about .env.local and src/relia.ts is somewhat cryptic and file-path-heavy, but it earns its place by explaining where a project id comes from.

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 parameters, no output schema and rich annotations, the description supplies the two things an agent actually needs: what comes back (id, name, plan, role, services) and that visibility is token-scoped. Nothing essential for calling this tool 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly adds no parameter noise.

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 the resource and scope precisely: the Relia projects this token can read, with an inline field list (id, name, plan, role, services). The verb is only implied by the title ('List'), but the scope qualifier clearly separates it from relia_create_project and relia_check_setup. It is clear, though it does not explicitly name a sibling alternative.

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 mention of RELIA_PROJECT_ID / project_id suggests this tool is how you discover a project id for other calls, but the description never says 'use this to find your project id' or when not to use it. An agent can infer the use case but gets no explicit routing versus relia_check_setup or relia_setup.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare a non-read-only, non-idempotent, non-destructive write but say nothing about the commit gate; the description supplies that with 'Nothing happens without confirm: true,' which is exactly the kind of two-phase behavior an agent must know. It stops short of saying what a successful report returns or whether repeated reports dedupe.

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 purpose then the hard constraint, with zero filler. The confirm rule is placed last where it is most memorable before invocation.

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 seven-parameter write with no output schema and thin annotations, the definition covers intent and the confirm gate but not the remaining payload fields or what the call returns. Adequate to avoid misuse of confirm, insufficient to fill the fields 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 coverage is only 29% (two of seven parameters documented), so the description must compensate. It maps loosely onto 'kind' by naming deploy/config/flag, but leaves note, service, version and previous_version entirely unexplained — an agent cannot tell what to put in previous_version or how note is used.

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 ('Tell Relia about a deploy, config change or feature flag') plus the effect ('links problems to it and verifies fixes'). The 'it can't see' qualifier implicitly separates it from relia_changes, which presumably surfaces known changes, but that sibling is never named.

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 parenthetical 'e.g. right after deploying a fix' gives one concrete trigger, and 'it can't see' implies a precondition. However, there is no explicit alternative ('use relia_changes to read reported changes') and no guidance on when not to report, so the agent must infer routing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish readOnly/idempotent/non-destructive, so the description rightly spends its words elsewhere: it discloses content boundaries ("Never who the visitor was or what they typed") and the derived-signal types (rage clicks, stuck). It omits operational traits an agent would want — behavior when a session id is unknown, or whether large sessions are truncated.

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?

Roughly three sentences, front-loaded with the outcome, then the contents, then the privacy boundary and the input source. No restatement of the name or title, and every clause carries new information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description steps in and characterizes the return shape as an ordered step list with errors and signals, which is exactly what an agent needs to plan a follow-up. Minor gaps remain: no mention of empty/unknown-session behavior or result-size limits.

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 is documented inline, session_id is not. The description clarifies session_id by pointing to where it comes from (an incident's evidence), but says nothing about project, the more ambiguous parameter in a multi-project token context. Baseline 3 fits given partial coverage.

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?

"What happened in one visit, step by step" names a specific verb (replay a visit) and resource (a single session's step sequence), then enumerates the payload: pages, clicks, failed requests, errors, and Relia-detected patterns. That scope distinguishes it from siblings like relia_trace (distributed tracing) and relia_logs (log search) without needing their 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?

"Takes a session id as found in an incident's evidence" gives a concrete entry point and implies this follows an incident investigation, which is useful. But it never states when NOT to use it or names an alternative (e.g., relia_trace for cross-session or latency questions), so the routing decision is left to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly/idempotent/non-destructive, so the description doesn't need to cover safety. It instead adds genuinely new behavioral context: the output is tailored to the workspace currently open, is framework-specific, and contains two founder decisions (screen replays, user identification) that the agent must surface rather than decide alone. It omits what happens for unsupported frameworks or a stale editor context.

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 what the tool produces, no filler. The second sentence is slightly run-on and the parenthetical founder choices would read better as a separate short clause, but nothing is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the burden of describing the return value, and it does: files to add, load order, source maps, user naming, plus embedded decisions. The main gap is that it doesn't say how the instructions interact with relia_check_setup or what state the repo must be in first.

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?

Only one optional parameter, and the schema already explains it at 100% coverage ('needed when the token covers more than one project'). The description's phrase 'code open in the editor' implicitly documents the default behavior when no project is passed, which is a small but real addition — 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 resource and action: project-specific steps to install Relia in the code currently open in the editor, with a framework list (Node, Next.js, browser apps, Python). It is clearly distinguishable from generic siblings, but it never names relia_check_setup — the obvious adjacent tool — so the agent must infer the routing 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?

Usage is only implied by 'install Relia in the code open in the editor'; there is no explicit when-to-use statement, no mention of pairing with relia_check_setup to verify the result, and no guidance for the case where the user has not yet created a project.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only say this is a non-read-only, non-destructive, non-idempotent write, which conveys little. The description adds substantive behavior: which verdicts require elevated role permissions, that "expected" suppresses future alerts, and that the write is gated behind confirm: true. What is missing is what happens on success or failure, or whether a verdict can be revised later — non-idempotence is declared in annotations but never explained.

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, front-loaded with purpose and then the operational constraints. The parenthetical definitions do real work; nothing is wasted or repeated from the schema verbatim.

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 non-destructive write with no output schema, the description covers the essentials an agent needs to call it safely: allowed verdicts, role gate, and confirm gate. It is slightly thin on outcome (does the incident state change immediately, what is returned) and omits the multi-project requirement, which lives only in the 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?

With 60% schema coverage, the description meaningfully annotates two parameters: the verdict enum values each get a gloss, and confirm is reinforced with an absolute rule. It says nothing about project (multi-project tokens), note, or incident_id beyond what the schema already carries, so the remaining coverage gap is not closed.

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 ("Teach Relia about an incident") and, unusually, defines each of the five verdict values in plain language ("correct (real), wrong (false alarm), expected (by design, stop raising it)..."), which tells an agent exactly what the tool changes. It never distinguishes itself from close siblings like relia_ack or relia_mark_fixed, so an agent still has to infer which tool applies in a given 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?

Gives two real preconditions: role requirements ("expected / mute / bug need an owner or admin") and a mandatory confirmation gate ("Nothing happens without confirm: true"). However, there is no guidance on when to choose this over relia_ack or relia_mark_fixed, and no statement of when-not to raise a verdict, so the selection context is only implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description contributes scope detail by listing the six areas and the incident dimension. It says nothing about data freshness, aggregation window, cost/size of the response, or what happens when the token covers multiple projects.

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?

A single front-loaded sentence with no filler; the leading clause states the deliverable immediately. The parenthetical list of seven areas is dense but each item is informative rather than padding. Slightly list-heavy for what is fundamentally "returns status."

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only overview with no output schema, full annotation coverage and one optional, fully-documented parameter, the description is adequate but thin. It leaves "verdict" undefined and does not describe the shape of the response or how area states and incidents relate, which matters for a broad aggregating 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% and the single `project` parameter is fully documented in the schema, including its multi-project disambiguation purpose. The description does not mention the parameter at all, so it adds no semantics beyond the schema. Baseline 3 applies when the schema carries this load.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the resource ("Relia's verdict for this product") and enumerates exactly what the result contains: area states across uptime, APIs, database, servers, page speed, users and AI agents, plus incidents needing a fix. An agent can form a clear picture of the payload. It stops short of a crisp verb phrase like "Get product status" and never contrasts itself with siblings such as relia_dashboard or relia_uptime, which also surface area state.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use or when-not-to-use guidance, and no mention of alternatives despite an extensive sibling set (relia_dashboard, relia_uptime, relia_list_incidents, relia_vitals all overlap). The implicit framing as a top-level "what needs attention right now" suggests a starting point, but the agent must infer that itself.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered; the description adds real behavioral content by describing the shape of the response (ordered spans with durations and error messages). It says nothing about trace size limits, truncation, or what happens for an unknown or expired trace id.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no filler, front-loaded with what the tool returns before the input requirement. Every clause carries information an agent would otherwise have to guess.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the return-value burden and does so adequately for a single-trace read tool, covering span ordering, durations and error detail. Missing is any note on large-trace behavior or result truncation, which an agent would want before dumping output.

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 only 50%: the project parameter is documented in the schema, but trace_id has no description there. The description compensates by explaining where a valid trace_id comes from (incidents, logs, database results), which is meaningful guidance the schema does not provide.

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 (read/fetch) and resource (one request trace) and enumerates what the result contains: spans in order, services, database calls, outgoing calls, durations, failures. That distinguishes it from aggregate siblings like relia_dashboard or relia_vitals, though it never names the closest alternatives (relia_logs, relia_session) 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?

"Takes a trace id as found in incidents, logs or database results" gives a concrete precondition and tells the agent where to source the id before calling. It stops short of stating when NOT to use it (e.g. when you have only a session or a log search in mind and should use relia_session or relia_logs instead).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds that results reflect current state (up/down now) plus a percentage, and that check failures identify the failing step, which is useful output-shape context. It does not describe freshness, polling cadence, or what happens for a monitor with insufficient history.

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?

A single dense sentence with no filler, and the two content categories are stated up front. The parenthetical field hints are compact and earn their 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 read-only, two-optional-parameter tool with no output schema, the description is close to adequate but doesn't say how monitors and checks are grouped in the response (two sections? per-project?), which matters since two data types are returned. Annotations cover safety, so the remaining gap is structural rather than behavioral.

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 both the range enum (24h/7d) and the project scoping rule are already documented in the schema. The description adds nothing about how range affects uptime percentage calculation or which project is chosen by default. 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 two concrete resources it reports on: uptime monitors (up/down state, uptime %) and Relia's own synthetic checks (passing, failing step). That is specific enough for an agent to know what comes back. It stops short of a clean verb+resource statement and doesn't distinguish itself from nearby siblings like relia_status or relia_vitals.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to call this versus relia_status, relia_vitals, or relia_dashboard, which all plausibly overlap. No prerequisites, no exclusions, no mention of which project context is required.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish the safe read-only, idempotent profile, so the bar is lower. The description adds real value by disclosing the shape of the result: p75 percentiles, per-metric ratings, a period-over-period delta, and a worst-pages list, which tells the agent what it can conclude without a second call.

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?

A single dense sentence with the metric list and output content front-loaded, and no filler. The colon-plus-parenthetical construction is slightly compressed but still parseable in one pass.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the burden of explaining return values and does so concretely (metrics at p75, ratings, delta, worst pages). The only gap is the absence of any scoping or default-range context, which the schema covers.

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 both 'range' (with its enum and 7d default) and 'project' are already documented in the schema; baseline 3 applies. The description contributes nothing about range semantics or project scoping, but nothing is lost either.

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 (web vitals: LCP, INP, CLS, FCP, TTFB) measured at p75 for real visitors, which is far more informative than the title alone. It does not explicitly contrast itself with the nearest siblings (relia_uptime for availability, relia_dashboard for aggregate views), so an agent must infer the boundary.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use or when-not-to-use guidance, no mention of alternatives such as relia_uptime, and no note that 'project' is only needed on multi-project tokens. The agent gets a topic, not a routing rule.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.