Bridge status

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

The annotations already establish read-only behavior and openWorldHint=false. The description adds useful observability scope, particularly Mac check-in recency, but does not clarify whether results are cached or gathered live, or what happens when the bridge or Mac is unavailable.

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 single compact sentence fragment efficiently enumerates four distinct status elements with no filler. Although it lacks an explicit verb, every phrase contributes useful selection information.

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

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

For a zero-argument status read, the enumerated components provide nearly enough information to select and invoke the tool correctly. Without an output schema, it still leaves result formats and the precise meaning of open live windows unspecified, and sibling routing remains implicit.

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 no parameters, so the baseline score of 4 applies and no invocation-parameter explanation is necessary. The description appropriately focuses on the information returned rather than inventing input requirements.

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?

Together with the name, the description clearly conveys a bridge status summary containing job counts, unread items, live windows, and the Mac's last check-in. It does not use an explicit verb or directly distinguish this aggregate view from detail-oriented 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?

The field list implies using the tool for a quick operational overview rather than reading individual jobs, messages, or reports. However, it never explicitly states when to choose it over siblings such as list_jobs, read_messages, read_reports, or list_sessions.

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