Citation-backed honey producer discovery by place or varietal. Free, no auth.
Scored across 4 tools
The four tools collapse into two near-duplicate pairs: find_local_producers vs search both locate producers by place/varietal, and fetch vs get_producer both return the full record for a single producer (differing only by id vs slug). An agent has no clear rule for choosing within each pair, so misselection is likely.
Names mix bare verbs (fetch, search) with verb_noun patterns (find_local_producers, get_producer), and 'fetch' vs 'get' are synonym verbs used for essentially the same single-record operation. The convention is readable but genuinely inconsistent.
Four tools is numerically fine for a directory lookup, but the surface is inefficient rather than well-scoped, since two of the four are redundant with their siblings. The count is borderline because the slimmest possible correct set would be two.
For a read-only producer directory it covers discovery (search, proximity, varietal) and detail retrieval, with honest empty-result handling, so there are no real dead ends. Minor gaps like varietal-only listing or result pagination are workable around.
Retrieve the full Melvea record for one producer by id, returning name, location, declared honey types, contact info, verification status, and profile URL. Use after search to pull complete detail on a result. For richer Deep Research answers, fetch the top several search results rather than just one, so varietal and contact detail are populated across the set.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The producer id/slug from a search result, e.g. 'cloister-honey'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set readOnlyHint=true, and description confirms retrieval. Adds behavioral context by stating it returns a full record and recommends fetching multiple for deep research, which implies idempotency.
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, no wasted words. First sentence states purpose and returns. Second sentence gives usage guidance. Efficient and front-loaded.
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?
Without output schema, description lists specific fields returned (name, location, etc.). Provides usage context (after search, for deep research). Slight omission of error handling or limits, but adequate for a simple fetch.
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 provides description for the 'id' parameter (100% coverage). Description adds context with an example ('e.g. 'cloister-honey'') and clarifies that the id comes from a search result.
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?
Description uses specific verb 'Retrieve' and resource 'full Melvea record for one producer by id'. It lists returned fields and distinguishes from sibling tools like 'search' and 'get_producer'.
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?
Explicitly says 'Use after search to pull complete detail on a result.' Provides specific recommendation for Deep Research: fetch top several results. Does not mention when not to use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find local honey producers near a specific place, optionally filtered by honey varietal. Requires a place name in near — never call this tool without one. Returns producer name, location, distance, distance_basis (farm_location vs town_center), declared honey types, and contact channels (website, etc.) where listed, ordered by distance. When distance_basis is town_center, describe the producer as in/near their city rather than quoting the exact mile distance. Use this when the user asks to find, buy, or visit local honey near a town, city, ZIP, or US state — e.g. 'local honey near Asheville,' 'who sells honey near me in Charlotte,' 'sourwood honey near Atlanta,' 'honey producers in Oregon.' Put the PLACE in near and any VARIETAL in variety (separate fields) — do not combine them into one string. US state names (e.g. 'Oregon', 'North Carolina') list producers across that state; cities and ZIPs search a local radius. Named sub-state regions (e.g. 'Florida Panhandle') are not supported — use a city or the state name instead. Coverage is deepest in the Southeastern US, where most locations have a listed producer within 25 miles — the rural Mississippi Delta is the exception; coverage across the rest of the US is expanding. Don't use this for general honey questions (what is sourwood honey, health benefits, recipes) — it only returns directory listings, not knowledge. If no producer is listed nearby, the tool returns an honest empty result with a coverage note; relay that rather than inventing producers.
| Name | Required | Description | Default |
|---|---|---|---|
| near | Yes | REQUIRED. The place to search around — a city, town, ZIP, or US state name/code. Examples: 'Charlotte, NC', '28202', 'Asheville', 'Oregon', 'OR', 'North Carolina'. Do NOT put a honey varietal in this field (use `variety` for that). Do NOT pass named sub-state regions (e.g. 'Florida Panhandle') — ask for a city or the state instead. If the user has not named a place (e.g. only said 'near me'), ask them for their city, ZIP, or state BEFORE calling this tool — do not invent a location and do not call with an empty near. | |
| limit | No | Maximum number of producers to return, ordered nearest first. | |
| variety | No | Optional honey varietal filter, e.g. 'sourwood', 'tupelo', 'clover', 'wildflower', 'orange blossom'. Pass this SEPARATELY from `near` — e.g. near='Asheville, NC' and variety='sourwood', never near='Asheville, NC sourwood'. Omit to return all local producers regardless of type. Do not pass a place name here. | |
| radius_km | No | Search radius in kilometers for city/ZIP queries only (ignored for US state queries). Defaults to a standard local radius (~80 km). For US query points, if nothing is found within that radius the tool automatically widens to ~121 km (75 miles), then to ~241 km (150 miles), flagging results as farther than typical. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover readOnlyHint, so the description carries the rest: ordering by distance, the distance_basis distinction (farm_location vs town_center) and how to phrase town_center results, automatic radius widening, geographic coverage caveats, and honest empty-result behavior.
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?
Front-loaded with purpose, then constraints, examples, and caveats in a logical order. It is long and overlaps noticeably with the schema text, but nearly every sentence adds operative guidance.
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?
No output schema exists, yet the description enumerates the return fields, ordering, and the empty-result case. Combined with the fully documented schema, an agent has everything needed to call and interpret this tool.
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 every parameter thoroughly. The description reinforces the near/variety separation and the place-vs-state behavior, but mostly restates what the schema provides, so the baseline 3 applies.
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 verb+resource ('Find local honey producers') with scope ('near a specific place, optionally filtered by honey varietal'), and clearly distinguishes itself from siblings by noting it returns directory listings, not knowledge.
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?
Explicit about when to use (user asks to find, buy, or visit local honey near a town/city/ZIP/state) with concrete example queries, and when not to use (general honey questions like health benefits or recipes). Also states the prerequisite that a place name must be supplied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full directory profile for one specific producer by its slug, including location, declared honey types, contact channels, and verification status. Use this after find_local_producers (or search) when the user wants more detail on a particular listing. Don't use this to browse or search — it requires an exact producer slug.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The exact producer slug, as returned in the slug/id field of a find_local_producers or search result, e.g. 'cloister-honey', 'asheville-bee-charmer'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=true, so the description adds value by specifying the return contents (location, honey types, etc.) and the exact slug requirement. No contradictions.
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, each essential: first defines purpose and output, second gives usage guidance. 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 single-parameter read tool with good annotations and sibling context, the description fully covers when to use, what to expect, and how it relates to other tools. No output schema needed given the description of return contents.
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 coverage is 100% with a detailed description for 'slug'. The tool description reiterates the slug requirement but adds no new semantic information beyond the schema.
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 uses a specific verb ('Get') and resource ('full directory profile') and clearly distinguishes this from sibling tools by stating it is for one specific producer by slug, contrasting with find_local_producers and search which are for browsing.
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?
Explicitly states when to use ('after find_local_producers or search when the user wants more detail') and when not to use ('don't use this to browse or search'), providing clear alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Melvea local honey directory by free-text query and return matching producers as a list of results (id, title, url). Designed for ChatGPT Deep Research and Company Knowledge. Use for any local-honey discovery query that names or implies a place; the tool parses place and varietal from the query. Returns an honest empty list when nothing matches — never fabricate. Pair with fetch to retrieve full producer detail.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | A free-text local-honey query, e.g. 'sourwood honey near Asheville NC' or 'local honey producers in Charlotte'. The tool extracts the place and any varietal automatically; a varietal alone (e.g. 'tupelo honey') is treated as a type, not a place. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds important behavior beyond the readOnlyHint annotation: it states that the tool 'parses place and varietal from the query', that it 'never fabricates' results, and that it returns an honest empty list. These are critical for agent decision-making.
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 concise with four sentences, each serving a purpose: defining the action, noting intended use cases, explaining behavior, and linking to a sibling tool. No fluff.
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 one parameter and no output schema, the description is comprehensive. It covers purpose, usage guidance, behavioral transparency, and parameter semantics. It also references the sibling tool 'fetch' for completeness.
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?
Although the schema covers 100% of parameters, the description adds meaningful context: it explains how the query is interpreted (tool extracts place and varietal), and provides an example. This goes beyond the schema's dry description and helps the agent format queries correctly.
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 it searches a local honey directory by free-text query and returns matching producers. It specifies the target resource (Melvea local honey directory) and the action (search and return results). It distinguishes from sibling 'fetch' by noting that fetch retrieves full detail.
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 says to use it for 'any local-honey discovery query that names or implies a place' and that it 'returns an honest empty list when nothing matches — never fabricate.' While it doesn't explicitly exclude other use cases, it provides clear context and mentions pairing with fetch, indicating appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
find_local_producers1 field changedInput schema / properties / radius_km / descriptionPrevious value: -"Search radius in kilometers for city/ZIP queries only (ignored for US state queries). Defaults to a standard local radius. Within the Southeastern US, the tool automatically widens to ~120 km (75 miles) if nothing is found closer."New value: +"Search radius in kilometers for city/ZIP queries only (ignored for US state queries). Defaults to a standard local radius (~80 km). For US query points, if nothing is found within that radius the tool automatically widens to ~121 km (75 miles), then to ~241 km (150 miles), flagging results as farther than typical."find_local_producers2 fields changedInput schema / properties / near / descriptionPrevious value: -"REQUIRED. The place to search around — only a city, town, ZIP, US state name/code, or known region. Examples: 'Charlotte, NC', '28202', 'Asheville', 'Oregon', 'OR', 'Florida Panhandle'. Do NOT put a honey varietal in this field (use `variety` for that). If the user has not named a place (e.g. only said 'near me'), ask them for their city, ZIP, or state BEFORE calling this tool — do not invent a location and do not call with an empty near."New value: +"REQUIRED. The place to search around — a city, town, ZIP, or US state name/code. Examples: 'Charlotte, NC', '28202', 'Asheville', 'Oregon', 'OR', 'North Carolina'. Do NOT put a honey varietal in this field (use `variety` for that). Do NOT pass named sub-state regions (e.g. 'Florida Panhandle') — ask for a city or the state instead. If the user has not named a place (e.g. only said 'near me'), ask them for their city, ZIP, or state BEFORE calling this tool — do not invent a location and do not call with an empty near."Input schema / properties / radius_km / descriptionPrevious value: -"Search radius in kilometers. Defaults to a standard local radius. Within the Southeastern US, the tool automatically widens to ~120 km (75 miles) if nothing is found closer."New value: +"Search radius in kilometers for city/ZIP queries only (ignored for US state queries). Defaults to a standard local radius. Within the Southeastern US, the tool automatically widens to ~120 km (75 miles) if nothing is found closer."find_local_producers4 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / near / descriptionPrevious value: -"The place to search around — a city, town, ZIP code, or region. Examples: 'Charlotte, NC', '28202', 'Asheville', 'the Florida Keys'. If the user says 'near me' without naming a place, ask them for their city or ZIP first rather than guessing."New value: +"REQUIRED. The place to search around — only a city, town, ZIP, US state name/code, or known region. Examples: 'Charlotte, NC', '28202', 'Asheville', 'Oregon', 'OR', 'Florida Panhandle'. Do NOT put a honey varietal in this field (use `variety` for that). If the user has not named a place (e.g. only said 'near me'), ask them for their city, ZIP, or state BEFORE calling this tool — do not invent a location and do not call with an empty near."Input schema / properties / near / minLengthAdded value: +1Input schema / properties / variety / descriptionPrevious value: -"A honey varietal to filter by, e.g. 'sourwood', 'tupelo', 'wildflower', 'orange blossom'. Omit to return all local producers regardless of type. Do not pass a place name here."New value: +"Optional honey varietal filter, e.g. 'sourwood', 'tupelo', 'clover', 'wildflower', 'orange blossom'. Pass this SEPARATELY from `near` — e.g. near='Asheville, NC' and variety='sourwood', never near='Asheville, NC sourwood'. Omit to return all local producers regardless of type. Do not pass a place name here."fetch1 field changedInput schema / properties / id / descriptionPrevious value: -"Producer id (slug) from a search result, e.g. \"cloister-honey\"."New value: +"The producer id/slug from a search result, e.g. 'cloister-honey'."find_local_producers4 fields changedInput schema / properties / limit / descriptionPrevious value: -"Max results (1-100, default 25)."New value: +"Maximum number of producers to return, ordered nearest first."Input schema / properties / near / descriptionPrevious value: -"A location: a point as \"lat,lon\" (e.g. \"35.2271,-80.8431\"), a ZIP/postal code, or a global place name (\"Charlotte\", \"Charlotte, NC\", \"Auckland, NZ\"). Ambiguous bare cities resolve to the most populous match and are flagged (resolved_confidence: low)."New value: +"The place to search around — a city, town, ZIP code, or region. Examples: 'Charlotte, NC', '28202', 'Asheville', 'the Florida Keys'. If the user says 'near me' without naming a place, ask them for their city or ZIP first rather than guessing."Input schema / properties / radius_km / descriptionPrevious value: -"Search radius in km (default 80)."New value: +"Search radius in kilometers. Defaults to a standard local radius. Within the Southeastern US, the tool automatically widens to ~120 km (75 miles) if nothing is found closer."Input schema / properties / variety / descriptionPrevious value: -"Optional honey variety token, e.g. \"sourwood\", \"tupelo\", \"wildflower\"."New value: +"A honey varietal to filter by, e.g. 'sourwood', 'tupelo', 'wildflower', 'orange blossom'. Omit to return all local producers regardless of type. Do not pass a place name here."get_producer1 field changedInput schema / properties / slug / descriptionPrevious value: -"Producer slug, e.g. \"cloister-honey\"."New value: +"The exact producer slug, as returned in the slug/id field of a find_local_producers or search result, e.g. 'cloister-honey', 'asheville-bee-charmer'."search1 field changedInput schema / properties / query / descriptionPrevious value: -"Free-text search: place and/or honey varietal."New value: +"A free-text local-honey query, e.g. 'sourwood honey near Asheville NC' or 'local honey producers in Charlotte'. The tool extracts the place and any varietal automatically; a varietal alone (e.g. 'tupelo honey') is treated as a type, not a place."fetchsearchfind_local_producersget_producerClaims-based knowledge base for no/low ABV specialty beverages (producers, beverages, people).
Open, verified shop database for AI agents: products, offers, price comparison, trust and coupons.
Owner-verified local business data for AI agents: profiles, hours, prices, with provenance.
AI-native restaurant discovery: verified/menu-indexed/discovered tiers + signed allergy-safety data.
Add one secure layer between your agents and this server.