Skip to main content
Glama

fundz

by net.fundz
OverviewDiscussionsAdmin

Search office expansions

search_office_expansions
Read-onlyIdempotent

Office expansions, the same feed as app.fundz.net/office-expansions: new office leases, expansions and relocations that public companies disclosed in SEC 8-K filings (the filer is always the tenant taking space; renewals of existing space are left out unless lease_type asks for them, and factory or warehouse sites unless facility_type asks for them), with address and country, facility type, square footage, exact lease term, annual and total base rent, landlord or sublandlord, start dates and a plain-English summary. A company taking more space is usually about to hire. Filter by state, city, company, lease type, minimum square feet and filing date. Page through every match with page; use since to get only filings on or after a date.

Input Schema

NameRequiredDescriptionDefault
cityNoCity of the leased space (partial match), e.g. "Austin"
daysNoOnly filings in the last N days (default: all)
pageNoPage number, starting at 1 (default 1). The reply ends with the total and next_page when there are more.
limitNoResults per page (default 20, max 50)
sinceNoOnly filings on or after this ISO date, e.g. "2026-10-01". Overrides days.
stateNoUS state 2-letter code(s) of the leased space, comma-separated, e.g. "CA, NY"
lease_typeNoOne or more of: new, expansion, relocation, renewal (comma-separated), or all. Default: new, expansion and relocation (renewals excluded).
company_nameNoCompany name (partial, case-insensitive)
facility_typeNoOne or more of: office, lab, mixed, manufacturing, warehouse, retail (comma-separated), or all. Default: everything except pure manufacturing and warehouse sites.
min_square_feetNoMinimum square footage, e.g. 20000

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / facility_type
      Added value: +{
+  "description": "One or more of: office, lab, mixed, manufacturing, warehouse, retail (comma-separated), or all. Default: everything except pure manufacturing and warehouse sites.",
+  "type": "string"
+}
  2. Changed1 schema field changed
    • changedInput schema / properties / lease_type / description
      Previous value: -"One or more of: new, expansion, relocation, renewal (comma-separated)"New value: +"One or more of: new, expansion, relocation, renewal (comma-separated), or all. Default: new, expansion and relocation (renewals excluded)."
  3. Added

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/safe, so the description only needed to add context, and it does: default exclusions for renewals and manufacturing/warehouse sites, the tenant-always-filer rule, and the pagination reply shape (total + next_page). It omits any rate-limit or latency expectations, which keeps it from a 5.

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?

Front-loaded with what the feed is, then the filter set and the paging hint. The long parenthetical of returned fields is dense but each clause carries information; nothing is filler.

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?

With no output schema, the description compensates by enumerating returned fields (address, country, facility type, square footage, lease term, rent, landlord, dates, summary) and by describing the pagination contract. Coverage is strong, though it never states the response envelope beyond total/next_page.

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% and the field descriptions already state defaults (lease_type default set, facility_type default set, 'since overrides days', page/limit behavior). The prose largely restates those defaults, so the schema is doing the heavy lifting and a baseline 3 is warranted.

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+resource and pins down the exact dataset: new office leases/expansions/relocations disclosed in SEC 8-K filings, with the filer always the tenant. It is clearly distinguishable from siblings like search_office_permits and search_sec_filings 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 Guidelines4/5

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

Explains the inclusion/exclusion logic (renewals and factory/warehouse sites are omitted unless lease_type or facility_type asks for them) and points to `since` for date-bounded retrieval. It does not name an alternative sibling tool for adjacent needs (e.g. permits vs leases), so it stops short of explicit routing.

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

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