venumark
Server Details
Booking decisions, scorecards, and self-checks for Florida food vendors over live DBPR data.
- 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.1/5 across 12 of 12 tools scored.
Each tool has a clearly distinct purpose: vendor search, scorecard retrieval, checking improvement, event listing, checklist retrieval, platform info, signup link, and vendor decision. Aliases (fetch/search) are explicitly described as shortcuts, not overlapping tools.
Most tools follow a consistent verb_noun pattern (e.g., get_scorecard, list_open_events). The aliases 'fetch' and 'search' break this pattern but are clearly documented as alternatives for specific connectors, not primary tool names.
12 tools is well-scoped for the server's purpose: covering vendor search, scorecard, decision, events, checklists, and platform setup. Each tool serves a necessary function without bloat.
The tool set covers core workflows: vendor discovery, compliance checking, checklist guidance, and event information. Minor gaps exist (e.g., no tool for submitting vendor applications, but that is handled via web app links).
Available Tools
12 toolsdecide_vendorAInspect
One-call booking decision for a Florida food vendor: CLEAR, CONDITIONAL, REVIEW, or DECLINE with reason codes, the evidence behind it, the documents to collect for the event type, and a signed receipt the organizer can keep in their compliance file. This is the recommended vetting tool; use search_vendors first only when you do not have a license number.
| Name | Required | Description | Default |
|---|---|---|---|
| vendor_id | No | Vendor id (UUID) from search_vendors | |
| event_type | No | Event type the document list is tailored to (default food-truck-night) | |
| license_number | No | Florida DBPR license number, with or without the letter prefix |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains the output (decision, evidence, documents, receipt) but does not disclose any behavioral traits like idempotency, side effects, or authentication needs.
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 efficiently convey the tool's function and usage. No redundant 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?
The description adequately explains return values despite lack of output schema, listing decision types and included components. However, it omits specifics like receipt format or evidence structure.
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% and descriptions are provided for all three parameters. The description adds context like 'from search_vendors' and 'Florida DBPR' but doesn't go beyond schema details. Baseline 3 is appropriate.
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 makes a booking decision with specific outcomes (CLEAR, CONDITIONAL, REVIEW, DECLINE) and includes reason codes, evidence, documents, and a receipt. It also distinguishes itself from search_vendors, making the purpose distinct.
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 recommends this as the vetting tool and advises using search_vendors only when lacking a license number. It could mention other sibling tools but the guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fetchAInspect
Alias of get_scorecard for ChatGPT Deep Research connectors. Takes a vendor id from search and returns the full public scorecard as a document (id, title, text, url, metadata).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Vendor id (UUID) from search |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It describes the tool as an alias for fetching a scorecard and lists return fields, but it does not disclose that the operation is read-only, any authentication requirements, or potential side effects. Given no annotations, this is insufficient.
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 a single, well-structured sentence that front-loads the core purpose (alias of get_scorecard) and includes essential details about input and output. Every phrase earns its place with no redundancy or filler.
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 tool's simplicity (one required parameter, no output schema), the description adequately covers the input and output structure. It identifies the tool as an alias and specifies the return fields. However, it lacks information about error conditions, rate limits, or the exact format of the 'document', though these may be inferred. Overall, it is sufficient for a straightforward fetch operation.
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% for the single parameter 'id', which already describes it as a vendor ID (UUID). The description redundantly states 'Takes a vendor id from search', adding no new meaning beyond what the schema provides. Baseline score of 3 is appropriate.
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 is an alias of get_scorecard for ChatGPT Deep Research connectors, specifies the input (vendor id from search), and explicitly lists the output fields (id, title, text, url, metadata). This distinguishes it from sibling tools like get_scorecard by clarifying its specific use case.
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 implies that the vendor id should come from a search, but it does not provide explicit guidance on when to use this tool versus its alias get_scorecard, nor does it mention any alternatives or exclusions. The context is clear but lacks direct instruction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_checklistAInspect
A Florida organizer checklist as markdown. Slugs: florida-food-truck-night (breweries, HOAs, churches), festival-food-vendors (festivals, farmers markets), city-special-event-food-vendors (public property).
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It states the output format (markdown) and lists the available checklists, which is helpful. However, it does not disclose side effects, authentication needs, or whether the tool is read-only. As a 'get' tool, it is likely safe, but this is not explicitly stated.
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 two sentences, front-loading the purpose and then providing the slug details. Every word earns its place; no redundant or trivial content.
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 simple tool with one parameter and no output schema, the description covers the key aspects: what it returns, what parameters are available, and their meanings. It could mention that the checklist is specifically for Florida organizers, but that is already implied. Slightly missing is the format/structure of the markdown content.
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 0%, but the description fully compensates by explaining each enum value in context (e.g., 'florida-food-truck-night (breweries, HOAs, churches)'). This adds meaning beyond the raw enum list, helping the agent select the correct slug.
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 'A Florida organizer checklist as markdown', clearly indicating the tool returns a checklist for event organizers in Florida. It lists three specific slugs with their contexts, distinguishing it from other 'get_' tools. However, it could be more explicit about the exact nature of the checklist (e.g., requirements, steps).
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?
Usage is implied: this tool is for obtaining an organizer checklist for Florida events. The description lists the available slugs and their contexts (e.g., breweries, festivals), giving some guidance on when to use it. However, there is no explicit comparison to sibling tools or conditions for when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_eventAInspect
One published event's public details: dates, venue, city, application deadline, required documents, and the apply link. Use the slug from list_open_events or from a venumark.com/event/ URL.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Event slug from list_open_events or the event URL |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description implies read-only behavior by referring to 'public details' of a published event. No contradictory or missing behavioral info; it appropriately conveys the tool's scope.
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 with no wasted words. The purpose is stated clearly upfront, and the usage guidance follows naturally.
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 simple read-only tool with one parameter, the description covers the output details and input source completely. No output schema exists, but the description lists return fields sufficiently.
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 for the single parameter is 100%, and the description adds value by explaining where to get the slug, making it more actionable than the schema alone.
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 explicitly states what the tool does: retrieving public details of a published event including dates, venue, city, deadline, documents, and apply link. It also distinguishes itself from the sibling tool list_open_events by focusing on a single event's details.
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 provides clear guidance on where to obtain the required slug parameter (from list_open_events or event URL). While it doesn't explicitly state when not to use the tool, the context is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_platform_infoAInspect
What VenuMark is (the food vendor application and compliance platform for Florida events), how the workflow runs, current pricing tiers, and which tier fits an organizer. Use when someone asks about running vendor applications, pricing, or whether VenuMark fits their event.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes the tool as providing informational overview with no side effects. Implicitly read-only, but could be more explicit about non-destructive nature.
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 core purpose, no wasted words. Perfectly concise.
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?
Tool has no parameters or output schema, low complexity. Description fully covers purpose and usage context, including what information is provided.
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?
No parameters in schema, so baseline 4. Description adds no parameter info, but none needed.
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 clearly states the tool provides information about VenuMark's identity, workflow, pricing tiers, and tier fit. It uses specific verbs and distinguishes from sibling tools like get_event and get_checklist.
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 tells when to use: 'Use when someone asks about running vendor applications, pricing, or whether VenuMark fits their event.' No ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_scorecardAInspect
One vendor's public compliance record: letter grade (or withheld when the current DBPR license cannot be confirmed), license status, inspection recency, and record shape. Look up by vendor_id from search_vendors, or directly by license_number (MFD3953067 or 3953067) to vet a vendor in one call. Grades: A to F, plus HOLD (active DBPR license hold), Ungraded (insufficient record), and Withheld (license unconfirmed).
| Name | Required | Description | Default |
|---|---|---|---|
| vendor_id | No | Vendor id (UUID) from search_vendors | |
| license_number | No | Florida DBPR license number, with or without the letter prefix |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses that the tool reads public compliance records and explains grade values (including HOLD, Ungraded, Withheld). However, it does not mention caching, staleness, rate limits, or any destructive behavior, which is acceptable for a read-only tool but could be more comprehensive.
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 a single, dense paragraph that front-loads the core purpose ('One vendor's public compliance record') and every sentence adds value. No extraneous information, achieving high informational density without waste.
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 no output schema and no annotations, the description covers key output fields (grade, license status, inspection recency, record shape) and explains the grading scale. It is complete enough for a straightforward read operation, though it could mention the response format or any pagination limits.
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 descriptive parameter fields. The description adds context by specifying that vendor_id comes from search_vendors and providing license_number format examples (MFD3953067 or 3953067), enhancing clarity beyond the schema alone.
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 identifies the tool as retrieving a vendor's public compliance record, listing specific fields (letter grade, license status, inspection recency, record shape). It distinguishes from sibling tools like search_vendors, which returns vendor IDs, making the purpose unambiguous.
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 provides clear lookup instructions (by vendor_id from search_vendors or directly by license_number) and explains grade meanings. However, it does not explicitly state when not to use this tool or compare it to alternatives like decide_vendor, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_signup_linkAInspect
A direct VenuMark signup link for the human to open in their browser. role 'venue' is for organizers who run vendor applications; optional tier ('growth' or 'pro') and cadence ('month' or 'year') preselect the plan, and checkout completes in the browser via Stripe. role 'vendor' is for food trucks and caterers (free forever). Event creation and applications happen in the web app after signup.
| Name | Required | Description | Default |
|---|---|---|---|
| role | Yes | Who is signing up | |
| tier | No | Optional paid tier to preselect (venues only; omit for Free) | |
| cadence | No | Optional billing cadence for the preselected tier |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It explains that the tool returns a link for the human to open, checkout happens via Stripe, and event creation occurs later. It does not mention any side effects or restrictions, but for a simple link retrieval, the behavior is sufficiently transparent.
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 the purpose stated upfront in the first sentence followed by two sentences detailing roles and optional parameters. No unnecessary words, and the structure is effective.
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?
The tool has no output schema, so the description should detail the return value. It mentions 'a direct VenuMark signup link' but does not specify the format (e.g., URL string). It covers the signup flow but lacks explicit output semantics, leaving some ambiguity.
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 brief descriptions. The description adds value by explaining that 'venue' is for organizers, 'vendor' for food trucks, and that 'tier' and 'cadence' are optional and only for venue. It provides examples and clarifies preselect functionality.
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 provides a signup link, explains the two roles ('venue' and 'vendor'), and distinguishes their purposes. It uses specific verbs ('get') and resource ('signup link'), and adds detail about what each role does.
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 explains when to use with each role and mentions optional parameters for venue. However, it does not explicitly state when not to use this tool or provide alternatives like other sibling tools, but the context is clear given no sibling serves a signup purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
improve_my_scoreAInspect
For a Florida food truck or caterer checking their own record: what is currently limiting the VMScore letter grade, what to do about each item, official Florida DBPR resources, and a link to claim the free VenuMark vendor profile. Look up by license_number (MFD3953067 and 3953067 both work) or vendor_id from search_vendors. Organizers vetting a vendor for booking should use decide_vendor instead. Grades: A to F, plus HOLD (active DBPR license hold), Ungraded (insufficient record), and Withheld (license unconfirmed).
| Name | Required | Description | Default |
|---|---|---|---|
| vendor_id | No | Vendor id (UUID) from search_vendors | |
| license_number | No | Florida DBPR license number, with or without the letter prefix |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description discloses the tool's behavior: it retrieves limiting factors, action items, DBPR resources, and a link to claim a profile. It does not mention side effects, but the context suggests a read-only lookup, which is adequately clear.
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 front-loaded with the primary purpose and is fairly concise. It includes useful details but could be slightly trimmed by moving grade explanations to output context. Still well-structured and efficient.
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 no output schema, the description comprehensively covers return values: limiting factor, action items, DBPR resources, and profile link. It also explains grade meanings and provides alternative tool for organizers, making it complete for a lookup tool with two optional parameters.
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 parameter descriptions. The description adds value by providing example formats for license_number (MFD3953067 or 3953067) and clarifying that vendor_id comes from search_vendors, which aids correct parameter usage.
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 is for Florida food truck/caterer checking their own VMScore, and distinguishes it from the sibling 'decide_vendor' tool. It specifies the verb 'improve' and the resource 'my score', with a clear target audience.
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 (vendor checking own record) and when not to (organizers should use decide_vendor). Provides lookup method via license_number or vendor_id, including example formats.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_open_eventsAInspect
Florida events currently published on VenuMark and taking food vendor applications. Optional city filter. Each result includes the application deadline, required documents, and the public apply_url where a vendor applies (free account).
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | Optional Florida city filter, e.g. TAMPA |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the list scope and result fields, but omits read-only indication, auth requirements, or behavior edge cases (no results, pagination). Acceptable but not fully transparent.
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 (two sentences) and packs key information without fluff. Slightly more structured formatting could improve scannability.
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 simple list tool with one optional parameter and no output schema, the description covers the essential context: source, scope, what results contain. Missing guidance on result format but sufficient.
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 clear description for the city parameter. The description adds the 'Florida' context but does not significantly enhance parameter meaning 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 lists Florida events from VenuMark that are currently accepting food vendor applications, with optional city filter. This distinguishes it from siblings like get_event (single event) and search (generic).
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 implies use when needing open vendor events, but does not provide explicit when-to-use or when-not-to-use guidance, nor compare to alternatives like search_vendors or get_event.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
searchAInspect
Alias of search_vendors for ChatGPT Deep Research connectors. Returns matching Florida food vendors as results with id, title, and url. Pass the id to fetch for the full record.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Business name, license number, or Florida city |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral aspects. It states the tool returns results with id, title, and url, implying a read operation. However, it does not explicitly confirm it is read-only, mention authentication needs, rate limits, or any side effects. The alias hint adds some context but leaves gaps.
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 two sentences long, each sentence serving a distinct purpose: first explains the alias and context, second describes the output and next steps. No excess words, and it is front-loaded with the primary purpose.
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 no output schema, the description covers the return format (id, title, url) and the follow-up action (use fetch for full record). It provides sufficient context for basic usage. However, it lacks details on pagination, error handling, or what constitutes a 'match', but for a simple alias tool this is adequate.
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% for the single parameter 'query', which describes acceptable inputs. The description adds context about what the results contain but does not enhance the parameter meaning beyond the schema. Baseline score of 3 is appropriate.
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 clearly states it is an alias of search_vendors for ChatGPT Deep Research connectors and returns matching Florida food vendors. The verb 'search' and resource 'vendors' are explicit. However, it does not distinguish itself from the sibling 'search_vendors' beyond being an alias, and the title is null.
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 mentions it is for ChatGPT Deep Research connectors, providing a usage context, and advises passing the id to fetch for the full record. However, it does not explicitly state when to use this tool versus alternatives like 'search_vendors' or 'fetch', nor does it mention any prerequisites or scenarios to avoid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_vendorsAInspect
Search all licensed Florida food trucks and caterers (19,000+, scored from official DBPR inspection records). Matches business name, prior names, license number (MFD3953067 and 3953067 both work), and city. Optional county, grade, and limit filters. Grades: A to F, plus HOLD (active DBPR license hold), Ungraded (insufficient record), and Withheld (license unconfirmed). Returns matches with license status, letter grade, and a scorecard link.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | Optional Florida city filter, e.g. TAMPA | |
| grade | No | Optional: only vendors currently holding this grade | |
| limit | No | Max results, 1 to 25 (default 10) | |
| query | No | Business name or license number (partial ok). Optional when city is given. | |
| county | No | Optional Florida county filter, e.g. Hillsborough |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description adds context about data source (DBPR records) and return fields (status, grade, scorecard link), but does not disclose safety profile, authentication needs, or rate limits.
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 purpose, every sentence adds necessary detail 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?
No output schema, but description sufficiently explains return values (status, grade, scorecard link) and all parameters, making the tool self-contained for an agent.
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?
Adds value beyond 100% schema coverage by explaining license number format matching and elaborating on grade enum values (HOLD, Ungraded, Withheld).
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?
Clearly states 'Search all licensed Florida food trucks and caterers' with specific detail on searchable fields (name, license number, city) and distinguishes from sibling tools like get_scorecard.
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?
Describes optional filters (county, grade, limit) and matching behavior, but does not explicitly contrast with alternative tools or state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
submit_leadAInspect
Send an organizer's contact request to the VenuMark founder (setup help, demo, festival or city program, Enterprise scope). Only call after the user has explicitly confirmed the exact details to send. The founder replies by email, usually the same day.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | Florida city or region (optional) | |
| name | Yes | The person's name | |
| Yes | Where the founder should reply | ||
| message | No | What they need help with (optional) | |
| event_type | No | e.g. brewery food truck night, festival, farmers market, city event | |
| organization | No | Business, venue, or city (optional) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description mentions action and email reply but doesn't disclose potential side effects, reversibility, or auth needs. Adequate but not detailed.
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 purpose, then usage condition. No unnecessary words, efficient and clear.
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 purpose, usage condition, and outcome (founder replies). Missing output schema but description provides enough context for an agent. Could mention return value.
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 descriptions. Description adds context for usage (confirmation) but doesn't provide additional parameter constraints or formats. Baseline 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?
Clearly states it sends an organizer's contact request to the VenuMark founder, specifying scope (setup help, demo, etc.). Distinct from sibling tools like search or get_event.
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 'Only call after the user has explicitly confirmed the exact details' and provides follow-up info. Lacks alternatives but sufficient given context.
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!