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 by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Uptime
100.0% over 57 days
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.5/5.0

Scored across 6 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: finding pros by city/pest, building a request link, getting planning cost ranges, fetching a company's published prices, verifying a license by name, and verifying a phone number. Even the overlapping verification tools are cleanly separated by input type and use case.

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern: get_intro_request_link, find_licensed_pros, verify_license, verify_phone. The verbs are meaningful and align with each tool's action, making the set predictable and easy to navigate.

Tool Count5/5

Six tools is a well-scoped set for a pest-control lookup and verification service. Each tool covers a distinct homeowner need without redundancy or bloat.

Completeness4/5

The toolset covers the core workflow: finding licensed pros, verifying a license or phone number, getting cost estimates, and requesting contact. Minor gaps exist, such as no direct machine-readable full-list retrieval or broader company-detail lookup, but these do not break the main use cases.

Available Tools

6 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

A4.5/5.0
Behavior5/5

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

Beyond the readOnly/idempotent annotations, the description discloses that listings are matched public records rather than recommendations or rankings, that most businesses have not confirmed services, and that a full-list link is provided. This materially shapes agent expectations.

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?

Three sentences front-load the main action and result, then add return fields, a caveat about public records, and consumer-context details. No redundant or filler content.

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?

With an output schema present, the description need not restate return structure. It covers result limit, data fields, source attribution, caveats, and the full-list link, making it complete for an agent to select and invoke the tool.

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 documents all three parameters with examples and descriptions (100% coverage). The description adds context like 'near a US city' and 'pest type', but does not add meaning beyond the schema's parameter documentation.

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 uses a specific verb and resource ('Find licensed pest control companies near a US city') and states the core result: up to 8 licensed matches with license number, phone, source link, and processing date. This clearly differentiates it from sibling tools like verify_license or get_pest_cost.

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?

The intended use case is clear: a homeowner looking for licensed pest control companies in a city. It does not explicitly name alternatives or state when not to use it, but the discovery-focused purpose is unambiguous relative to verification and cost siblings.

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; the actual price for a job comes from a written local quote.

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

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds important behavioral context: it is an editorial range, not a measured average, and includes factors that move price. This goes beyond what annotations state, clarifying scope and limitations.

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, front-loaded with the core purpose and then immediately clarifying limitations. No wasted words; every phrase adds value.

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?

The description fully explains the nature of the return (a planning range, not a quote) and its intended use. Given the output schema presumably describes result structure, nothing else is needed. The tool's purpose, limitations, and context are clearly conveyed.

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 the 'pest' parameter is fully described in the schema with examples. The description doesn't add specific parameter details, but its mention of 'factors that move the price' hints at how the parameter influences the result. This is adequate given the schema 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?

The description clearly states the tool provides a 'US national planning cost range for a pest control service' with factors that move the price. It immediately distinguishes itself from siblings like get_price_card (which likely gives specific quotes) by clarifying this is an editorial range, not a quote.

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?

The description explicitly contrasts the planning range with a 'written local quote', implying it should be used for rough estimates rather than actual pricing. It notes it is not a quote or measured average, giving strong context for when to use it. However, it doesn't explicitly name alternative tools that should be used in its place.

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

get_price_cardPrices a pest control company publishesA
Read-onlyIdempotent
Inspect

The prices a licensed US pest control company has published on its own PestPin listing, as ranges per service (for example a one-time general treatment, a quarterly plan, a termite inspection, bed bug treatment per room), with the date the company last changed them and when it can usually start. Entered by the company's verified owner, never by PestPin; companies that have not published prices return no match, and that is not a statement about their prices. Use it to answer 'what does charge' without phoning them. The company confirms the exact price for a job.

ParametersJSON Schema
NameRequiredDescriptionDefault
stateNoOptional two-letter state to narrow the match
companyYesCompany name, or part of it

Output Schema

ParametersJSON Schema
NameRequiredDescription
noteYes
matchesYes

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, but the description adds meaningful context beyond them: data is entered by the company's verified owner and never by PestPin, no match does not imply absence of prices, and the exact price requires company confirmation. These are non-obvious behavioral details that help an agent interpret results correctly.

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?

The description is longer than a minimal definition but every sentence earns its place: it defines the returned data, explains provenance and no-match semantics, and gives direct usage guidance. It is front-loaded with the core purpose and structured clearly, though it could be slightly tightened.

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?

With an output schema present and annotations covering the safety profile, the description supplies all necessary lookup semantics: scope, data source, no-match interpretation, and usage context. An agent has enough information to select and invoke this tool correctly without missing critical details.

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 the schema already documents both 'company' and 'state' parameters clearly. The description does not add parameter-level semantics beyond what the schema states, which is acceptable given the full coverage. Baseline 3 is appropriate.

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: it gets a company's published price card as ranges per service, including metadata like last change date and start availability. It also distinguishes itself from generic cost tools by emphasizing that prices are self-published on the company's own PestPin listing by a verified owner. This makes the tool's scope unambiguous.

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?

Explicitly tells the agent to use this tool to answer 'what does <company> charge' without phoning them. It also clarifies that a no-match result is not a statement about the company's prices. It does not explicitly name sibling alternatives or exclusion conditions, so it falls just short of full usage guidance.

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 (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.

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.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.

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 35 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 35 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. It looks up a business's published number, never a 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. A business's number, not the person's own.

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?

The description goes far beyond the annotations by disclosing exact ten-digit matching, what a match does and does not imply, open-world limitations, 35-state coverage, and the exclusion of individual-operator records. These details align with openWorldHint and readOnlyHint 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.

Conciseness4/5

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

The description is front-loaded with purpose and output, then covers use cases and caveats. It is longer than strictly necessary, with some repetition around the business-vs-person distinction, but every sentence contributes operational meaning for a tool with subtle matching semantics.

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?

Given one parameter, full schema coverage, and an output schema, the description covers input sources, return contents, exact-match behavior, no-match interpretation, state coverage, and alternative lookups. Nothing an agent needs to invoke it correctly is missing.

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?

The schema already documents the single parameter with examples and accepted formats, so the baseline is 3. The description adds real-world input sources ('the number on the van, the flyer, the voicemail or the caller ID') and reinforces that it must be a business number, not a personal one, which helps an agent map user intent to the parameter.

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 a pest control company's phone number against official state license records.' It also lists the exact output fields, which distinguishes it from sibling tools like verify_license that operate on license numbers rather than phone numbers.

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?

It explicitly states when to use the tool: 'Use it when someone has a number and wants to see which license records publish it, before they hire or let anyone in.' It also gives exclusions, such as never looking up a person's own number, and points to the license-number lookup as the alternative for individual-operator records.

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
    • Changedverify_phone1 field changed
      • changedInput schema / properties / businessPhone / description
        Previous value: -"The 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."New value: +"The pest control company's published phone number, e.g. 713-555-0100. Dashes, brackets, spaces, a leading 1 and an extension are all accepted. A business's number, not the person's own."
  2. 1 tool update
    • Addedget_price_card
  3. 1 tool update
    • Addedverify_phone
  4. 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"
+}
  5. 3 tool updates
    • First observedfind_licensed_pros
    • First observedget_pest_cost
    • First observedverify_license

Related MCP Connectors

Related MCP Servers

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