PestPin

Check a pest control license

verify_license

Read-onlyIdempotent

Check whether a US pest control company holds a state license record. Searches PestPin's directory of official state regulator records (35 states, reprocessed from official sources on a recurring schedule; publication timing varies by regulator). Returns matched businesses with license number, state, status at PestPin's last check, the date that check happened, and the official state source link so the answer can be verified at the regulator. Use it when someone names a company and wants to know if it is licensed. A miss is not proof a company is unlicensed: coverage is 35 states, some businesses are excluded as lawn, agricultural or government records, and name spellings vary.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "company": "<company>"
    },
    "name": "verify_license"
  }
}

Input Schema

Name	Required	Description	Default
`state`	No	Optional two-letter US state code to narrow the search, e.g. FL
`company`	Yes	Business name (or license number) to search for, e.g. Acme Pest Control

Output Schema

Name	Required	Description
`note`	Yes	The limits a reader must be told
`matches`	Yes	Matched license records, empty when nothing matched
`totalMatches`	Yes	How many records matched in total

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedSep 8, 2026

addedInput schema / additionalProperties
```
Added value: +false
```

changedInput schema / properties / company / description

Previous value: -"Business name (or license number) to search for"New value: +"Business name (or license number) to search for, e.g. Acme Pest Control"

addedInput schema / properties / company / examples

Added value: +[
+  "Acme Pest Control",
+  "Terminix"
+]

addedInput schema / properties / state / examples
```
Added value: +[
+  "FL",
+  "TX"
+]
```

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "matches": {
+      "description": "Matched license records, empty when nothing matched",
+      "items": {
+        "properties": {
+          "inDirectorySince": {
+            "description": "ISO date the record first cleared PestPin's checks",
+            "type": "string"
+          },
+          "lastCheckedAt": {
+            "description": "Same as sourceCheckedOn when the record carries its own check date",
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "licenseNumber": {
+            "description": "License number on the state record",
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "licenseState": {
+            "description": "Two-letter state that issued the license",
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "name": {
+            "description": "Business name as the state record spells it",
+            "type": "string"
+          },
+          "officialSourceAgency": {
+            "description": "Name of the state agency that publishes the record",
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "pestpinProfile": {
+            "description": "PestPin page for this record",
+            "type": "string"
+          },
+          "sourceCheckedOn": {
+            "description": "ISO date PestPin last processed the source behind this record",
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "sourceCheckedOnScope": {
+            "description": "'record' when the date is this record's own last check, 'state' when it is the last time PestPin processed that state's source",
+            "enum": [
+              "record",
+              "state"
+            ],
+            "type": "string"
+          },
+          "status": {
+            "description": "What the record said at PestPin's last check",
+            "type": "string"
+          },
+          "verifyAtOfficialSource": {
+            "description": "Official state regulator page where this record can be checked",
+            "type": "string"
+          }
+        },
+        "required": [
+          "name",
+          "verifyAtOfficialSource",
+          "sourceCheckedOn",
+          "sourceCheckedOnScope",
+          "pestpinProfile"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "note": {
+      "description": "The limits a reader must be told",
+      "type": "string"
+    },
+    "totalMatches": {
+      "description": "How many records matched in total",
+      "type": "integer"
+    }
+  },
+  "required": [
+    "matches",
+    "totalMatches",
+    "note"
+  ],
+  "type": "object"
+}

First observedAug 17, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Richly discloses behaviors beyond the annotations: data is a reprocessed snapshot ('status at PestPin's last check' with the check date), coverage is limited to 35 states with regulator-dependent publication timing, and a miss is explicitly 'not proof a company is unlicensed' due to exclusions and spelling variance. This consistently supports openWorldHint and readOnlyHint with no contradiction.

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?

Five sentences, each earning its place: purpose, data provenance, return values, usage trigger, and false-negative caveat. The core purpose is front-loaded in sentence one, and the density is justified by the tool's complexity.

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?

Complete for a read-only lookup tool: parameters are fully schema-documented, return values are enumerated, data freshness is disclosed, and the verification link and coverage limitations are covered. An output schema exists to carry structured return details, and nothing needed to invoke or interpret results is missing.

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% and both parameters carry descriptions and examples in the schema itself. The description adds only marginal context (search is by company name, and the 35-state coverage hint informs the optional state filter), so it lands at the baseline 3 rather than higher.

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 and resource: 'Check whether a US pest control company holds a state license record,' then enumerates the exact return fields (license number, state, status, check date, source link). The scope (US pest control, 35 states) is unambiguous and clearly distinguishes it from siblings like verify_phone or find_licensed_pros.

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?

Gives an explicit trigger condition: 'Use it when someone names a company and wants to know if it is licensed.' It stops short of naming sibling alternatives or stating when another tool would be preferable, so it earns a 4 rather than a 5 on the when/when-not/alternatives scale.

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

All PestPin tools Inspect

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

Need Help?