InstaBids

Published local permit facts

permit_facts

Read-onlyIdempotent

Read sourced local permit facts, with the date each rule was checked; unpublished rules get guidance to ask your bidder and confirm local requirements. Homeowners anywhere in the US can post a job; once you send it, InstaBids finds contractors to bid on it.

Input Schema

Name	Required	Description	Default
`town`	Yes	a five-digit ZIP or a town name
`trade`	No	optional

Output Schema

Name	Required	Description	Default
`town`	Yes
`records`	Yes
`guidance`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 3, 2026
- addedInput schema / properties / town / description
```
Added value: +"a five-digit ZIP or a town name"
```
- addedInput schema / properties / trade / description
```
Added value: +"optional"
```
Changed4 schema fields changedNov 3, 2026
- removedInput schema / properties / town / enum
```
Removed value: -[
-  "boca-raton",
-  "coconut-creek",
-  "parkland",
-  "pompano-beach"
-]
```
- addedInput schema / properties / town / maxLength
```
Added value: +80
```
- addedInput schema / properties / town / minLength
```
Added value: +1
```
- addedInput schema / properties / town / pattern
```
Added value: +"^(?:[0-9]{5}|[\\p{L}][\\p{L}\\p{M} ,.'’-]{0,79})$"
```

Changed1 schema field changedOct 30, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": false,
+  "properties": {
+    "guidance": {
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "note": {
+            "type": "string"
+          },
+          "trade": {
+            "enum": [
+              "ac",
+              "pool_repair"
+            ],
+            "type": "string"
+          }
+        },
+        "required": [
+          "trade",
+          "note"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "records": {
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "checked": {
+            "pattern": "^[0-9]{4}-[0-9]{2}-[0-9]{2}$",
+            "type": "string"
+          },
+          "note": {
+            "type": "string"
+          },
+          "publisher": {
+            "type": "string"
+          },
+          "sourceTitle": {
+            "type": "string"
+          },
+          "sourceUrl": {
+            "format": "uri",
+            "pattern": "^https://",
+            "type": "string"
+          },
+          "trade": {
+            "enum": [
+              "ac",
+              "pool_repair"
+            ],
+            "type": "string"
+          }
+        },
+        "required": [
+          "trade",
+          "note",
+          "sourceUrl",
+          "publisher",
+          "sourceTitle",
+          "checked"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "town": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "town",
+    "records",
+    "guidance"
+  ],
+  "type": "object"
+}

First observedOct 30, 2026

TDQS

B3.1/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, openWorldHint=false, and idempotent=true, so safety is covered. The description does add genuine value by disclosing that facts are sourced, timestamped with the check date, and that unpublished rules return fallback guidance telling the caller to confirm locally. However, the second sentence describes a job-posting workflow that is not part of this read-only lookup and can mislead an agent about side effects.

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 first sentence is dense and front-loaded with the essential behavior. The second sentence about homeowners posting jobs is off-topic boilerplate that does not earn its place in a permit-lookup definition.

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?

With two parameters, full schema coverage, an output schema, and rich annotations, the description only needs to add routing and behavior. It covers the unpublished-rule fallback but omits when to prefer it over the other permit/job siblings, leaving a gap for a fairly simple 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?

Schema description coverage is 100%, with 'town' documented as a five-digit ZIP or town name and 'trade' constrained to an enum. The description adds nothing about either parameter, so the schema carries the full burden and the 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?

The description opens with a specific verb+resource: 'Read sourced local permit facts,' and adds the scope qualifier that each rule carries the date it was checked. That is clearly distinct from siblings like job_status or check_service_area, though no sibling is named explicitly.

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

Usage Guidelines2/5

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

There is no statement of when to reach for this tool versus bid_checklist, job_guidance, or check_service_area, nor any precondition such as needing a town or trade. The only guidance is implicit in 'unpublished rules get guidance to ask your bidder,' and the closing sentence about posting a job offers no usage direction for this tool.

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

All InstaBids tools Inspect

Try in Browser

Pay for results, not tokens.Fund a bounty. Let AI agents compete and collaborate to solve your problems.agentbounties.appAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?