Find cloud storage plans matching filters. Boolean filters require the feature to be verified present; max_monthly_price compares against the cheapest per-month equivalent; plan_type is individual/team/enterprise.
| Name | Required | Description | Default |
|---|---|---|---|
| gdpr | No | ||
| hipaa | No | ||
| free_only | No | ||
| plan_type | No | ||
| lifetime_only | No | ||
| min_storage_gb | No | ||
| zero_knowledge | No | ||
| two_factor_auth | No | ||
| max_monthly_price | No | ||
| end_to_end_encryption | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It adds meaningful semantics beyond the schema: boolean filters are strict ('verified present'), max_monthly_price uses a normalized 'cheapest per-month equivalent,' and plan_type has enumerated values. This helps avoid misinterpreting filter behavior. Some traits (e.g., behavior with no filters, result ordering) are not disclosed, so it is not perfect.
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 description is three concise sentences, each earning its place: the first states the core purpose, the second clarifies boolean and price filter behavior, and the third defines plan_type values. It is front-loaded, avoids fluff, and is easy to scan.
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?
The tool has 10 parameters, no output schema, and no annotations, requiring a fairly complete description. It covers the most important filter semantics and gives enough to invoke the tool correctly, where the result is clearly a list of matching providers. However, it does not mention default behavior (no filters provided), result size/limits, or any specifics about the response format, leaving some gaps in the full usage context.
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 0%, so the description must compensate. It does so by explaining the ambiguous parameters: the general boolean filter rule covers all six booleans, and max_monthly_price and plan_type get explicit semantic clarification. The remaining parameters (min_storage_gb, free_only, lifetime_only) have self-explanatory names/units, so the description effectively covers the meaningful semantics of nearly all 10 parameters.
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 opens with 'Find cloud storage plans matching filters,' which uses a specific verb ('Find'), a clear resource ('cloud storage plans'), and a clear scope ('matching filters'). This distinguishes it from siblings like list_providers (unfiltered listing) and compare_providers (comparing), making the tool's role immediately obvious.
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 description provides clear context on when to use the tool: whenever you need to find/filter storage plans rather than compare or retrieve a specific one. It also explains how key filters behave ('Boolean filters require the feature to be verified present; max_monthly_price compares against the cheapest per-month equivalent'), giving practical usage guidance, though it does not name explicit alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool serves a distinct purpose: listing all providers, filtering with find_providers, drilling into one provider, comparing multiple, and viewing price history. No two tools have overlapping responsibilities, making misselection unlikely.
Four of the five tools follow a clear verb_noun pattern (compare, find, get, list), but 'price_history' breaks the pattern as a noun phrase. Despite the deviation, the names are unambiguous and predictable.
Five tools is a tight, well-scoped set for a provider/plan lookup service. Each tool covers a necessary query type without redundancy or bloat, fitting the expected 3-15 range perfectly.
The tool surface covers the full lifecycle of a read-only provider database: list, filter, get detailed, compare, and historical price tracking. There are no obvious gaps; all common queries are addressed.
