gsc_status

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

No annotations are provided, so the description carries the full behavioral burden. It does well by disclosing that this is a read-only status/connection check, explicitly stating what it reports (OAuth config, connected flag, email, verified properties), and reassuring the agent it is the 'truthful signal' vs whoami. It does not mention error behavior, auth failures, or rate limits, but for a status-query tool these are less critical. It frames itself as authoritative without overstating.

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 well-structured paragraph, front-loaded with the core purpose and then enumerating the specific data returned. The final sentence about whoami is valuable differentiation. It's slightly longer than strictly necessary and the last sentence could arguably be folded into the sibling-differentiation, but every clause adds operational value — no filler.

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

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

For a zero-parameter status tool with no output schema, the description is thorough: it enumerates exactly what fields the agent can expect (connected flag, email, verified property list). It could be improved by noting the possible absence of values (e.g., what happens when not connected — does `connected` default to false or is the field omitted?), but given the tool's simplicity and the lack of output schema, this is a solidly complete description.

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 are 0 parameters and schema description coverage is 100%, so per the rubric the baseline is 4 and no parameter documentation is needed. The description compensates naturally by explaining what the tool RETURNS rather than its inputs. Nothing is missing regarding parameter semantics since there are no parameters to describe.

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 is very specific: it names the verb (GSC connection check), the resource (Google Search Console for this workspace), and precisely enumerates what it returns (OAuth config state, `connected` flag, account email, verified properties list). It explicitly distinguishes from the sibling `whoami` tool by stating 'whoami does not report GSC state — this tool is the truthful signal.' This is excellent sibling differentiation.

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 clearly indicates when to use it (to check GSC connection state for the workspace) and explicitly contrasts with `whoami`, telling the agent that whoami is NOT the right tool for GSC status. It doesn't name a specific alternative tool to use instead for verifying GSC properties, but the exclusion of whoami plus the contextual framing (`authoritative`, `truthful signal`) provides strong usage guidance. Could add more explicit when/why vs. `gsc_overview` and `gsc_query`, which are related siblings.

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