Skip to main content
Glama

Request a vendor check

vendor_check_request

Send your whole vendor list for a Florida license, workers' compensation and stop-work order check. Results start in seconds. We run the whole list once at no cost and email the full table when the check finishes. After the first results the list can be kept on Record watch, a paid option offered privately with the results: when the state posts new records we read it again (licenses every day) and email only about vendors that changed, with the read date and the state link.

Input Schema

NameRequiredDescriptionDefault
textNoOne vendor name per line; use instead of vendors.
emailYes
companyNo
vendorsNoEach vendor is {name, license_number?, city?} or just its name as a string; use instead of text.
ref_codeNo
contact_timeNoLeave empty.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • addedInput schema / properties / vendors / description
      Added value: +"Each vendor is {name, license_number?, city?} or just its name as a string; use instead of text."
    • removedInput schema / properties / vendors / items / additionalProperties
      Removed value: -false
    • addedInput schema / properties / vendors / items / anyOf
      Added value: +[
      +  {
      +    "maxLength": 300,
      +    "minLength": 1,
      +    "type": "string"
      +  },
      +  {
      +    "additionalProperties": false,
      +    "properties": {
      +      "city": {
      +        "maxLength": 120,
      +        "type": "string"
      +      },
      +      "license_number": {
      +        "maxLength": 100,
      +        "type": "string"
      +      },
      +      "name": {
      +        "maxLength": 300,
      +        "minLength": 1,
      +        "type": "string"
      +      }
      +    },
      +    "required": [
      +      "name"
      +    ],
      +    "type": "object"
      +  }
      +]
    • removedInput schema / properties / vendors / items / properties
      Removed value: -{
      -  "city": {
      -    "maxLength": 120,
      -    "type": "string"
      -  },
      -  "license_number": {
      -    "maxLength": 100,
      -    "type": "string"
      -  },
      -  "name": {
      -    "maxLength": 300,
      -    "minLength": 1,
      -    "type": "string"
      -  }
      -}
    • removedInput schema / properties / vendors / items / required
      Removed value: -[
      -  "name"
      -]
    • removedInput schema / properties / vendors / items / type
      Removed value: -"object"
  2. Changed1 schema field changed
    • removedInput schema / properties / vendors / maxItems
      Removed value: -500
  3. Added

TDQS

A3.5/5.0
Behavior4/5

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

Annotations declare readOnly=false, idempotent=false, openWorld=true, so the agent already knows this is a non-idempotent write against an external system. The description adds genuinely useful behavior beyond that: results are asynchronous and delivered by email, the first full-list run is free, and a paid 'Record watch' re-check runs on a stated cadence (licenses daily) with change-only notifications. It does not disclose whether repeated calls create duplicate requests or how to retrieve results in-band.

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

Conciseness3/5

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

Front-loaded correctly with what the tool does and the free first run. However, roughly a third of the text is promotional detail about the paid Record watch upsell with cadence specifics that a caller does not need in order to invoke the tool, and sentences are long and clause-heavy.

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

Completeness3/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 must explain what a caller gets back — it does say results arrive by email as a full table, which is the key fact for an async tool. The critical missing piece is how to follow up: vendor_check_status exists as a sibling but is never referenced, leaving the agent to guess the polling path.

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 50%; the two highest-value parameters (text and vendors) already carry inline descriptions including the mutually exclusive usage rule. The description reinforces the list-based input but says nothing about company, ref_code, or the required email beyond implying email is the delivery channel. Baseline 3 for partial coverage.

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?

States a specific verb and resource: submit a whole vendor list for a Florida license, workers' comp and stop-work order check. The scope (Florida, three record types, whole-list batch) is clear. It stops short of naming vendor_check_status as the companion tool, so the request/status pairing must be inferred from the sibling list.

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?

"Send your whole vendor list" implies the trigger condition, and the description establishes that the first run is free and batch-oriented. But there is no explicit guidance on when not to use it, no mention of polling results via vendor_check_status, and no statement of prerequisites or limits (list size, turnaround expectations beyond "seconds").

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources