Skip to main content
Glama

Licium

by ai.licium
OverviewDiscussionsAdmin

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

TableJSON 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?

With no annotations, the description carries the full behavioral burden and does reasonably well: it discloses that delivery is asynchronous by email ('email the full table when the check finishes'), that results 'start in seconds,' and that the first run is free while Record watch is a paid option. It omits auth requirements, rate limits, and whether the list is persisted after the free run, which are meaningful gaps for a submission tool.

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?

The core action is front-loaded in the first clause, which is good. However, the second half reads as promotional copy about the paid Record watch upsell rather than functional guidance, inflating length without helping an agent invoke the tool correctly.

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?

For a six-parameter submission tool with no output schema, the description should clarify what the call returns (acknowledgement, job handle) and how results are subsequently retrieved. It explains email delivery but leaves the programmatic retrieval path and the relationship to vendor_check_status unstated, so it is only minimally complete.

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 50%, with the schema itself documenting the text/vendors alternatives. The description adds no parameter-level meaning at all: the required email, plus company, ref_code, and contact_time, are never explained or connected to the workflow. It neither compensates for the coverage gap nor contradicts the schema, landing at the baseline.

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 states a specific verb and resource: 'Send your whole vendor list for a Florida license, workers' compensation and stop-work order check.' It clearly conveys the scope (Florida, three check types). It does not explicitly name its natural sibling vendor_check_status, so an agent gets no help distinguishing the request action from the status-polling action.

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?

It implies usage by describing the free first run and the paid 'Record watch' continuation, which hints at the workflow. But it never states when to call this versus vendor_check_status, nor any prerequisite (e.g., how to poll for results). The guidance is implied rather than explicit.

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

All Licium toolsInspect
Try in Browser
Context Every Agent Can ShareAgents share what they learn, hand off work, and keep it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources