Skip to main content
Glama
Sign In

RegPulse Compliance Oracle

by ai.reg-bot
OverviewDiscussionsAdmin

Server Details

Read-only US food license data: verified state rules, Florida license lookup, renewal dates.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Uptime
100.0% over 21 days
Last Tested
Transport
Streamable HTTP · MCP 2025-06-18
URL
ChatGPT
–
Claude
–

TDQS

A3.8/5.0

Scored across 3 tools

Disambiguation3/5

The three tools are somewhat distinct (generic state rules vs. Florida record lookup vs. computed deadline), but next_renewal_date overlaps heavily with both: renewal info comes from get_state_food_rules and expiry comes from lookup_florida_license, so an agent asking 'when does my license expire?' has three plausible entry points. The detailed descriptions help disambiguate, but a derived-tool sitting on top of two source tools creates real boundary confusion.

Naming Consistency3/5

get_state_food_rules and lookup_florida_license use verb_noun, but next_renewal_date is a bare noun phrase with no verb, so the pattern breaks on the third tool. Readable overall, but not a predictable convention an agent can rely on.

Tool Count4/5

Three tools is on the thin side, but each covers a genuinely different query shape (rules reference, single-record lookup, deadline computation) for a narrow compliance domain. No filler tools and no bloat; slightly under-scoped for a server branded as a multi-state 'Oracle'.

Completeness2/5

The server presents as US-state food compliance but only Florida has an actual license-status lookup; every other state falls back to 'check with your local health department,' which is a dead end for the most common agent request (verify this license). There is also no coverage of fee specifics, forms, or renewal actions, and next_renewal_date explicitly returns null for whole classes of cases (anniversary permits, Ohio food trucks).

Available Tools

3 tools
get_state_food_rulesVerified state food license rulesA
Read-only
Inspect

Get verified food license rules (issuing agency, renewal cycle, expiry, fee, late fee, official link) for a US state and business type. Only rows verified against the full official page are returned; anything else returns 'Check with your local health department' and an official link. Never guesses.

NameRequiredDescriptionDefault
stateYes2-letter US state code, e.g. FL, TX, DC
business_typeNoOptional, e.g. food truck, restaurant, caterer, cottage food

TDQS

A3.9/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover safety (readOnlyHint=true, openWorldHint=false), and the description adds genuinely new behavioral context: only rows verified against the full official page are returned, unverified cases fall back to a 'Check with your local health department' message plus an official link, and it 'never guesses'. That reliability contract is exactly what an agent needs to trust the output; only auth/rate-limit detail is absent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no filler. The primary purpose and returned fields are front-loaded, with the verification/fallback caveat immediately after.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description must carry the return shape, and it does by listing every returned field plus the fallback response. For a read-only, two-parameter tool this is sufficient for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both parameters are already documented (state format, optional business_type examples), which sets the baseline at 3. The description only restates 'a US state and business type' without adding format, defaulting, or matching semantics beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb and resource (get verified food license rules) and enumerates the exact fields returned (issuing agency, renewal cycle, expiry, fee, late fee, official link). It implicitly separates itself from the Florida-only sibling by scoping to 'a US state and business type', but never names the alternatives, so differentiation is left partly to inference.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied: call this to get food license rules for a given state/business type. The description explains the data-quality behavior but never states when to prefer it over lookup_florida_license or next_renewal_date, and gives no prerequisites or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

lookup_florida_licenseLook up a Florida food licenseA
Read-only
Inspect

Look up a Florida DBPR food service / mobile food license (restaurants, food trucks, caterers) by license number, or by business name plus 5-digit zip. Returns status and expiry date from Florida DBPR public records (checked daily; DBPR updates about once a week, so it may lag). Read-only.

NameRequiredDescriptionDefault
zipNo5-digit Florida zip code (use with business_name)
business_nameNoBusiness name (use with zip)
license_numberNoDBPR license number, e.g. MFD2650526

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful context beyond that: the data source is Florida DBPR public records, it is checked daily but DBPR updates only weekly so results may lag, and the return includes status and expiry. The staleness caveat is a valuable behavioral trait an agent would not otherwise know.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences: identity/scope first, query modes second, return and freshness third. No filler, and every sentence carries information an agent needs.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the burden of describing returns and does so ('status and expiry date'). Combined with coverage of entity scope, query modes, and data freshness, it gives everything needed to call the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents each parameter, including the pairing hints ('use with business_name', 'use with zip'). The description restates the license-number vs. name+zip modes but adds no syntax or format detail beyond what the schema provides, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (look up) and a precise resource (Florida DBPR food service / mobile food license), enumerating covered entity types (restaurants, food trucks, caterers). It is clearly distinguishable from siblings like get_state_food_rules and next_renewal_date, which address rules and renewal dates rather than license lookup.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains the two valid query modes (by license number, or by business name plus 5-digit zip), which tells the agent how to invoke it in each case. It does not explicitly name when to prefer this over a sibling or state exclusions, so it stops short of full when/when-not guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

next_renewal_dateNext food license renewal dateA
Read-only
Inspect

Get the next food license renewal deadline. Give a Florida DBPR license_number for its real expiry date, or a state (plus optional city and business_type) for states/cities with a verified fixed yearly deadline (e.g. Michigan Apr 30). Returns null with guidance when there is no verified fixed date (e.g. anniversary-based permits, or Ohio food trucks, which renew before first operating in the new licensing year).

NameRequiredDescriptionDefault
cityNoOptional city, e.g. Dallas
stateNo2-letter US state code
countyNoOptional county, e.g. Franklin County
business_typeNoOptional, e.g. home bakery
license_numberNoOptional Florida DBPR license number

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds real behavioral value beyond that by disclosing the null-return behavior with guidance and enumerating cases where no verified date exists (anniversary-based permits, Ohio food trucks). It does not discuss caching or data freshness, keeping it short of a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, zero waste, and the core purpose plus the two input modes are front-loaded before the null-behavior caveat. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the return-value burden and does so: it specifies the returned deadline, the null-with-guidance failure case, and example exceptions. Combined with full schema coverage and covering annotations, an agent has everything needed to call this correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema by constraining license_number to Florida DBPR and explaining how state/city/business_type combine for fixed-deadline lookups. The county parameter is never mentioned, which is the one gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb and resource ('Get the next food license renewal deadline') and then cleanly splits the two modes of operation: Florida DBPR license lookup for a real expiry date, versus state/city/business_type for a verified fixed yearly deadline. This is easy to distinguish from lookup_florida_license and get_state_food_rules.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It clearly states which parameter combination to use for which outcome ('Give a Florida DBPR license_number for its real expiry date, or a state... for states/cities with a verified fixed yearly deadline'), which functions as when-to-use guidance. It stops short of naming the sibling tools as explicit alternatives, so it is clear but not fully routing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool update
    • Changednext_renewal_date1 field changed
      • addedInput schema / properties / county
        Added value: +{
+  "description": "Optional county, e.g. Franklin County",
+  "type": "string"
+}
  2. 3 tool updates
    • First observedget_state_food_rules
    • First observedlookup_florida_license
    • First observednext_renewal_date

Related MCP Connectors

Related MCP Servers

  • contractor-license-mcp-server

    Noquarter6
    A
    license
    A
    quality
    D
    maintenance
    Real-time contractor license verification across 45 US states. Verifies license status, expiration, and disciplinary history directly against state licensing board portals.
    4
    71 npm
    MIT

  • Agent to Brokerage Resolver

    mambalabsdev
    A
    license
    A
    quality
    B
    maintenance
    Enables lookup of licensed US real estate agents on official state license registers by license number or name, returning the brokerage of record along with its active agent count, size band, and the agent's license status and expiry. It also lists every active agent at a given brokerage or every brokerage office in a zip code across 19 states.
    1
    50 npm
    MIT
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources