fundz

Search office build-out permits

search_office_permits

Read-onlyIdempotent

Office build-out permits, the Permits tab of app.fundz.net/office-expansions: commercial tenant build-out, alteration and new-building permits from city records in New York, Los Angeles, Chicago, Boston, San Francisco and Seattle, with the named tenant (private and public companies), address, estimated build-out cost, permit status and a Fundz company link when matched. A permit is usually pulled 30 to 90 days after a lease is signed, so it is an early sign a company is adding space and about to hire. By default only permits that name a tenant or owner-occupier, cost $250K or more, and are not food, retail or salon fit-outs or certificates of occupancy (finished work) are returned; set min_cost, include_consumer or include_completed to widen. Use together with search_office_expansions (SEC 8-K leases, public companies, any geography) for the full expansion picture. Filter by city, state, company, work type, minimum cost and filing date. Page through every match with page; use since to get only permits filed on or after a date.

Input Schema

Name	Required	Description
`city`	No	One or more of NYC, SF, LA, CHI, BOS, SEA or the city name, comma-separated. Default: all six.
`days`	No	Only permits filed in the last N days (default 60)
`page`	No	Page number, starting at 1 (default 1). The reply ends with the total and next_page when there are more.
`sort`	No	"newest" (default) or "cost" (largest build-out first)
`limit`	No	Results per page (default 20, max 50)
`since`	No	Only permits filed on or after this ISO date, e.g. "2026-10-01". Overrides days.
`state`	No	US state 2-letter code(s), comma-separated, e.g. "NY, MA"
`min_cost`	No	Minimum estimated build-out cost in USD. Default 250000 (smaller permits are rarely an expansion signal); set 0 or 1 to see every size. Not applied by default when company_name is given.
`work_type`	No	One or more of: tenant_improvement, new_building, alteration, fitout, other (comma-separated)
`company_name`	No	Tenant, owner or applicant name (partial, case-insensitive)
`matched_only`	No	Only permits matched to a Fundz company profile
`include_unnamed`	No	Also return permits that name no tenant (landlord or developer work). Default false.
`include_consumer`	No	Also return cafe, restaurant, retail, salon, gym and hotel fit-outs and food-service vendors. Default false: a coffee shop build-out is not a hiring signal.
`include_completed`	No	Also return certificates of occupancy (the work is finished, not starting). Default false.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 12, 2026

addedInput schema / properties / include_completed

Added value: +{
+  "description": "Also return certificates of occupancy (the work is finished, not starting). Default false.",
+  "type": "boolean"
+}

addedInput schema / properties / include_consumer

Added value: +{
+  "description": "Also return cafe, restaurant, retail, salon, gym and hotel fit-outs and food-service vendors. Default false: a coffee shop build-out is not a hiring signal.",
+  "type": "boolean"
+}

changedInput schema / properties / min_cost / description

Previous value: -"Minimum estimated build-out cost in USD, e.g. 250000"New value: +"Minimum estimated build-out cost in USD. Default 250000 (smaller permits are rarely an expansion signal); set 0 or 1 to see every size. Not applied by default when company_name is given."

AddedOct 11, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare this a read-only, idempotent, open-world, non-destructive search, so safety is covered; the description goes further by disclosing the default filtering policy (named tenant/owner-occupier only, >=$250K, excluding food/retail/salon fit-outs and certificates of occupancy) and the interpretation caveat that unnamed, consumer, and completed records are suppressed unless explicitly enabled. It also documents pagination via page and the since-overrides-days precedence, none of which the annotations convey.

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 two long sentences are dense but front-loaded with the resource and scope before the default-filter policy and the sibling reference. Some material (the explicit city list, individual filter names) duplicates the schema, which costs a little, but every sentence carries actionable content and nothing is filler.

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?

For a 14-parameter, zero-required, no-output-schema tool, the description covers selection criteria, default behavior, widening options, pagination, and the shape of returned records. The only thing an agent cannot get from structured fields is the result payload, and that is described well enough to interpret matches.

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 all 14 parameters are already documented with defaults and rationale (min_cost's $250K default, include_consumer's coffee-shop example, since overriding days). The description mostly restates this, adding only a synthesized 'set X to widen' framing; per the baseline for fully-covered schemas, a 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?

The description names a specific resource (office build-out permits from city records), its scope (six named metros, commercial tenant build-out/alteration/new-building), and the fields returned (tenant, address, estimated cost, status, Fundz company link). It also explicitly distinguishes itself from the sibling search_office_expansions by data source and geography, so an agent can choose between them without opening either schema.

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 states the domain rationale for the default filters (a permit is usually pulled 30-90 days after a lease is signed, so it signals expansion and hiring) and gives the exact levers to widen results (min_cost, include_consumer, include_completed, include_unnamed). It also names the complementary tool, search_office_expansions, and the condition under which to combine them for the full expansion picture.

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

All fundz 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?