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

Annotations already declare readOnly, non-destructive and closed-world, and the description adds genuinely new behavior: owner-only auth, no side effects (no provisioning or messages), the warning that 'Configured does not mean tested live', the dependency on AI credits and the paired phone being on, and that it works even when phone service is disabled. These caveats tell the agent how to interpret the result rather than just restating the safety profile.

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 lead sentence is well front-loaded with the owner-only constraint and the read scope, but the caveat cluster is dense and partly redundant: 'No live tests, external probes...' and 'Configured does not mean tested live' say much the same thing, and the paid-plan/AI-credits sentence runs long with semicolons.

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 covers the essential ground: who can call it, what it returns at a high level, what it does not do, and how to interpret a 'configured' verdict. An agent has enough to call it correctly and read the result sensibly.

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 baseline of 4 applies. The description's explanation of what the returned states mean partially compensates for the absent output schema.

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

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

The description names a specific read operation ('Private owner setup read') and enumerates exactly what comes back: shared publication/catalog/booking setup plus separate website_chat, voice and sms states with next actions. It stops short of naming a specific sibling to contrast with, but the 'No live tests, external probes, provisioning or messages' clause implicitly separates it from live-test tools such as receptionist_call_voice.

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 a clear access precondition ('Owners only (needs sign-in)') and explicit exclusions ('No live tests, external probes, provisioning or messages'), plus the useful caveat that 'Works even when phone service is disabled.' It never names an alternative tool or states the decision rule for choosing between this and receptionist_service/receptionist_refresh, so it falls short of a 5.

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