Kolmo Construction

Permit submittal checklist

resolve_permit_submittals

Read-onlyIdempotent

Resolve the structured submittal-item set for a specific parcel + permit scope, via the unified permit-engine pipeline. Use this when you need the per-item checklist (with triggers, source citations, filler actor, gap-resolution path) — not just the rule-level summary that check_permit_requirements returns. Output fidelity per jurisdiction: Seattle is "full" (each item cites the SDCI Tip, code section or City page it rests on; some items describe what the source requires rather than quoting it); the other 9 verified cities are "wa-baseline-stub" until their detail backfill lands. Unverified jurisdictions return no-spec.

Input Schema

TableJSON Schema

Name	Required	Description
`scope`	Yes	Permit scope — the (project-type x work-class) identifier the provider catalogs by
`address`	Yes	Full street address — geocoded to a parcel and matched to a jurisdiction provider
`envelopeChange`	No	Project alters the building envelope (windows, doors, siding, roof). Default false. Drives WSEC triggers.
`structuralChange`	No	Project involves a structural change (header, framing, lateral). Default false. Drives several triggers.
`totalFloorAreaSqft`	No	Total floor area in sqft. Used by SEPA threshold (>=12000) and other size-based triggers.
`projectValuationUsd`	No	Project valuation in USD

Output Schema

TableJSON Schema

Name	Required	Description	Default
`ok`	Yes
`scope`	Yes
`totals`	No
`address`	No
`parcelId`	No
`applicable`	No
`disclaimer`	No
`permitType`	No
`attribution`	Yes
`skippedCount`	Yes
`jurisdictionId`	Yes
`jurisdictionFidelity`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedSep 3, 2026
- removedOutput schema / properties / attribution / properties / contractorLicense
```
Removed value: -{
-  "type": "string"
-}
```
- removedOutput schema / properties / attribution / properties / note
```
Removed value: -{
-  "type": "string"
-}
```
- removedOutput schema / properties / attribution / properties / organization
```
Removed value: -{
-  "type": "string"
-}
```
- removedOutput schema / properties / attribution / properties / retrievedFrom
```
Removed value: -{
-  "type": "string"
-}
```
- removedOutput schema / properties / attribution / properties / url
```
Removed value: -{
-  "type": "string"
-}
```
- changedOutput schema / properties / attribution / required
```
Previous value: -[
-  "organization",
-  "contractorLicense",
-  "url",
-  "sourceUrl",
-  "citeAs",
-  "retrievedFrom",
-  "note"
-]New value: +[
+  "sourceUrl",
+  "citeAs"
+]
```

Changed1 schema field changedAug 31, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": true,
+  "properties": {
+    "address": {},
+    "applicable": {},
+    "attribution": {
+      "additionalProperties": true,
+      "properties": {
+        "citeAs": {
+          "description": "Ready-made citation line. Use verbatim.",
+          "type": "string"
+        },
+        "contractorLicense": {
+          "type": "string"
+        },
+        "note": {
+          "type": "string"
+        },
+        "organization": {
+          "type": "string"
+        },
+        "primarySource": {
+          "description": "Present when Kolmo verified but does not author the fact — cite both.",
+          "type": "string"
+        },
+        "retrievedFrom": {
+          "type": "string"
+        },
+        "sourceUrl": {
+          "description": "The specific page these facts render on. Link this, not the site root.",
+          "type": "string"
+        },
+        "url": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "organization",
+        "contractorLicense",
+        "url",
+        "sourceUrl",
+        "citeAs",
+        "retrievedFrom",
+        "note"
+      ],
+      "type": "object"
+    },
+    "disclaimer": {},
+    "jurisdictionFidelity": {},
+    "jurisdictionId": {
+      "type": "string"
+    },
+    "ok": {
+      "const": true,
+      "type": "boolean"
+    },
+    "parcelId": {},
+    "permitType": {},
+    "scope": {
+      "type": "string"
+    },
+    "skippedCount": {
+      "type": "number"
+    },
+    "totals": {}
+  },
+  "required": [
+    "ok",
+    "jurisdictionId",
+    "scope",
+    "skippedCount",
+    "attribution"
+  ],
+  "type": "object"
+}

AddedMay 17, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare the tool as read-only, open-world, idempotent, and non-destructive, so the safety profile is covered. The description adds critical behavioral details: the output fidelity varies by jurisdiction (Seattle full with citations, other cities wa-baseline-stub until backfill, unverified jurisdictions return no-spec). This is valuable context beyond the annotations, though it does not describe pagination or error handling, which are minor given the output schema.

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 concise and front-loaded, with the primary use case stated first. It is a single paragraph that efficiently covers purpose, differentiation, and jurisdiction-specific behavior. It is slightly dense but each clause earns its place, justifying a 4 rather than a 5.

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?

Given the tool's moderate complexity (6 params, 2 required, output schema present), the description covers the key usage scenario, distinct from siblings, and jurisdiction-specific expectations. It doesn't delve into output schema details, but since an output schema exists, that is not required. It is complete enough for an agent to invoke correctly, though it could mention error cases (no-spec) more explicitly.

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 explains all parameters. The description adds context that scope is a project-type x work-class identifier and that envelopeChange/structuralChange drive triggers, but these are also partly in the schema. The baseline of 3 is appropriate because the schema does the heavy lifting; the description does not add significant new semantics beyond confirming the pipeline's use.

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 resolves a structured submittal-item set for a given parcel and permit scope, explicitly differentiating it from check_permit_requirements (rule-level summary) and noting the per-item checklist includes triggers, citations, filler actor, and gap-resolution path. This is a specific verb + resource + scope, fully distinguishing it from siblings.

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: when you need the per-item checklist, not just the rule-level summary that check_permit_requirements returns. It also outlines output fidelity differences by jurisdiction, which guides expectation-setting. While it doesn't enumerate all alternatives, it clearly specifies the primary alternative and the condition for selection.

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

All Kolmo Construction 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?