FedWatch — Federal Funding & Lien Watcher

liens_search

Search tax-lien data. Default mode 'db': FedWatch's lien database (county lien records ingested from public sources; every hit is labeled with its source and extraction path) — filter by state, county, parcel, or free text matched against address/owner/parcel/city. For upcoming sales pass upcoming_only (sale date today or later) and/or sale_within_days, with sort 'sale_date_asc' for next-sale-first; the default view is historical, most recent sale first. Modes 'nyc' (NYC's official lien-sale notice lists, live) and 'discover'/'both' (live discovery of public tax-lien datasets on open-data portals) remain available explicitly and serve as the labeled fallback when the DB has no match or is unreachable. Every response carries the partial-coverage label — this is not national coverage.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "liens_search"
  }
}

Input Schema

Name	Required	Description
`zip`	No	NYC ZIP filter
`mode`	No	'db' (default), 'nyc', 'discover', or 'both' (nyc + discover)
`sort`	No	DB mode: 'sale_date_desc' (default) or 'sale_date_asc' (next sale first)
`limit`	No	Max results (default 25)
`query`	No	DB mode: free text matched against address / owner / parcel / city. Discovery query for mode=discover, e.g. 'Cook County tax sale' or 'Florida tax lien'
`state`	No	DB mode: state name or 2-letter abbreviation, e.g. 'New York' or 'NY'
`county`	No	DB mode: county name (partial match), e.g. 'Queens'
`parcel`	No	DB mode: exact parcel / APN id
`borough`	No	NYC borough code 1-5 (1=Manhattan, 2=Bronx, 3=Brooklyn, 4=Queens, 5=Staten Island)
`upcoming_only`	No	DB mode: only records whose sale date is today or later
`sale_within_days`	No	DB mode: only sales within the next N days (implies upcoming)

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 24, 2026

TDQS

A4.5/5.0

Behavior4/5

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

No annotations are provided, so the description carries the burden, and it does well: it discloses that hits are labeled with source and extraction path, that every response carries a partial-coverage label, and that this is 'not national coverage.' It stops short of stating auth needs, rate limits, or result-count behavior beyond the limit param.

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-loads the core ('Search tax-lien data') then mode behavior, with no filler sentences. The single dense paragraph is long but every clause carries operational meaning; minor readability cost from packing modes and filtering into one block.

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 11-param, multi-mode tool with no annotations and no output schema needs mode disambiguation, fallback behavior, and coverage caveats — all present. Return-value shape is only partially addressed (coverage label noted, but not result fields), which keeps it from a 5.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, but the description adds cross-parameter meaning the schema does not: upcoming_only and sale_within_days should be paired with sort 'sale_date_asc', and the default view is 'historical, most recent sale first.' That relationship guidance exceeds the individual field descriptions.

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 and resource ('Search tax-lien data') and then breaks down the four modes with what each returns. The coverage scope and per-mode intent let an agent distinguish this from the contracts/permits/property siblings without opening the 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?

Explicit defaults and conditions: 'db' is default, 'nyc'/'discover'/'both' are for live data, and modes 'serve as the labeled fallback when the DB has no match or is unreachable.' It also names when to pass upcoming_only/sale_within_days and which sort to pair with them.

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

All FedWatch — Federal Funding & Lien Watcher 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?