de en es ja ko ru zh

Saveproptax

Name: Saveproptax
Author: atifnayeem-oss

by atifnayeem-oss

Overview Schema Source Related Servers Score Discussions Admin

JavaScript

Remote

SavePropTax MCP server

A remote MCP server and an open HTTP API for California property tax appeals.

Ask it whether a home is over-assessed. If recent comparable sales support a lower value, it prepares the county's own Proposition 8 decline-in-value review form and emails a signing link to the homeowner. The owner signs and pays a flat $29. Checking is free, keyless, and can only ever lower a tax bill, never raise it.

There is nothing to install. The server is hosted:

https://saveproptax.com/mcp

Streamable HTTP, no authentication, stateless.

Add it to a client

Claude: Settings, then Connectors, then Add custom connector, and paste the URL above.

ChatGPT: Settings, then Connectors (or Apps), then add an MCP server by URL, where your plan supports custom connectors.

Claude Code:

claude mcp add --transport http saveproptax https://saveproptax.com/mcp

Any MCP client: point a streamable-HTTP transport at the URL. No token.

Related MCP server: assessor-lookup-mcp

Tools

Tool	Arguments	What it does
`check_property_tax_savings`	`address` (required), `unit`	Free check of one California home. Returns a status, the current assessment, an opinion of value from recent comparable sales, and estimated annual savings. A qualifying result carries a `continueToken`.
`start_filing`	`continueToken`, `ownerName`, `ownerPhone`, `ownerEmail`	Prepares the county form and emails the signing link to the owner. The link is never returned to the client.
`get_filing_status`	`docId`	Coarse status only: `awaiting_signature`, `awaiting_payment`, `filed`, `delivered`, `unknown`. No personal information.

The rule that shapes everything

An agent never handles the signature or the money. The signing link goes to the owner's inbox. The owner reviews the county's own form, signs it, and pays. The worst an anonymous caller can do is spend a free check and send a real homeowner a legitimate link to their own property.

HTTP API

The same capability without MCP. Keyless.

curl -s https://saveproptax.com/api/agent/check \
  -H 'Content-Type: application/json' \
  -d '{"address": "123 Main St, Walnut Creek"}'

A qualifying response:

{
  "status": "qualifies",
  "message": "This property qualifies: recent comparable sales support a value of $915,000 against the $1,024,000 assessment, an estimated $1,204 per year in tax savings; filing costs a flat $29 and the owner signs and pays.",
  "property": { "address": "123 MAIN ST, WALNUT CREEK CA", "county": "Contra Costa" },
  "estimate": { "assessment": 1024000, "opinion": 915000, "estimatedAnnualSavings": 1204 },
  "filing": { "feeUsd": 29, "deadline": "November 30, 2026" },
  "continueToken": "eyJ...valid 24 hours",
  "cached": false,
  "checkedAt": "2026-08-19T18:00:00.000Z"
}

Then hand the token and the owner's details to prepare:

curl -s https://saveproptax.com/api/agent/prepare \
  -H 'Content-Type: application/json' \
  -d '{
    "continueToken": "eyJ...",
    "ownerName": "Jane Homeowner",
    "ownerPhone": "925 555 0100",
    "ownerEmail": "jane@example.com"
  }'

{ "docId": "d0c1d2...", "status": "awaiting_signature",
  "statusUrl": "https://saveproptax.com/api/agent/status?doc=d0c1d2...",
  "ownerEmailSent": true }

Poll the status endpoint for progress:

curl -s 'https://saveproptax.com/api/agent/status?doc=d0c1d2...'

Every status to handle

status	meaning
`qualifies`	Comparable sales support a defensibly lower value, savings exceed $500 a year, and the county window is open. The only status carrying a `continueToken`.
`fair_assessment`	Sales do not support a value below the current assessment this year.
`not_enough_data`	Too few closely matched recent sales for a defensible filing.
`not_residential`	The parcel's county record is not residential.
`window_closed`	The county's review window has closed; `filing.reopens` says when it returns.
`county_not_served`	A California county not covered yet.
`already_filed`	A review request was already filed for this property this year.
`address_not_found`	Retry with the city included.
`needs_more_info`	The message says what is missing, for example a unit number.
`busy`	Heavy load: fresh checks briefly paused, cached answers still serve. Retry shortly.

Every message is a relayable one-sentence explanation you can pass to your user as written.

Optional key

curl -s https://saveproptax.com/api/agent/register \
  -H 'Content-Type: application/json' \
  -d '{"agentName": "MyAssistant", "contactEmail": "dev@example.com"}'

Returns a key immediately, no approval step. Send it as the x-agent-key header for double the fresh-check headroom and named attribution. Anonymous use works fine; registration is identity, not permission.

Rate limits

Per-address cache, 24 hours. Repeat checks are instant, cost us nothing, and come back marked cached: true. Cached answers are never rate limited.
Hourly fresh-check budget. Fresh checks buy real records and sales data, so they share an hourly pool. Under load, fresh checks answer busy while cached answers still serve. The pipeline never degrades to a cheaper valuation method; it only delays.
Prepare gating. Requires a token from a real check, and is limited to three signing links per owner inbox per day.

Coverage

Alameda, Contra Costa, Los Angeles, Marin, Napa, Placer, Riverside, Sacramento, San Benito, San Bernardino, San Francisco, San Joaquin, San Mateo, Santa Clara, Santa Cruz, Solano, Sutter, and Yolo counties. Windows are seasonal per county; current deadlines are at https://saveproptax.com/counties.html.

Full reference: https://saveproptax.com/agents
OpenAPI: https://saveproptax.com/openapi.json
llms.txt: https://saveproptax.com/llms.txt
Registry metadata: server.json
Partnerships and volume arrangements: support@saveproptax.com

SavePropTax prepares review requests from public records and the county's own forms; owners review and sign them. We are not a law firm, and nothing here is legal or tax advice. Reductions are decided solely by the County Assessor.

License

MIT. See LICENSE. The license covers this repository's contents; the hosted service is governed by the terms at https://saveproptax.com/legal.html.

Run locally (stdio)

The hosted server needs no install. For stdio-only MCP clients, this repo ships a dependency-free bridge (Node 18+):

{
  "mcpServers": {
    "saveproptax": {
      "command": "node",
      "args": ["bridge.js"]
    }
  }
}

Or with Docker: docker build -t saveproptax-mcp . && docker run -i saveproptax-mcp. Introspection is answered locally; tool calls are forwarded to saveproptax.com/mcp.

Available Tools

3 tools

check_property_tax_savingsAInspect

Check whether a California home qualifies for a Proposition 8 decline-in-value property tax reduction. Free. Returns qualification status, estimated annual savings, assessment, opinion of value, county and deadline, and a continueToken when the property qualifies.

ParametersJSON Schema

Name	Required	Description	Default
`unit`	No	Unit number for condos, if any
`address`	Yes	Street address including the city, e.g. "123 Main St, Walnut Creek"

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations, the description carries the burden. It discloses that the tool is free, returns qualification status, estimated savings, assessment, county, deadline, and a continueToken. It does not explicitly state whether it makes any modifications, but as a 'check' tool, it is reasonably transparent about its read-only nature.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that front-loads the primary purpose and lists all key outputs concisely. Every phrase adds value, with no waste.

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?

Given only two simple parameters and no output schema, the description is complete. It enumerates all return values and mentions the continueToken, which links to sibling tools for filing, providing enough context for an agent to use it correctly.

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 coverage is 100% (both unit and address are described). The description adds minimal additional meaning beyond the schema, only implicitly requiring the address to include city. Baseline 3 is appropriate when the schema fully documents parameters.

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 checks California home qualification for Proposition 8 decline-in-value property tax reduction, using a specific verb and resource. It distinguishes from siblings (start_filing, get_filing_status) by focusing on the pre-filing check and mentioning a continueToken for qualified properties.

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?

The description implies usage context by noting it returns a continueToken when the property qualifies, suggesting it is a prerequisite for filing. However, it does not explicitly state when to use it versus alternatives or include when-not guidance, so a slight deduction is warranted.

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

get_filing_statusAInspect

Coarse progress for a filing: awaiting_signature, awaiting_payment, filed, delivered. Returns no personal information.

ParametersJSON Schema

Name	Required	Description	Default
`docId`	Yes

TDQS

A3.7/5.0

Behavior3/5

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

With no annotations present, the description carries the behavioral burden. It usefully discloses that only coarse progress is returned and that no personal information is included, but it does not mention authentication needs, invalid document handling, or whether this operation is purely read-only.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is one efficient sentence that front-loads the main purpose, lists the possible status values, and adds a useful privacy guarantee. Every part serves a purpose with no redundant phrasing.

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 simple shape (one required string parameter, no output schema), the description is nearly sufficient: it communicates the coarseness and enumerates possible values. It only lacks a note about missing or invalid documents, and the relationship to 'start_filing' is implicit rather than explicit.

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

Parameters2/5

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

Schema description coverage is 0%, and the description does not explain 'docId' at all. The name 'docId' is suggestive but not amplified by the tool description; the parameter semantics are left mostly to inference.

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 uses a specific verb ('get') and resource ('filing status'), names the coarse statuses ('awaiting_signature, awaiting_payment, filed, delivered'), and clearly differentiates itself from the sibling tools 'check_property_tax_savings' and 'start_filing'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

The description implies this tool is for retrieving a filing's status after starting a filing, but it does not explicitly say when to use it versus alternatives or any workflow order. It provides clear context but not explicit when-to-use guidance.

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

start_filingAInspect

Start a filing for a qualifying property. Requires the continueToken from a qualifying check plus the owner's name, phone, and email. The signing link is emailed to the owner; it is never returned to the caller. The owner signs and pays a flat $29.

ParametersJSON Schema

Name	Required	Description	Default
`ownerName`	Yes
`ownerEmail`	Yes
`ownerPhone`	Yes
`continueToken`	Yes

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that the signing link is never returned to the caller and that a flat $29 fee applies, which are important side-effects. It does not mention potential errors or auth, but for a simple mutation it is adequately transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three concise sentences that front-load the action and prerequisites, then key output behavior, then cost. Every sentence adds value without redundancy.

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 moderate complexity, no output schema, and no annotations, the description covers the essential points: action, prerequisites, outcome (link emailed, not returned), and cost. It does not mention error handling or what the caller receives as a response, but for a simple tool this is sufficient.

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 coverage is 0%, so the description must compensate. It explains that continueToken comes from a qualifying check, adding meaning beyond the schema. However, ownerName, ownerPhone, and ownerEmail are only listed without formats or constraints, providing minimal additional semantics.

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 action (start a filing) and the target resource (a qualifying property). It distinguishes from siblings by focusing on the initiation step, whereas check_property_tax_savings evaluates eligibility and get_filing_status retrieves status.

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?

It explicitly states the prerequisite (continueToken from a qualifying check) and describes the workflow (link emailed to owner, payment). It implies the use case (after a qualifying check) but does not explicitly mention alternatives or when not to use it, though the context is clear.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

3 tool updatesv0.1.0Aug 19, 2026
- First observedcheck_property_tax_savings
- First observedget_filing_status
- First observedstart_filing

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0

Scored 2026-08-19 21:35 across 3 tools

Disambiguation5/5

Each tool has a distinct, non-overlapping purpose: checking eligibility, starting a filing, and tracking status. An agent can clearly select the right tool for each stage of the workflow.

Naming Consistency5/5

All tools follow the same verb_noun pattern: check_property_tax_savings, start_filing, get_filing_status. The naming is uniform and predictable, with no stylistic deviations.

Tool Count5/5

Three tools is ideal for this narrow domain, covering the essential workflow (check → start → status) without redundancy or bloat. Each tool earns its place.

Completeness5/5

The tools cover the full lifecycle of the service: qualification assessment, initiation, and status tracking. No obvious missing operations (such as cancellation) are needed for the stated purpose.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

transaction-coordinator A
io.github.GordonHal
AI transaction coordinator + legal-matters platform for real estate and law firms.
Real Estate Legal & Compliance
112
agentic-ai A
io.github.anthonywlicausi
Deal intelligence for agents: SEC-verified financials, validation, institutional deal scoring.
Finance Research & Data
42
Curagent Title Risk A
io.github.ksh0rt
AI title risk analysis for Florida real estate closing docs. Get an API key at curagent.io
Developer Tools Legal & Compliance Real Estate
31
myplot.ai Property Intelligence A
ai.myplot
US property risk data for agents: flood, hazards, taxes, air quality. Credits or USDC.
Real Estate Finance Location Services
21

Related MCP Servers

readypermit-mcp
Real Estate Government Data Open Data
Galax-ai
A
license
A
quality
D
maintenance
AI-powered property intelligence for instant zoning analysis, buildability assessments, ADU eligibility, flood risk, and development feasibility reports for any US address.
Updated 6 months ago (2026-03-23 19:30 UTC)
5
1
MIT
assessor-lookup-mcp
Real Estate Government Data Search
chadru
A
license
Not graded
quality
A
maintenance
Enables AI agents to look up county assessor public records for properties, check MLS discrepancies against public data, and discover new county assessor sources, all via a local MCP server for real-estate appraisal workflows.
Updated 2 months ago (2026-07-14 20:15 UTC)
6
MIT
Real Estate MCP Server
Finance Location Services Search
0Xfftobit
A
license
Not graded
quality
B
maintenance
Enables structured real estate workflows including property search, agent/client management, market intelligence, mortgage calculations, valuation, investment analysis, and document ingestion, with offline-first capabilities and optional live data integrations.
Updated 2 months ago (2026-07-15 15:07 UTC)
AGPL 3.0
Property MCP Server
digitsouler
A
license
Not graded
quality
B
maintenance
Enables AI assistants to operate property management systems via natural language, covering repair orders, owner info, payments, notices, and inspections. Features a full agentic workflow with human-in-the-loop and observability.
Updated 2 months ago (2026-07-19 15:21 UTC)
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/atifnayeem-oss/saveproptax-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

SavePropTax MCP server

Add it to a client

Tools

The rule that shapes everything

HTTP API

Every status to handle

Optional key

Rate limits

Coverage

More

License

Run locally (stdio)

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API