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

Goes well beyond the annotations: warns that the location appears live immediately unless visible=false, that creating twice makes two locations (consequence of non-idempotency, not just the hint flag), that geocoding is used when lat/lng are absent and may be inaccurate, and that the location:create permission is required. This is precisely the behavioral context an agent needs before a mutation.

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?

Front-loads the operation type and target, then layers in requirements, behavior, edge cases, and the permission/endpoint. Every sentence carries actionable information with no filler, and it is dense but readable for a 26-parameter tool.

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 could say what is returned (e.g. the new location id), which would help an agent chain into get_location or update_location. Otherwise it covers the mutation's side effects, prerequisites, and key parameter constraints thoroughly for a tool of this complexity.

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 coverage is already 100%, so the baseline is 3; the description adds genuine meaning on top by explaining why to supply lat/lng (precise pin vs. approximate geocoding) and the omit-or-all-seven-days constraint on hours. Required fields name and city are called out, though most of the 26 optional fields receive no mention in the description.

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?

Opens with an explicit 'WRITE: add a location to a project's store locator', giving a specific verb, resource, and mutation class. It is trivially distinguishable from sibling get_location, list_locations, and update_location, and the POST endpoint confirms the operation.

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?

Gives concrete when-to-use conditions: set visible=false for coming-soon or draft locations, and call storerocket_list_locations before retrying after an error. It does not explicitly route the agent to storerocket_update_location when modifying an existing location, which is the one obvious sibling alternative left unaddressed.

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