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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false; the description adds the auth requirement (sign-in) and a privacy constraint that a person's hours and time off must not be shared with customers. It doesn't describe the response shape, but for a no-output-schema read tool the added behavioral constraints are meaningful.

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 sentences, front-loaded with the owner/sign-in constraint, followed by when-to-use and the privacy caveat. No filler, though the phrase "Private owner information" is slightly vague.

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-only tool with no output schema, the description covers the key things: who can call it, what domains it returns, when to call it, and a privacy rule. It stops short of describing the exact response structure, but it is complete enough to invoke 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline is 4. The description does not need to explain parameter formats.

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 scopes the tool to owners' private configuration data and names the domains it covers (services, prices, team, hours, booking rules). The verb is implicit ("Read") rather than stated, and it does not name specific update siblings, but an agent can tell this is the private owner-side read counterpart to the update tools.

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 explicitly says to read this before changing services, prices, team, hours or booking rules, and gives the prerequisite "Owners only (needs sign-in)". It also routes customer-facing availability questions to find_times, though it doesn't name the update tools it precedes.

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