Skip to main content
Glama
Sign In

InstaBids

by ai.instabids
OverviewDiscussionsAdmin
This connector has been deprecated

Duplicate listing. The current InstaBids connector is https://glama.ai/mcp/connectors/ai.instabids/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.

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": {
      "town": "<town>"
    },
    "name": "permit_facts"
  }
}

Input Schema

NameRequiredDescriptionDefault
townYesa five-digit ZIP or a town name
tradeNooptional trade key such as roofing

Output Schema

NameRequiredDescriptionDefault
townYes
recordsYes
guidanceYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / trade / description
      Previous value: -"optional"New value: +"optional trade key such as roofing"
  2. Changed2 schema fields changed
    • addedInput schema / properties / town / description
      Added value: +"a five-digit ZIP or a town name"
    • addedInput schema / properties / trade / description
      Added value: +"optional"
  3. Changed4 schema fields changed
    • 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})$"
  4. Changed1 schema field changed
    • 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"
+}
  5. First observed

TDQS

B3.4/5.0
Behavior4/5

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

Annotations already establish readOnly, idempotent, non-destructive, closed-world behavior, so the description is free to add the parts annotations cannot express. It does so usefully: facts are sourced, each rule carries the date it was checked, and unpublished rules return guidance rather than failing or returning nothing. That partial-result behavior is exactly the kind of nuance an agent needs before trusting the output.

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 but front-loaded and earns its place by covering sourcing, timestamps, and the unpublished fallback. The second sentence is pure marketing about posting jobs and receiving bids, which is irrelevant to calling a read-only permit lookup and should be cut.

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?

An output schema exists, so return shape and the checked-date fields need not be described here, and annotations carry the safety profile. Combined with full schema coverage of both parameters, what remains is the unpublished/unavailable outcome, which the description does disclose. Only the missing routing guidance relative to job_guidance and bid_checklist keeps it from a 5.

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 town (ZIP or name) and trade are already well documented, and the baseline of 3 applies. The description adds nothing about either parameter — not how town granularity affects lookup, nor that trade further narrows results. Note the schema's trade enum ('ac', 'pool_repair') contradicts its own 'such as roofing' example, but that is a schema defect, not something this description addresses.

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 opening clause gives a specific verb and resource (read sourced local permit rules) plus the notable attribute that results carry a checked date. That distinguishes it reasonably well from job_guidance and bid_checklist, though it never names a sibling. The trailing sentence about homeowners posting jobs and InstaBids finding contractors is unrelated to the tool's function and dilutes the purpose.

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 explicit when-to-use or when-not-to-use guidance, and no sibling is named as an alternative. The only guidance is an implied fallback: if a rule is unpublished, the caller is told to ask the bidder and confirm locally. An agent must infer the invocation context (pre-bid check for a given town/trade) entirely on its own.

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

All InstaBids 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