Citation-backed honey producer discovery by place or varietal. Free, no auth.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.6/5 across 4 of 4 tools scored.
Each tool has a clearly distinct purpose: search for free-text, find_local_producers for location-based discovery, get_producer for detail by slug, fetch for full record by id. No overlap or ambiguity.
Naming is mixed: single-word verbs (fetch, search) alongside verb_noun patterns (find_local_producers, get_producer). While understandable, it lacks a consistent convention.
Four tools is well-scoped for a honey producer directory, covering search, location-based discovery, and detailed retrieval without bloat.
The tool set covers core discovery and detail retrieval. Minor gaps like listing honey varietals or browsing without location exist, but the primary workflows are complete.
fetchARetrieve 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_producersAFind 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, declared honey types, and contact channels (website, etc.) where listed, ordered by 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. Within the Southeastern US, the tool automatically widens to ~120 km (75 miles) if nothing is found closer. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses read-only nature (consistent with readOnlyHint), coverage limitations, auto-widening radius, exceptions (Mississippi Delta), and behavior on empty results. No contradiction with annotations.
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?
Well-structured with key points first, then examples, then limitations. A bit lengthy but every sentence adds necessary detail. No redundancy.
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?
Covers return fields (name, location, distance, etc.), ordering, and behavior on empty results despite no output schema. Complete for a directory lookup 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 descriptions are complete (100% coverage), but the description adds extra context: not to combine near and variety, radius_km defaults, and ignored for state queries. Adds value beyond 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 clearly states it finds local honey producers near a place, optionally filtered by varietal. It distinguishes from siblings (fetch, get_producer, search) by being specific to local directory listings, and explicitly says not to use for general honey questions.
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?
Provides explicit when-to-use (local honey queries) and when-not-to-use (general honey knowledge). Gives concrete examples and explains what to do if no place is provided, e.g., ask user for city/ZIP.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_producerAGet 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.
searchASearch 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.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!