Skip to main content
Glama

ShearQuery — Barber & Beauty Industry Data

by com.innergcomplete
OverviewDiscussionsAdmin

Count Texas barber & cosmetology licensees

texas_licensee_counts
Read-only

Count active Texas licensees from the TDLR public record by license type, optionally limited to those whose license expires before a given date. Answers how many people a rule change, CE requirement or fee change actually affects — the number is not published anywhere in this form.

Input Schema

NameRequiredDescriptionDefault
license_typeNoOptional exact TDLR license type, e.g. "Class A Barber", "Cosmetology Operator", "Cosmetology Manicurist", "Cosmetology Esthetician". Omit for a breakdown across all types.
expiring_beforeNoOptional ISO date (YYYY-MM-DD). Counts only licenses expiring before it — use to size who is affected by a change taking effect on that date.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / expiring_before / description
      Previous value: -"Optional ISO date (YYYY-MM-DD). Counts only licences expiring before it — use to size who is affected by a change taking effect on that date."New value: +"Optional ISO date (YYYY-MM-DD). Counts only licenses expiring before it — use to size who is affected by a change taking effect on that date."
    • changedInput schema / properties / license_type / description
      Previous value: -"Optional exact TDLR licence type, e.g. \"Class A Barber\", \"Cosmetology Operator\", \"Cosmetology Manicurist\", \"Cosmetology Esthetician\". Omit for a breakdown across all types."New value: +"Optional exact TDLR license type, e.g. \"Class A Barber\", \"Cosmetology Operator\", \"Cosmetology Manicurist\", \"Cosmetology Esthetician\". Omit for a breakdown across all types."
  2. First observed

TDQS

A4/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false), so the description gains credit mainly for provenance and nature: results come from the TDLR public record and are an aggregate not published elsewhere — i.e. derived, not a stored field. It still omits return shape, freshness/lag of the public record, and any counting caveats.

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, both earning their place: the first states mechanism and scope, the second states the use case and the reason to trust this tool over manual lookup. Front-loaded with the core action and no filler.

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

Completeness4/5

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

With only two optional params, no nested objects, and no output schema, the agent has enough to invoke it correctly, and the description supplies the missing 'why/when'. What it does not supply is the shape of the result (single count vs. per-type breakdown) or how current the TDLR record is.

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 fully documented with examples and the 'omit for a breakdown' behavior. The description restates the same two filters ('by license type, optionally limited to... expires before') without adding syntax or edge-case meaning, so baseline 3 applies.

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?

Specific verb+resource (count active Texas licensees) plus the authoritative source (TDLR public record) and the aggregation dimension (by license type). It reads clearly as an aggregate-count tool, implicitly distinct from the per-license sibling verify_texas_license, though it never names that sibling to remove any doubt.

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?

Strong contextual guidance: 'Answers how many people a rule change, CE requirement or fee change actually affects' tells the agent exactly when this tool is the right one. There is no explicit when-not or named alternative (e.g. verify_texas_license for a single license), so it stops short of the top score.

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

All ShearQuery — Barber & Beauty Industry Data toolsInspect
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