Discover the most relevant ANOTS businesses for a need AND ask each one in a single step, returning their answers side by side. The fastest way to answer a purchase-intent or research question across the directory.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many businesses to ask (default 3, max 5) | |
| query | Yes | The need or question to route across the directory |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden of behavioral disclosure. It explains the tool discovers and asks businesses, returning answers, but lacks details on side effects (e.g., does it send real messages?), authentication needs, or rate limits. The behavior is generally clear but not exhaustive.
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 two sentences, directly stating the action and the benefit. It is front-loaded with the key functionality and contains no redundant words. Every sentence earns its place.
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?
Given no output schema and two simple parameters, the description adequately explains the tool's purpose and outcome (answers side by side). It could be improved by specifying the return format or handling of edge cases (e.g., no results), but it is sufficient for typical use.
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?
Both parameters have descriptions in the schema (100% coverage). The description adds context for how they are used (discover and ask in one step) but does not provide details beyond the schema, such as input format constraints or example values. Baseline 3 is appropriate.
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 specifies the tool discovers relevant ANOTS businesses and asks each one in a single step, returning answers side by side. This clearly distinguishes it from siblings: 'search_businesses' (only find) and 'ask_business' (only ask a single business). The verb-resource combination is precise and the use case is explicit.
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 states it is 'the fastest way to answer a purchase-intent or research question across the directory,' providing a clear context for when to use it. However, it does not explicitly state when not to use it or mention alternatives, though the sibling tools provide implicit guidance.
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 has a clearly distinct purpose: search_businesses discovers agents, ask_business queries a specific one by slug, and find_and_ask combines both in one step. No overlap or ambiguity.
All tools follow a verb_noun pattern with snake_case: search_businesses, ask_business, find_and_ask. The naming is consistent and predictable.
Three tools is minimal but well-scoped for a directory server focused on agent discovery and interaction. It covers the essential workflow without unnecessary extras.
The tool set covers the core user-facing functionality: search, ask specific, and combined ask. It lacks listing all agents or administrative tools, but for a client-facing directory it is complete enough.
