Melvea Local Honey Discovery
Server Details
Find local honey producers near a place or by varietal. Name, location, honey types, and website.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
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.
Tool Definition Quality
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.
Available Tools
4 toolsfetchARead-onlyInspect
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'. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true; description adds no new behavioral traits beyond stating what fields are returned, which is adequate but does not exceed 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?
Two sentences: first delivers core purpose, second adds usage guidance. No wasted words, information is 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?
Given one required parameter and no output schema, description fully covers purpose, usage context, and a recommendation for broader research; no gaps.
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 description for 'id'; description adds no extra meaning beyond confirming it's from a search result, so 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?
Description specifies retrieving full Melvea record by id, listing returned fields (name, location, etc.), and distinguishes from search by saying 'use after search'.
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' and advises fetching multiple results for richer answers, providing clear when-to-use and when-to-consider alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_local_producersARead-onlyInspect
Find local honey producers near a specific place, optionally filtered by honey varietal. 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 region — e.g. 'local honey near Asheville,' 'who sells honey near me in Charlotte,' 'sourwood honey near Atlanta.' 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 | 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. | |
| limit | No | Maximum number of producers to return, ordered nearest first. | |
| variety | No | 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. | |
| radius_km | No | 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, and the description adds significant behavioral context: returns specific fields (name, location, distance, honey types, contact channels), ordering by distance, coverage depth in Southeastern US with exception (Mississippi Delta), and honesty about empty results. 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?
The description is relatively long but well-structured with front-loaded purpose and usage. Every sentence provides necessary context, though minor redundancy exists (e.g., 'ordered by distance' appears twice). Still, it remains clear and efficient for an AI agent.
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 4 parameters, no output schema, and moderate complexity, the description is remarkably complete. It explains return fields, ordering, coverage, empty result behavior, and usage boundaries. No key aspect is missing.
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%, so baseline is 3. Description adds value by providing examples for each parameter, clarifying that 'near' should not be guessed, 'variety' should not be a place name, and 'radius_km' has auto-widening behavior. This extra context justifies a score above baseline.
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 finds local honey producers near a place, optionally filtered by varietal. It distinguishes from siblings by explicitly stating not to use for general honey questions, and provides concrete examples like 'local honey near Asheville'.
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 comprehensive guidance on when to use (user asks to find/buy/visit local honey), when not to use (general honey questions), and how to handle 'near me' by prompting for city/ZIP. Also notes coverage limitations and handling of empty results.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_producerARead-onlyInspect
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'. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, so description need not repeat safety. Description adds behavioral context: requires exact slug and returns specific fields (location, honey types, etc.). 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 concise sentences: first defines purpose and output, second gives usage context. No wasted words, 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?
No output schema, but description lists included fields. Tool is simple detail retrieval, and description covers all needed context: input, output fields, and when to 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?
Only one parameter 'slug' with 100% schema description coverage. Schema already explains slug format and origin. Description adds no extra meaning beyond restating requirement.
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 states the verb 'Get' and resource 'full directory profile for one specific producer by its slug', listing specific fields. It distinguishes from sibling tools by noting it's for detailed view after find_local_producers or search.
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 this after find_local_producers (or search) when the user wants more detail' and 'Don't use this to browse or search', providing clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
searchARead-onlyInspect
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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true; description adds that it returns an honest empty list when nothing matches (never fabricates), which is a critical behavioral guarantee beyond the annotation.
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 (4 sentences) and front-loaded with the purpose, followed by usage guidance and behavioral notes. Every sentence adds essential information without 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?
Given the simple input schema and no output schema, the description covers all necessary aspects: purpose, usage, behavior, output format, and even suggests pairing with fetch for detail. Complete for a search 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 has 100% coverage with a clear description of the query parameter. The description adds value by explaining that the tool extracts place and varietal automatically, and provides examples of valid queries, enhancing understanding 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 clearly states the tool searches a specific directory (Melvea local honey) by free-text query and returns matching producers with fields like id, title, url. It distinguishes from siblings by specifying its use case (free-text query) and mentions it is designed for ChatGPT Deep Research and Company 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?
Provides explicit guidance: use for local-honey discovery queries that name or imply a place, and it parses place and varietal. Also implies pairing with fetch for full detail, differentiating from sibling tools.
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.
Discussions
No comments yet. Be the first to start the discussion!