Skip to main content
Glama

PestPin

by com.pestpin
OverviewDiscussionsAdmin

Server Details

US pest control license check by number, licensed-company search by city, and cost planning ranges.

If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Last Tested
Transport
Streamable HTTP
URL

TDQS

A4.1/5.0

Scored across 5 tools

Disambiguation4/5

Each tool targets a distinct action (find, verify, cost, request link), but find_licensed_pros and get_intro_request_link both serve homeowners seeking to contact a company, which could cause minor confusion about which to use when the user wants to initiate a request.

Naming Consistency5/5

All tool names use snake_case with a verb_noun structure (find_..., get_..., verify_...), providing a predictable and consistent pattern.

Tool Count5/5

Five tools is well-scoped for a pest control directory/verification service; each tool has a clear purpose without redundancy.

Completeness4/5

Core workflows for discovery, cost planning, license/phone verification, and request initiation are covered, but there is no explicit tool to verify solely by license number or retrieve a full company profile, which could be a minor gap.

Available Tools

5 tools
find_licensed_prosFind licensed pest control companiesA
Read-onlyIdempotent
Inspect

Find licensed pest control companies near a US city. Returns up to 8 businesses that hold a state license record covering that city and pest type, each with its license number, published phone number, the official state source link, and the date PestPin last processed that source. Also returns a link to the full list, where a homeowner can call any company for free or send one request that is offered to a single company at a time and never resold. Listings are matched public records, not recommendations or a ranking, and most businesses have not confirmed services or coverage with PestPin.

ParametersJSON Schema
NameRequiredDescriptionDefault
cityYesCity name, e.g. Houston. A city name only, never a street address.
pestNoOptional pest type, e.g. termites, bed bugs, rodents, ants, cockroaches, mosquitoes, wildlife. Defaults to general pest control.
stateYesTwo-letter US state code, e.g. TX

Output Schema

ParametersJSON Schema
NameRequiredDescription
noteYesThe limits a reader must be told
pestNoPest type the answer covers
locationNoCity and state the answer covers
companiesYes
fullListAndFreeRequestNoPestPin page with the full list and the free request form
totalRecordMatchedCompaniesNoHow many license-record companies match, before the 8-row cap

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already establish read-only, idempotent, open-world, and non-destructive behavior. The description adds meaningful behavioral details: results are limited to 8, include source links and last-processed dates, and are matched public records rather than recommendations or confirmed coverage.

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 main purpose is stated clearly up front, but the description becomes repetitive and includes tangential consumer/privacy details (e.g., free calls, never resold, coverage disclaimers) that could be shortened without losing necessary meaning.

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?

The description provides a good summary of the result contents, limits, and limitations, which is adequate for an agent to understand what to expect. It does not mention edge cases like empty results or invalid inputs, but those are not necessary for basic use.

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?

The input schema already covers all three parameters with descriptions and examples, so the description adds little parameter-specific meaning. It reinforces the city/state context and optional pest default but does not go beyond the schema's coverage.

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-resource pair ('Find licensed pest control companies') and clarifies scope (near a US city, returns up to 8 matching businesses). This clearly distinguishes it from the sibling tools by focusing on discovery of licensed companies rather than links, cost, or verification.

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 by the purpose: call this when you need licensed pest control companies for a city/state, optionally filtered by pest type. However, it does not explicitly describe when to prefer this over the sibling tools (e.g., verify_license for checking a specific license, get_pest_cost for pricing).

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

get_pest_costPest control cost rangeA
Read-onlyIdempotent
Inspect

US national planning cost range for a pest control service, with the factors that move the price. This is an editorial planning range, not a quote and not a measured average. Always tell the person to get a written local quote before hiring.

ParametersJSON Schema
NameRequiredDescriptionDefault
pestYesPest or service, e.g. termite control, bed bugs

Output Schema

ParametersJSON Schema
NameRequiredDescription
noteYes
pestYes
answerNoShort direct answer a person can read out
detailsNoPestPin cost page for this pest
priceFactorsNo
nationalPlanningRangeUsdYes

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds crucial context by clarifying this is an editorial planning range, not a quote or measured average, and instructs the agent to recommend a local quote. This goes beyond the annotations without contradicting them.

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?

The description is two sentences with no wasted words. It front-loads the primary purpose (cost range) and immediately follows with the key caveat (not a quote, always advise local quote). Perfectly concise and well-structured.

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 an output schema present, the description does not need to explain return values. It covers the scope (US national), the nature (planning range), and provides actionable guidance for the agent. It does not explicitly list alternatives or edge cases, but for a simple one-parameter tool this is sufficient.

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?

The schema description covers 100% of the parameter, providing examples and a clear description ('Pest or service, e.g. termite control, bed bugs'). The tool description does not add additional meaning about the parameter beyond what the schema already states, so it meets the baseline for high schema 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?

The description clearly states that the tool provides a US national planning cost range for pest control services, with factors that affect the price. It distinguishes itself from siblings (e.g., find_licensed_pros, get_intro_request_link) by focusing on cost estimation rather than finding providers or generating links, though it does not explicitly name them.

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?

The description implies when to use the tool (for planning cost ranges) and instructs the agent to always advise the person to get a written local quote. However, it does not explicitly state when not to use it or mention alternative tools, so the routing 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.

verify_licenseCheck a pest control licenseA
Read-onlyIdempotent
Inspect

Check whether a US pest control company holds a state license record. Searches PestPin's directory of official state regulator records (34 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 34 states, some businesses are excluded as lawn, agricultural or government records, and name spellings vary.

ParametersJSON Schema
NameRequiredDescriptionDefault
stateNoOptional two-letter US state code to narrow the search, e.g. FL
companyYesBusiness name (or license number) to search for, e.g. Acme Pest Control

Output Schema

ParametersJSON Schema
NameRequiredDescription
noteYesThe limits a reader must be told
matchesYesMatched license records, empty when nothing matched
totalMatchesYesHow many records matched in total

TDQS

A4.4/5.0
Behavior5/5

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive, open-world), and the description adds substantial context beyond them: 34-state coverage, reprocessing cadence, variable publication timing by regulator, the fact that status reflects PestPin's last check with its date, and an explicit false-negative caveat about lawn/agricultural/government exclusions and spelling variance.

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

Conciseness4/5

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

Front-loaded with purpose, then caveats; every sentence carries information. It is on the dense side with several stacked parentheticals, but nothing is padding for a tool with this many caveats to convey.

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?

An output schema exists, so return-value documentation is not strictly required, yet the description still outlines the matched fields and the verification link. Combined with the coverage and false-negative warnings, an agent has everything needed to call and interpret this 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 description coverage is 100%, and the schema already documents both the 'company' and optional 'state' parameters, so the baseline is 3. The description mostly restates the entity being searched rather than adding format, matching, or precedence guidance for the parameters.

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 opens with a specific verb and resource: 'Check whether a US pest control company holds a state license record.' It also names the data source (PestPin's directory of official state regulator records), which makes it immediately distinguishable from verify_phone and 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?

It gives a clear trigger ('Use it when someone names a company and wants to know if it is licensed') plus a substantive exclusion about what a miss does and does not prove. It stops short of naming sibling tools as explicit alternatives, so the routing guidance is strong but not complete.

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

verify_phoneCheck a pest control phone numberA
Read-onlyIdempotent
Inspect

Check a pest control company's phone number against official state license records. Give it the number on the van, the flyer, the voicemail or the caller ID and it returns the license records that publish that exact number, each with the business name, license number, issuing state, the official state source link and the date PestPin last processed that source. Use it when someone has a number and wants to see which license records publish it, before they hire or let anyone in. The state lookups PestPin works with are searched by business name or license number, so a number on its own is normally a dead end; this covers 34 states. The match is exact on ten digits and never partial, so a number one digit different is a different company and is never offered. A match means a license record publishes that number: it does not say who answered, whether the caller works for that company, or anything about insurance or work quality. No match is not proof anyone is unlicensed: coverage is 34 states, about half of all listings publish no phone at all, and a licensed company can publish a number PestPin does not hold. Records from states that license the individual operator rather than a firm are never returned here, because a phone number is not a way to look up a private person; they are counted in withheld and the license-number lookup returns them. Only ever pass a business's number, never the person's own.

ParametersJSON Schema
NameRequiredDescriptionDefault
businessPhoneYesThe pest control company's published phone number, e.g. 713-555-0100. Dashes, brackets, spaces, a leading 1 and an extension are all accepted. Never the person's own number.

Output Schema

ParametersJSON Schema
NameRequiredDescription
noteYesThe limits a reader must be told
matchesYesLicense records publishing that number, empty when none does
withheldNoMatching records deliberately left out because that state licenses the individual operator rather than a firm. Zero when nothing was withheld.
phoneNumberNoThe ten digits the number was read as
totalMatchesYesHow many records publish that number

TDQS

A4.8/5.0
Behavior5/5

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

Goes well past the annotations: exact ten-digit matching with no partials, 34-state coverage, what a no-match does and does not prove, why individual-operator-state records are withheld, and the privacy constraint against passing a personal number. Annotations confirm the read-only/idempotent profile, and the description layers the substantive behavioral caveats on top.

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

Conciseness4/5

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

Front-loaded with the core action in the first sentence, and nearly every sentence carries operational weight. It runs long and restates the 'never the person's own number' constraint at the end, which is already implied earlier.

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?

Covers matching semantics, coverage limits, no-match interpretation, withheld-record behavior, and privacy constraints. An output schema exists, yet the description's summary of returned fields (business name, license number, state, source link, processed date) still helps frame the result.

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 real meaning by naming the sources the number comes from (van, flyer, voicemail, caller ID) and reinforcing that it must be a published business number, not a personal one. The formatting rules themselves are already in the schema.

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 (check) and resource (a pest control company's phone number) against a specific corpus (official state license records). The scope is precise enough to separate it from verify_license, which the description explicitly names as the name/license-number path.

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

Usage Guidelines5/5

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

Explicitly says when to use it ('when someone has a number and wants to see which license records publish it, before they hire or let anyone in') and when alternatives apply ('state lookups are searched by business name or license number, so a number on its own is normally a dead end'). It also routes individual-operator records to the license-number lookup.

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
    • Addedverify_phone
  2. 4 tool updates
    • Changedfind_licensed_pros6 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • changedInput schema / properties / city / description
        Previous value: -"City name, e.g. Houston"New value: +"City name, e.g. Houston. A city name only, never a street address."
      • addedInput schema / properties / city / examples
        Added value: +[
+  "Houston",
+  "Orlando"
+]
      • addedInput schema / properties / pest / examples
        Added value: +[
+  "termites",
+  "bed bugs"
+]
      • addedInput schema / properties / state / examples
        Added value: +[
+  "TX",
+  "FL"
+]
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "properties": {
+    "companies": {
+      "items": {
+        "properties": {
+          "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"
+          },
+          "phone": {
+            "description": "Published phone number, when the record has one",
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "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"
+          },
+          "verifyAtOfficialSource": {
+            "description": "Official state regulator page where this record can be checked",
+            "type": "string"
+          }
+        },
+        "required": [
+          "name",
+          "verifyAtOfficialSource",
+          "sourceCheckedOn",
+          "sourceCheckedOnScope",
+          "pestpinProfile"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "fullListAndFreeRequest": {
+      "description": "PestPin page with the full list and the free request form",
+      "type": "string"
+    },
+    "location": {
+      "description": "City and state the answer covers",
+      "type": "string"
+    },
+    "note": {
+      "description": "The limits a reader must be told",
+      "type": "string"
+    },
+    "pest": {
+      "description": "Pest type the answer covers",
+      "type": "string"
+    },
+    "totalRecordMatchedCompanies": {
+      "description": "How many license-record companies match, before the 8-row cap",
+      "type": "integer"
+    }
+  },
+  "required": [
+    "companies",
+    "note"
+  ],
+  "type": "object"
+}
    • Addedget_intro_request_link
    • Changedget_pest_cost3 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • addedInput schema / properties / pest / examples
        Added value: +[
+  "termite control",
+  "bed bugs"
+]
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "properties": {
+    "answer": {
+      "description": "Short direct answer a person can read out",
+      "type": "string"
+    },
+    "details": {
+      "description": "PestPin cost page for this pest",
+      "type": "string"
+    },
+    "nationalPlanningRangeUsd": {
+      "properties": {
+        "high": {
+          "type": "integer"
+        },
+        "low": {
+          "type": "integer"
+        },
+        "typical": {
+          "type": "integer"
+        }
+      },
+      "required": [
+        "low",
+        "high",
+        "typical"
+      ],
+      "type": "object"
+    },
+    "note": {
+      "type": "string"
+    },
+    "pest": {
+      "type": "string"
+    },
+    "priceFactors": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "pest",
+    "nationalPlanningRangeUsd",
+    "note"
+  ],
+  "type": "object"
+}
    • Changedverify_license5 fields changed
      • 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"
+}
  3. 3 tool updates
    • First observedfind_licensed_pros
    • First observedget_pest_cost
    • First observedverify_license

Related MCP Connectors

Related MCP Servers

Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources