Estroni Storefront

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

With no annotations, the description carries the full behavioral burden. It does disclose a useful behavior — setting policy_types returns the store's written policies as full text plus URL, versus FAQ-only answers when omitted — which tells the agent how the response shape changes. It says nothing about permissions, rate limits, or result volume, leaving gaps for a tool with zero annotation coverage.

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 purpose is front-loaded in the first sentence, and the example list is compact enough to be genuinely useful rather than padding. The closing line about policy_types is a slightly abrupt pivot but earns its place by flagging a non-obvious behavior.

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 three-parameter search tool with no output schema and no annotations, the description covers what the tool does, what can be asked, and how policy_types alters the return. Nothing critical to correct invocation is missing, though guidance on combined policy_types usage or empty-result behavior would round it out.

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 description coverage is 100%, so the schema already documents all three parameters and the baseline would be 3. The description adds meaning beyond that by explaining the behavioral effect of policy_types (retrieving full written policy text and a URL) rather than merely restating the enum, which is genuine added value.

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?

States a specific action (get facts) against a specific resource (store policies, products, services), backed by four concrete example questions that make the scope unmistakable. No siblings exist to differentiate from, so the only thing keeping it from a 5 is the slight vagueness of 'facts' as the operative verb.

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 example questions implicitly show the kind of request this tool serves (return policy, shipping, phone, hours), which is real guidance for a natural-language search tool. However, there is no explicit statement of when NOT to use it or which inputs select an alternative path, so usage is only implied.

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