Status pages and uptime monitoring: read status, monitors, incidents and error budgets, and with a write key create monitors, open incidents, post updates, schedule maintenance and record deploys.
Scored across 25 tools
Most tools have clearly distinct retrieval targets (apps, issues, events, pages, dashboards), but some overlap exists between list_issues and list_views, and between get_event/list_issue_events/search_events, which require reading descriptions carefully to distinguish.
The verb_noun pattern (get_*, list_*, search_*) is used consistently across the vast majority of tools, with only minor semantic variation like get_status and get_team that still follow the pattern.
25 tools is at the upper end of the 'heavy' range and approaches being excessive for what appears to be a monitoring/observability platform, with many granular getters that could potentially be consolidated.
The surface covers a broad range of read operations across apps, issues, events, pages, dashboards, releases, and team management, but is notably missing write operations like create/update/delete for most resources, leaving agents unable to modify state.
A page's alert settings: whether alerts go out, repeat, the destinations and people they go to, who is paged and when subscribers hear of an outage.
| Name | Required | Description | Default |
|---|---|---|---|
| pageId | Yes | The page id, from list_pages. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds value by previewing the shape of the returned configuration, which matters because there is no output schema, but it says nothing about pagination, default/empty states, or permissions required.
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 front-loaded sentence with no filler, and the resource (a page's alert settings) leads. Its fragmentary phrasing lacks a verb, but nothing in it 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?
For a simple read-only, single-parameter tool with full schema coverage and annotations, this is close to adequate, and the field enumeration partly substitutes for the absent output schema. It still omits edge-case behavior, such as what is returned when a page has no alert settings configured.
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 a single parameter and 100% schema description coverage, the schema already documents pageId and even cross-references list_pages. The description adds no syntax or provenance detail beyond the schema, 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 name supplies the verb (get) and the description names the specific resource and enumerates what the settings cover (delivery on/off, repetition, destinations, recipients, paging, subscriber notification). It is clearly distinguishable from siblings like list_alert_destinations or list_subscribers, though it does not explicitly contrast 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?
The description offers no when-to-use guidance, no prerequisites, and no alternatives. It never tells the agent to call this after list_pages, nor when to prefer get_alert_settings over list_alert_destinations or list_subscribers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One app: its name, slug, platform, page, DSN (null for a read key), and when it first and last sent an event.
| Name | Required | Description | Default |
|---|---|---|---|
| appId | Yes | The app's id or slug, from list_apps. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and closed-world, so safety is covered. The description adds genuinely useful field-level context, notably that DSN is null for a read key, which is behavioral info beyond the annotations, though it omits error/not-found behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence that lists the returned fields with zero wasted words, matching the low-complexity single-param tool.
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 single-resource read with full schema coverage and readOnly annotations, the description is essentially complete; the only minor gap is not stating behavior when the app is not found or lacks access.
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 appId param is fully documented including that it accepts id or slug from list_apps. The description adds no additional parameter meaning, 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+resource ('One app') and enumerates exactly what it returns (name, slug, platform, page, DSN, first/last event timestamps), clearly distinguishing it from list_apps and the other get_* siblings.
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: it fetches a single app by id, and the schema note 'from list_apps' hints at the list-then-get flow. However, there is no explicit when-to-use-vs-list_apps guidance or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
An app's levels, categories and fields and the rules that sort its events into them, with the schema's version.
| Name | Required | Description | Default |
|---|---|---|---|
| appId | Yes | The app's id or slug, from list_apps. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds useful scope context by disclosing what the schema actually contains (the rules that sort events into levels and categories), but it says nothing about size, caching, or version-fetching behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler, but it is an elliptical fragment rather than a complete statement, which slightly weakens it as a standalone instruction.
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 single-parameter tool with no output schema, describing the returned contents is a reasonable substitute for a return value spec. Still missing is any disambiguation from similarly named siblings, which is the main completeness 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?
With a single parameter and 100% schema description coverage, the schema already documents appId and even points to list_apps as the source. The description adds no parameter-level detail, 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 noun phrase names a specific resource and enumerates its contents (levels, categories, fields, sorting rules, version), which is far more informative than a tautology. However, it omits a verb and gives no explicit differentiation from siblings like list_schema_changes or get_app, so an agent must infer the distinction from the name alone.
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 guidance, no stated prerequisites, and no mention of alternatives such as list_schema_changes for change history or get_app for metadata. The only routing hint ('from list_apps') lives in the schema description, not the tool description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A dashboard with its widgets in order: each one's kind, title, width and query. With data, each widget's numbers over the range.
| Name | Required | Description | Default |
|---|---|---|---|
| data | No | true adds each widget's numbers. | |
| range | No | With data: how far back. Default 14d. | |
| dashboardId | Yes | The dashboard id, from list_dashboards. | |
| environment | No | With data: one environment's events only. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds that widgets come back in order with specific fields and that data toggles numeric payloads, which is useful output context, but it says nothing about what happens on a missing/invalid dashboard id or about response 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?
Two compact sentences, front-loaded with the base return shape and then the optional numeric payload; every clause carries information. The phrasing is telegraphic and slightly awkward, 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 and does so for the widget fields and the data-mode numbers. It leaves out error behavior and any mention that numbers are only added when data=true for a specific range/environment, minor gaps for a 4-parameter read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the enum and defaults for range and explanations for data and environment all present in the schema, so the baseline is 3. The description only echoes the schema's 'with data / over the range' phrasing without adding format, timezone, or default details.
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 spells out the returned shape (widgets with kind, title, width, query, plus numbers when data is set), so an agent knows this is a single-dashboard fetch rather than a listing. It never states the verb explicitly or contrasts itself with list_dashboards, so sibling differentiation is left to inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to reach for this tool versus list_dashboards or search_events, and no prerequisites beyond the schema note that dashboardId comes from list_dashboards. The conditional vocabulary ('With data', 'over the range') implies usage but gives no explicit when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One event by its id, whole as it was stored and scrubbed: exceptions and frames with variables, breadcrumbs, request, user, contexts, tags, extra, the grouping used, and its issue.
| Name | Required | Description | Default |
|---|---|---|---|
| appId | No | An app's id or slug, from list_apps. Holds the call to that app. | |
| eventId | Yes | The event id: 32 hex digits, dashes or not. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds real value beyond that by disclosing the returned content (exceptions, frames with variables, breadcrumbs, request, user, contexts, tags, extra, grouping) and noting data is 'scrubbed', which tells the agent the payload is complete but sanitized.
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 front-loaded sentence that leads with the action and scope, then lists the payload. The trailing comma-list is dense but each item is informative and 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?
For a simple read tool with no output schema, the description usefully enumerates the returned fields so the agent knows what it gets without opening a schema. Annotations cover safety; the main minor gap is absent routing guidance toward sibling search/list tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both appId and eventId are fully documented in the schema (including the 32-hex-digit format). The description only says 'by its id' and adds no syntax or format detail beyond the schema, 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?
States a specific verb+resource (retrieve one event) and scopes it by id, enumerating the payload an agent will get back. It implicitly contrasts with list_issue_events and search_events by emphasizing the single full record, but 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?
'One event by its id' implies the usage condition (you have an id and need the full record), which usefully distinguishes it from search/list tools by implication. However, there is no explicit when-to-use vs when-to-use-search_events guidance or prerequisite statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One issue: its level and category as its app's schema shows them, counts for the environment and range, first and last release, its latest event in short (exception type and value, frames oldest first with file, function, line and source lines, the last 20 breadcrumbs, tags), the most common tag values, and its activity with comments.
| Name | Required | Description | Default |
|---|---|---|---|
| appId | No | An app's id or slug, from list_apps. Holds the call to that app. | |
| range | No | How far back. 14d when left out. | |
| issueId | Yes | The issue's id, or its short id such as WEB-12. | |
| environment | No | An environment's name, such as production. Every one when left out. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false), so the description is free to add value elsewhere, and it does by detailing the returned contents—aggregate counts, first/last release, latest event frames, last 20 breadcrumbs, common tag values, and comments. It omits behavior like not-found handling or event pagination, but with no output schema this payload disclosure is genuinely useful context beyond the 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?
The scope statement is correctly front-loaded, but everything else is compressed into one very long comma-separated sentence. Every listed item is potentially useful, yet the lack of sub-structure makes the payload list hard to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the return-value burden and does so comprehensively, and the annotations handle safety. Gaps remain around missing-issue behavior and how nested collections (breadcrumbs, tags, comments) are bounded, so it is strong 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 coverage is 100%, so the schema fully documents issueId, appId, range, and environment, and the baseline is 3. The phrase 'counts for the environment and range' gestures at two of those params but adds no semantics beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opening with 'One issue:' paired with the get_issue name makes the singular-retrieval scope clear and distinguishes it from list_issues and list_issue_events among the siblings. The remainder enumerates the payload fields rather than restating purpose, so the tool's job lands but is never stated as an explicit verb+resource.
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 guidance, no prerequisites (e.g. that appId is required to scope the call), and no reference to alternatives such as list_issues or search_events. The only usage-adjacent detail, '14d when left out', lives in the schema, not the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Who can open a page: public, behind a password, or private to the people and email domains allowed. The list of people, with when each last signed in, is in the answer for a write key only; a read key gets the rest. A password is never shown.
| Name | Required | Description | Default |
|---|---|---|---|
| pageId | Yes | The page id, from list_pages. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true and openWorldHint=false already covering the safety profile, the description still adds real behavioral context: read vs write key changes what is returned, and passwords are never exposed. It does not, however, describe pagination or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences, front-loaded with the core concept (who can open the page), then the key-type nuance, then the password caveat. Phrasing like 'is in the answer for a write key only' is slightly compressed but 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?
There is no output schema, so the description must convey return contents; it does so partially by specifying the people list with last sign-in times and the key-type gating. The precise response shape is left somewhat vague but the essentials are covered.
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 pageId parameter is already documented as coming from list_pages, so the schema carries the load. The description adds no syntax, format, or sourcing detail beyond it, which is the expected baseline.
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 resource and its conceptual output: a page's access mode (public, password-protected, private to people/email domains). It is clear what the tool returns, though it never explicitly names a sibling tool (e.g., list_pages) to differentiate itself from 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?
Usage is only implied — an agent infers you call this to audit who can open a given page. There is no explicit when-to-use, when-not-to-use, or named alternative, so routing must be inferred from the tool name and the sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One release, by id or, with appId, by version: its new, regressed and resolved issues, and the deploy marker of its version on the app's page.
| Name | Required | Description | Default |
|---|---|---|---|
| appId | No | An app's id or slug, from list_apps. Holds the call to that app. | |
| releaseId | Yes | The release id, or its version with appId. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety and locality are covered by structured data. The description adds useful non-schema context about what the result contains — new, regressed and resolved issues plus the version's deploy marker — but says nothing about pagination, limits, or error behavior when a version/appId pair doesn't match.
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 primary resource ('One release') is front-loaded. The nested commas in 'by id or, with appId, by version' cost a little readability 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 compensates by enumerating the returned payload (issue classifications and the deploy marker). For a two-parameter read tool with full schema coverage, that is close to complete, though a note on lookup failure or response shape would close the remaining 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 description coverage is 100%, so the appId and releaseId semantics ('app id or slug', 'version with appId') are already fully documented in the schema. The description restates the same id-vs-version relationship without adding format examples or constraints, 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?
Names a specific verb+resource (fetch one release) and states its distinguishing scope — a single release identified either by id alone or by version+appId — which sets it apart from list_releases. The phrasing is slightly convoluted but the resource and lookup modes are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (when you need one release rather than a list) and explains the two lookup routes via 'by id or, with appId, by version.' It never names list_releases or another sibling as the alternative, so no explicit when-not guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The current status of a page: headline state, monitors, open incidents, planned maintenance, and the month against the uptime target.
| Name | Required | Description | Default |
|---|---|---|---|
| pageId | Yes | The page id, from list_pages. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=false, so the safety profile is already covered. The description adds real value by disclosing what the read actually contains (headline state, monitors, incidents, maintenance, uptime progress), which is important since there is no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence with no filler, and the resource is named before the list of returned facets. It is well front-loaded, though the colon-list style borders on schema-like enumeration rather than prose guidance.
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 snapshot tool with a fully documented parameter and no output schema, the description's enumeration of returned sections covers the main gap. Missing only usage routing and any note on staleness or refresh timing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema itself cross-references list_pages for the pageId, so the description adds nothing about the parameter. With a single fully documented parameter, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (get) and resource (a page's status) and enumerates the exact facets returned: headline state, monitors, open incidents, planned maintenance, and monthly uptime-target progress. This is specific enough to distinguish it from get_page_access or list_pages, 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?
There is no when-to-use guidance, no mention of prerequisites, and no routing to alternatives such as list_incidents or list_monitors for drill-down. An agent must infer the usage context from the enumerated contents alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The team: its people with their roles, the invitations still open, and its seats. Owner and admins' keys only, and not a key held to one page.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered; the description still adds real value by disclosing the authorization constraint (owner/admin-level key) and that page-scoped keys are rejected. It stops short of mentioning pagination or response shape, but the added auth context is meaningful beyond the 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 short sentences that front-load what the tool returns, followed by the access condition. Every clause carries information; the phrasing 'not a key held to one page' is a touch telegraphic but still compact and content-bearing.
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 zero-parameter read tool with no output schema, the description supplies both the fields returned (people, roles, invitations, seats) and the key-permission requirement, and the annotations cover the read-only nature. It is close to complete; only return formatting/pagination details are absent, and those are minor here.
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 the schema has nothing to document and the baseline for a parameter-free definition is 4. Nothing in the description misleads about inputs, and no parameter guidance is needed.
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 enumerates the resource and its contents concretely — team members with roles, open invitations, seats — so an agent knows exactly what is returned. It does not explicitly name a sibling it might be confused with, but none of the sibling tools (get_app, get_dashboard, list_views, etc.) competes for the same lookup, so differentiation is implicit and adequate.
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 provides an access precondition (owner/admin keys only, and not a key scoped to a single page), which governs whether the call can succeed. However, it gives no when-to-use guidance against alternatives or any positive trigger context, so usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The account's alert destinations, oldest first: email addresses, chat channels, pagers and webhooks, each with the pages that send to it and whether it is confirmed. A key that writes also sees where each points. Not for a key held to one page.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint and a closed-world scope, so the bar is lower; the description still adds real behavioral context beyond them – deterministic oldest-first ordering, conditional visibility based on key permission level, and the failure mode for a page-scoped key. It does not discuss pagination or result size, which keeps it at 4.
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 clauses, none wasted: the resource and ordering come first, contents second, access caveats last. Every sentence carries distinct information with no restatement of the name or schema.
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 and no parameters, the description usefully enumerates the returned fields and their ordering, which is the main thing an agent needs. It omits any statement about pagination or maximum result count, a minor gap for a list endpoint.
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 the baseline of 4 applies; there is no argument syntax to clarify and the description correctly introduces none. The prose defining 'where each points' describes output, not inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource (the account's alert destinations) and elaborates the exact contents of each entry: email addresses, chat channels, pagers, webhooks, the pages that send to them, and confirmation status. Combined with the ordering guarantee ('oldest first'), an agent can distinguish this from get_alert_settings or list_subscribers without opening a 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?
It gives an explicit exclusion ('Not for a key held to one page') and a scope-dependent condition ('A key that writes also sees where each points'), which tells the agent when this call is and isn't appropriate. It stops short of naming a sibling tool to use instead, so it is slightly under 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The account's API keys, newest first: name, prefix, access, the page it is held to, the connected app that made it (madeBy), when it was made and last used. Never the key itself. Owner and admins' keys only; a key held to one page sees the keys for its page.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint/openWorldHint annotations, the description discloses meaningful behavioral facts: secrets are never returned ('Never the key itself'), sort order is newest-first, and the permission/visibility model differs between owner/admin callers and page-scoped keys. These are exactly the traits an agent needs and none are derivable from 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?
Front-loaded with the resource and ordering, then field list, then the security caveat, then the scope rule. It is dense and mostly earns its space, though the compressed phrase 'the page it is held to' and the run-on field list cost a little readability.
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 and no parameters, the description carries the return-value burden well by enumerating returned fields and explicitly excluding the secret value. It does not touch on pagination or result-size limits, which is a minor gap for a list 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?
The tool takes zero parameters, so per the baseline there is nothing for the description to clarify. The field enumeration it does provide is about return values rather than inputs, which is a mild bonus rather than a requirement.
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 opening clause names the specific resource (the account's API keys) and immediately states ordering ('newest first') and the exact fields returned. An agent can distinguish it from siblings like list_apps or list_pages without opening any other definition.
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 states the usage condition clearly: 'Owner and admins' keys only; a key held to one page sees the keys for its page,' which tells the caller both the authorization requirement and the scope-dependent visibility. There is no competing sibling listing API keys, so no when-not guidance is required, but it stops short of explicitly naming that this is the only enumeration path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The apps this key reaches, each a service that sends errors, with its id and slug.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so safety is covered. The description adds value by explaining that an app is 'a service that sends errors' and that entries carry an id and slug, but omits pagination, ordering, and whether the list can be empty.
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, though the phrasing 'The apps this key reaches' is slightly indirect for an enumeration tool. Nothing extraneous is present.
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 needed work of naming the returned fields (id and slug) for a zero-parameter list. It is nearly complete, missing only paging/ordering behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the description to disambiguate; the schema is trivially complete. Baseline 4 applies 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?
It names the resource clearly ('the apps this key reaches') and implicitly conveys a listing operation, distinguishing it from the singular get_app sibling. It never uses an explicit verb like 'list', so the operation type is inferred 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?
There is no indication of when to use this versus get_app for a single app, or when the app list is relevant. No prerequisites, context, or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The team's own dashboards, newest first, each with how many widgets it holds.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many, from 1 to 100. Default 25. | |
| cursor | No | The cursor the last page gave, for the next. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuinely useful behavior beyond that: results are scoped to the team's own dashboards, sorted newest first, and include a widget count per item. It says nothing about pagination mechanics or default/max page size, which the schema covers only at the parameter level.
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 compact sentence that front-loads the scope ('the team's own dashboards') and ordering, then the per-item payload. 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 read-only list tool with no output schema, the description covers scope, ordering, and item shape, and the schema handles pagination. It could be more complete by noting typical volume or that an empty list is possible, but nothing needed to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for limit (1-100, default 25) and cursor (continuation token), so the schema carries the parameter burden. The description adds no parameter-level meaning, which is the expected baseline when coverage is high.
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 the resource (the team's own dashboards), the ordering (newest first), and a notable return attribute (widget count per dashboard). It does not explicitly differentiate from the sibling get_dashboard, which fetches a single dashboard, so it falls just short of 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?
No when-to-use guidance is given. It does not tell the agent to prefer get_dashboard for a single dashboard, nor when a listing is appropriate versus a search. The only implicit cue is the word 'own' implying team scoping.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Incidents and maintenance on a page, newest first, with every update.
| Name | Required | Description | Default |
|---|---|---|---|
| open | No | Only what is still open. | |
| pageId | Yes | The page id, from list_pages. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds ordering ('newest first') and completeness ('with every update'), which is useful behavioral context, but it does not clarify pagination, limits, or the exact meaning of 'with every update'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence with no filler, and the key scope ('on a page') and ordering ('newest first') are front-loaded. Every element is brief and relevant.
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 list tool with fully documented schema and safety annotations, the description adequately conveys what is returned and its ordering. The only minor gap is ambiguity around 'with every update', which could be clearer about whether updates are part of the incident objects or separate entries.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters fully documented in the schema. The description only implies the pageId scope through 'on a page' and does not add semantic detail beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource (incidents and maintenance) and scope (on a page) with ordering (newest first), so the agent can infer a list operation. It does not explicitly contrast with sibling tools like list_issues, but the page-scoped incident/maintenance resource is specific enough to distinguish it from global event or issue lists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'on a page' implies this tool is for page-scoped incident and maintenance data, giving some usage context. However, it does not state when to prefer this over alternatives such as list_issues or search_events, nor does it give prerequisites beyond the required pageId.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
An issue's events, newest first, in an environment and within a range when given. get_event reads one whole.
| Name | Required | Description | Default |
|---|---|---|---|
| appId | No | An app's id or slug, from list_apps. Holds the call to that app. | |
| limit | No | How many, from 1 to 100. Default 25. | |
| range | No | How far back. Every event kept when left out. | |
| cursor | No | The cursor the last page gave, for the next one. | |
| issueId | Yes | The issue's id, or its short id such as WEB-12. | |
| environment | No | An environment's name, such as production. Every one when left out. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful ordering (newest first) and optional-filter semantics, but says nothing about pagination or how cursor pages behave, leaving a notable behavioral gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the resource and ordering front-loaded, then the sibling disambiguation. Extremely economical, though the telegraphic style borders on under-specification rather than clean conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with full schema coverage and no output schema, the description covers the resource, ordering, optional filters, and the sibling alternative. The only omission is pagination/cursor behavior, which is a minor gap given the schema documents the cursor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter (appId, limit, range, cursor, issueId, environment) is already documented in the schema. The description echoes the environment/range filtering but adds no syntax or format detail beyond what the schema provides; 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 ('An issue's events, newest first') and explicitly contrasts with the sibling get_event ('reads one whole'), so an agent can route between the two. The phrasing is somewhat fragmentary but the purpose is unambiguous.
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?
Names the alternative (get_event) and its distinguishing behavior of returning a single full event, giving clear context for when to list vs. fetch one. It does not state exclusions or prerequisites, but the sibling routing is explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Issues as the dashboard lists them, with counts for the environment and range: a tab (unresolved by default), a sort, and q in the search language (statoss.com/docs/search) as Issues reads it: words, /regex/, level:error, category:billing, priority:high, assigned:me, is:unresolved, age:-24h, field:value, with -term or !key:value to leave out, a OR b, key:[a, b], * at either end of a value, key:>500 and has:key. Pages with cursor.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | The search, as Issues reads it. | |
| tab | No | unresolved, review, regressed, archived or resolved. | |
| apps | No | Apps by id or slug, from list_apps; every app the key reaches when left out. appId wins over it. | |
| sort | No | last (seen), first (seen), events or users. | |
| appId | No | An app's id or slug, from list_apps. Holds the call to that app. | |
| limit | No | How many, from 1 to 100. Default 25. | |
| range | No | How far back. 14d when left out. | |
| cursor | No | The cursor the last page gave, for the next one. | |
| environment | No | An environment's name, such as production. Every one when left out. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds useful behavioral context: returned counts for the environment and range, the unresolved tab default, and cursor-based paging. It stops there and says nothing about ordering guarantees or the shape of returned issues beyond counts.
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 operator enumeration is dense and load-bearing for q, but it is crammed into one sprawling sentence mixing defaults, search syntax, and pagination, making it hard to parse in one pass. The tab/sort context should be separated from the search-language catalogue for cleaner front-loading.
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 9-parameter, no-required-argument list tool with no output schema, the description covers defaults, counts in the response, the full q search language, and cursor paging, which is nearly everything an agent needs. It omits only the interaction/precedence among tab, q, and range, which would make 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 the baseline is 3, but the description goes well beyond the schema for q, enumerating the search language (words, /regex/, field:value, negation with -/!, OR, ranges, wildcards, comparisons) that the schema only labels as 'the search, as Issues reads it.' It also confirms the unresolved tab default. Remaining parameters rely on the schema, which already documents them.
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 (issues) and scope (as the dashboard lists them, with per-environment/range counts), and the mention of tab/sort/q makes it clearly the list endpoint. It is distinguishable from get_issue and list_issue_events, though the phrasing 'as the dashboard lists them' is slightly indirect rather than a crisp verb+resource statement.
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?
Discloses a default ('a tab, unresolved by default') and the pagination mechanism, which implies intended use, but offers no explicit when-to-use versus siblings (e.g., get_issue for a single issue) or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The monitors on a page with their type, target, state and last result.
| Name | Required | Description | Default |
|---|---|---|---|
| pageId | Yes | The page id, from list_pages. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds the returned field set (type, target, state, last result), which is genuine context, but says nothing about ordering, pagination, or limits for what could be a list of arbitrary 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 phrase with zero filler. It is slightly clipped (no verb framing the action) but 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 one-parameter read tool with no output schema, the description carries the return-value information an agent needs by naming the fields returned. Nothing critical is missing, though multi-page or large-result behavior is unaddressed.
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 parameter is fully described there, including where to obtain the page id. The description adds no parameter detail beyond the implicit 'on a page' scoping, so 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?
States the resource (monitors) and the scoping qualifier (on a page), plus the fields each monitor carries. An agent can tell it lists monitors rather than configuring them, though there is no explicit contrast with any sibling (no monitor-specific sibling exists, so little differentiation is needed).
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 offers no when-to-use or when-not-to-use guidance and names no alternative. The only orientation ('page id, from list_pages') lives in the schema, not in the description, so the description itself gives no routing help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every status page this key reaches, with ids and addresses.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false), so the description only needs to add context. It does contribute the access-scoping behavior and the shape of returned data, but says nothing about ordering, pagination, or size limits for a potentially unbounded list.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single short sentence with zero filler; the resource and its scope are front-loaded and everything stated earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless list tool with no output schema, the description covers the essentials: what is listed, the scope of the listing, and the key fields returned. It stops short of noting pagination or result limits, which would matter for a potentially large collection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters, so the baseline is 4. The description adds no parameter meaning, and none is needed since the schema has no properties to document.
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 (status pages) and a distinct scope — every page 'this key reaches' — plus what comes back (ids and addresses). It is distinguishable from siblings like get_page_access and list_subscribers, though it never uses an explicit verb like 'list'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'this key reaches' hints that results are permission-scoped, which is useful context, but there is no explicit when-to-use guidance and no mention of any alternative tool (e.g. get_status or get_page_access) or when not to call it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Releases of the key's apps, newest first, each with its events and the issues it brought, brought back and resolved. Pages with cursor.
| Name | Required | Description | Default |
|---|---|---|---|
| apps | No | Apps by id or slug, from list_apps; every app the key reaches when left out. appId wins over it. | |
| appId | No | An app's id or slug, from list_apps. Holds the call to that app. | |
| limit | No | How many, from 1 to 100. Default 25. | |
| cursor | No | The cursor the last page gave, for the next one. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuine behavioral context beyond that: results are ordered newest first, each release carries its events and associated issues, and the response is cursor-paginated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One front-loaded sentence with the resource and ordering stated first, then content, then pagination. It is tight, though the clause 'the issues it brought, brought back and resolved' is dense enough to require a second 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?
With no output schema, the description carries the burden of describing returns, and it does outline that each release includes events and issues plus ordering. Combined with fully documented parameters and pagination, an agent has nearly everything needed, with only the shape of the issue/event sub-objects left unspecified.
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 four parameters (apps, appId, limit, cursor) are already documented with defaults and precedence rules. The description only echoes the cursor paging behavior ('Pages with cursor') and adds no new parameter meaning, making the baseline 3 correct.
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+resource (releases of the key's apps) plus the ordering (newest first) and the nested content (events and the issues they brought, brought back, resolved). It is distinguishable from the sibling get_release by its list/multi-item scope, 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?
There is no when-to-use or when-not-to-use guidance, and no reference to alternatives such as get_release for a single release. The scope hint (apps, pagination) implies broad listing but leaves the routing decision to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
An app's schema changes, newest first: who made each, how, what it did, and whether it was undone.
| Name | Required | Description | Default |
|---|---|---|---|
| appId | Yes | The app's id or slug, from list_apps. | |
| limit | No | How many, from 1 to 100. Default 20. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false). Because no output schema exists, the description carries return-shape information and does so concretely: newest-first ordering and the per-entry contents (actor, method, effect, whether it was undone). It does not describe pagination or truncation behaviour for the 1-100 limit, keeping it below 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 tightly-packed sentence that front-loads the resource and ordering before the entry fields. No wasted words and nothing repeated from the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter, read-only list tool with full schema coverage and no output schema, the description supplies the ordering and entry contents an agent needs to interpret results. It is complete enough except for pagination/limit-application behaviour.
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 appId (id or slug, from list_apps) and limit (1-100, default 20) are already fully documented in the schema. The description adds nothing about parameter meaning, 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?
Names the specific resource (an app's schema changes) and, via 'schema changes' versus siblings like get_app_schema or get_app, an agent can infer this is the historical log rather than the current schema state. The verb 'list' is only implied by the name, not stated in the description, and no sibling is named explicitly, 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?
Usage is implied by the resource: call this to see past schema changes for an app. There is no explicit when-to-use versus when-not, no mention of when get_app_schema would be preferable, and no prerequisites stated. Adequate but with a clear gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
An app's uploaded source map bundles, newest first: release, dist, how many maps and their debug ids, size. Pages with cursor.
| Name | Required | Description | Default |
|---|---|---|---|
| appId | Yes | An app's id or slug, from list_apps. Holds the call to that app. | |
| limit | No | How many, from 1 to 100. Default 25. | |
| cursor | No | The cursor the last page gave, for the next one. | |
| release | No | Only the bundles of this release. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavior beyond that: results are ordered 'newest first', the bundle fields returned (release, dist, map count, debug ids, size) are disclosed, and pagination is signalled ('Pages with cursor').
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 most important element (what you are listing) is front-loaded, followed by return fields and pagination. Terse to the point of being fragmentary, 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?
There is no output schema, so the description usefully enumerates the returned bundle fields and ordering, and it covers pagination. Parameters and safety are handled by the schema and annotations, leaving no material gap for an agent to call this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters are already documented in the schema and the baseline is 3. The description confirms the app-scoping of appId and the paging nature of cursor but adds no syntax or format detail the schema lacks.
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 (an app's uploaded source map bundles) and its scope (held to one app), which is clearly distinct from siblings like list_releases or list_apps. It stops short of an explicit verb form ('List ...'), but the intended operation is unambiguous.
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 fragment 'An app's uploaded source map bundles' suggests you call it to inspect source maps for a given app, and the required appId reinforces this. There is no explicit when-to-use, when-not-to-use, or reference to an alternative tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A page's subscribers, newest first, with the counts by kind and the page's allowance. A webhook shows its host, not its URL.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Only this kind. | |
| limit | No | How many, from 1 to 100. Default 25. | |
| cursor | No | The cursor the last page gave, for the next. | |
| pageId | Yes | The page id, from list_pages. | |
| status | No | Only confirmed, or only unconfirmed ones. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true and openWorldHint=false, but the description adds real context the annotations cannot: results are sorted newest first, the response includes per-kind counts and the page's allowance, and webhook subscribers are rendered by host rather than full URL (a meaningful data-shape caveat).
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 core purpose front-loaded and the webhook-display caveat kept to a single trailing clause. Every sentence carries information an agent cannot get from the structured fields.
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 and five parameters, the description carries the return-shape burden and largely does so by describing ordering, aggregate counts, and the allowance. It is slightly thin on cursor/pagination behavior, which an agent must infer from the schema's cursor field.
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 enum, limit range, cursor, and status semantics are already fully documented in the schema. The description only echoes one of these indirectly via 'counts by kind', 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?
It names a specific resource ('a page's subscribers') and a specific ordering ('newest first'), which is enough to distinguish it from generic list tools. It does not, however, differentiate itself from siblings like list_pages or get_page_access, and 'page' is left to be inferred as the same page concept used elsewhere.
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 reach for this tool versus alternatives such as list_pages or get_page_access; usage is only implied by the list-plus-filter shape. An agent must infer that filtering by kind/status is done here rather than via a narrower sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The team's saved views: a name, the search and the filter bar, each with the link that opens it. In one area (logs, issues, explore) or all.
| Name | Required | Description | Default |
|---|---|---|---|
| area | No | logs, issues or explore. Every area when left out. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds value beyond that by disclosing the shape of what comes back (name, search, filter bar, and an opening link) in the absence of an output schema. It omits permission requirements and whether the view list is paginated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences with no filler. The clipped phrasing ('a name, the search and the filter bar') is efficient, though the sentence is somewhat elliptical and reads more like a note than a specification.
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 zero-required-param list tool with no output schema, the description covers the resource, the filter dimension, and the returned fields — enough for an agent to call it correctly. Missing only permission/scale caveats, which are minor here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single enum param is fully documented in the schema, so baseline 3 applies. The description mirrors the schema's meaning ('In one area (logs, issues, explore) or all') without adding format or default nuance beyond it.
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?
Identifies the resource precisely (the team's saved views) and enumerates what a view contains, which separates it from siblings like list_dashboards or list_pages. The verb 'list' is only implied by the tool name rather than stated, but the resource and scope are unambiguous.
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 context is implied rather than stated: saved views are a browsing/retrieval operation scoped by area. No explicit when-to-use or when-not-to-use guidance and no alternatives named among the many list_* siblings, leaving the agent to infer fit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Events as Explore finds them, newest first: in an environment and range, at levels and in categories (by key or label), with fields holding values, and with words in the title, culprit or message. q is the search language (statoss.com/docs/search) as Explore reads it: words, phrases and /regex/ in the title, culprit or message, level:, category:, field:value, with -term or !key:value to leave out, a OR b, key:[a, b], * at either end of a value, key:>500 and has:key. Pages with cursor.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | The search, as Explore reads it. | |
| apps | No | Apps by id or slug, from list_apps; every app the key reaches when left out. appId wins over it. | |
| appId | No | An app's id or slug, from list_apps. Holds the call to that app. | |
| level | No | Levels, by key or label. | |
| limit | No | How many, from 1 to 100. Default 25. | |
| range | No | How far back. 14d when left out. | |
| cursor | No | The cursor the last page gave, for the next one. | |
| fields | No | Fields and the value each must hold: {"route": "/pay"}. Up to 10. | |
| category | No | Categories, by key or label. | |
| environment | No | An environment's name, such as production. Every one when left out. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds ordering ('newest first') and pagination ('Pages with cursor'), but omits result caps, cost/rate behavior, and how defaults expand scope when filters are omitted — details that matter for a 10-parameter search.
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 very long, comma-piled sentences with no front-loaded list of what matters. The phrase 'in the title, culprit or message' is stated twice — once in the opening scope enumeration and again inside the q explanation — which is pure duplication.
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 10-parameter, no-required-args search with no output schema, the description covers filtering vocabulary, defaults (partly via schema), and pagination, but never describes the returned event shape and gives no guidance on combining q with structured filters. Adequate, with clear 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 the baseline is 3, but the description meaningfully exceeds it by spelling out the q grammar (phrases, /regex/, level:, category:, field:value, -term, !key:value, a OR b, key:[a, b], wildcards, key:>500, has:key) that the schema only points at via a docs URL. It falls short of 5 because it never explains whether q composes with or overrides the structured filters like level, category, and fields.
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 (events) with scope (environment, range, levels, categories, fields, text), so an agent can tell this is a filtered event search. However, it never names or contrasts the nearest siblings (get_event for a single event, list_issue_events for an issue's event stream), leaving the 'Explore' framing as the only differentiator.
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 the enumeration of filters; there is no statement of when to reach for this tool versus get_event or list_issue_events, and no note on how the free-text q interacts with the structured filters. The reader must infer the triage-style search intent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_appget_app_schemaget_dashboardget_eventget_issueget_releaselist_appslist_dashboardslist_issue_eventslist_issueslist_releaseslist_schema_changeslist_sourcemapslist_viewssearch_eventsget_alert_settingsget_page_accessget_teamlist_alert_destinationslist_api_keyslist_subscribersget_statuslist_incidentslist_monitorslist_pages
Add one secure layer between your agents and this server.