search-teachers-toolFind music teachers in New Zealand listed on Prelude. Filter by instrument and region. Returns teacher names, regions, instruments taught, and a link to their profile page for full details and contact.
| Name | Required | Description | Default |
|---|---|---|---|
| region | No | Filter by NZ region slug (e.g. "auckland", "wellington", "canterbury", "otago"). | |
| instrument | No | Filter by instrument category slug (e.g. "violin", "flute", "trumpet", "piano"). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool returns teacher names, regions, instruments, and a profile link, which is useful. However, it does not mention read-only status, pagination, or behavior when filters are omitted, leaving some ambiguity for a search tool.
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 short, focused sentences: purpose, filtering capability, and return format. It is front-loaded, contains no fluff, and every sentence adds valuable information.
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 only two optional parameters and no output schema, the description covers the essential information: purpose, filters, return fields, and a note about where to get full details. It lacks an explicit statement about optional filtering behavior (e.g., what happens if no filters are provided), but this is a minor gap given the low 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 description coverage is 100% with both parameters (region and instrument) adequately described with examples. The tool description only repeats 'filter by instrument and region' without adding new semantics, so it does not exceed the baseline of 3.
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 tool's purpose: finding music teachers in New Zealand. It distinguishes from sibling tools by specifying the target resource (teachers) and name-dropping Prelude, making it distinct from search-instruments-tool or FAQ/pricing tools.
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 implicitly indicates when to use the tool (whenever you need to find music teachers) and mentions filtering by instrument and region. It does not explicitly exclude alternatives, but the sibling tool names and the focus on teachers provide enough context for an agent to choose this over get-faqs-tool or get-pricing-tool.
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 targets a distinct purpose: FAQs, pricing, instrument search, and teacher search. There is no conceptual overlap; even search-instruments and get-pricing are complementary rather than duplicative.
All tools follow a consistent verb-noun-tool pattern with lowercase and hyphens. 'get' is used for reference lookups and 'search' for discovery, making the naming predictable and uniform.
Four tools is on the lean side but appropriate for the server's scope—covering key information needs for instrument rentals. The count is within a reasonable range and each tool adds value.
The surface covers the main informational needs: FAQs, pricing, instrument discovery, and teacher lookup. Minor gaps exist, such as no direct 'get instrument details' tool, but the search tool returns sufficient details and links.