Ask a specific business's ANOTS agent a question, by slug. The agent answers from that business's own knowledge base and tools (live data, not scraped HTML). Get the slug from search_businesses.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The business slug (e.g. "gyibb") | |
| question | Yes | The question to ask that business agent |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must cover behavioral traits. It reveals that answers come from the business's own knowledge base and tools, using live data (not scraped HTML). However, it does not mention authentication, rate limits, or error handling (e.g., if slug is invalid).
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?
Two sentences, front-loaded with the action. Every sentence contributes meaningful information: what the tool does, how answers are generated, and where to get the slug. No wasted words.
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 tool with 2 parameters and no output schema, the description explains the source of answers and their live nature. It lacks details on return format or possible errors, but given the simplicity and the presence of a sibling for slug retrieval, it is fairly complete.
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 baseline is 3. The description adds minimal extra meaning beyond the schema: it hints that slug comes from 'search_businesses' and that the question is to be asked. No further enriching details are provided.
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 clearly states the action (ask a question) and the resource (a specific business's ANOTS agent, identified by slug). It distinguishes itself from siblings: 'search_businesses' is for getting slugs, and 'find_and_ask' likely involves searching; this tool is for a specific known business.
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 explicitly tells users to get the slug from 'search_businesses', providing a clear prerequisite. While it doesn't explicitly state when not to use this tool versus alternatives, the context of asking a specific business agent is clear and distinct from siblings.
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.
