Get Status Page

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

Annotations already establish readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety bar is low, and the description still adds real value: the page is publicly readable by anyone with the address, and uptime is sampled once a minute from replica readiness plus the uptime check. That tells the agent both the access model and the freshness/derivation of the numbers it will report. It stops short of stating response shape or any throttling, but for a read-only public page the disclosure is solid.

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

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

Three sentences, front-loaded with the primary outcome (the address) before the descriptive detail about components, bars, and incidents. The measurement-methodology sentence is the only borderline one, and it earns its place by explaining where uptime figures come from. No filler or repeated phrasing.

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 convey return values, and it does describe page content well (per-service components, state, uptime, 60 daily bars, 14 days of incidents). However, it never states the actual return shape — whether the address comes back as a bare URL string or as a structured object alongside the data — and the four input parameters remain unexplained, which is a real gap for an agent trying to invoke it correctly.

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

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

Schema description coverage is 0% across four parameters, so the description carries the full explanatory burden and largely drops it. appSlug is only obliquely implied by 'the app's address', and workspaceSlug, env, and region are never explained at all — notably why env (with its production/preview/development enum) changes which page is returned. An agent cannot tell from this text what region scoping means for a status page.

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 first clause states a specific verb and resource: it returns the address of the app's public status page plus what that page displays. That is far more concrete than a restatement of the name. It does not, however, differentiate itself from nearby siblings such as getPublicStatus, getHealth, or streamAppStatus, so an agent must guess which one answers a given status question.

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 described return content; there is no explicit 'use this when' or 'use X instead' guidance across a sibling list that contains getPublicStatus and getHealth. The note that 'every app has the page' is a useful mild hint that the call will not fail for lack of a page, but it is not framed as usage guidance. The existence of an env parameter raises an obvious question (which environment's page?) that is never answered.

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