Ein gehosteter MCP-Server und eine offene HTTP-API für Grundsteuereinsprüche in Kalifornien.
Fragen Sie ihn, ob ein Haus überbewertet ist. Wenn aktuelle vergleichbare Verkäufe einen niedrigeren Wert stützen, stellt er das eigene Formular des Countys zur Wertminderungsprüfung nach Proposition 8 bereit und sendet dem Hauseigentümer per E-Mail einen Unterzeichnungslink. Der Eigentümer unterschreibt und zahlt eine Pauschale von 29 $. Die Prüfung läuft kostenlos, ohne Schlüssel und kann eine Steuerrechnung nur senken, niemals erhöhen.
Es ist nichts zu installieren. Der Server wird gehostet:
https://saveproptax.com/mcpStreamable HTTP, ohne Authentifizierung, zustandslos.
Claude: Einstellungen öffnen, dann Connectors, dann „Benutzerdefinierten Connector hinzufügen“ und die oben genannte URL einfügen.
ChatGPT: Einstellungen öffnen, dann Connectors (oder Apps), dann einen MCP-Client per URL hinzufügen, sofern Ihr Plan benutzerdefinierte Connectors unterstützt.
**Claude Code:
claude mcp add --transport http saveproptax https://saveproptax.com/mcpJeder MCP-Client: Richten Sie einen Streamable-HTTP-Transport auf die URL. Kein Token erforderlich.
Related MCP server: Property MCP Server
Werkzeug | Argumente | Beschreibung |
|
| Kostenlose Prüfung für ein Haus in Kalifornien. Gibt einen Status, die derzeitige Bewertung, eine Werteinschätzung auf Basis aktueller Vergleichsverkäufe und die geschätzten jährlichen Einsparnungen zurück. Ein qualifiziertes Ergebnis enthält einen |
|
| Erstellt das Formular des Countys und sendet den Unterzeichnungslink per E-Mail an den Eigentümer. Der Link wird niemals an den Client zurückgegeben. |
|
| Nur grober Fortschrittsstatus: |
Ein Agent kommt niemals mit der Unterschrift oder dem Geld in Berührung. Der Unterzeichnungslink geht in den Posteingang des Eigentümers. Der Eigentümer prüft das Formular des Countyunternehmen, unterschreibt es und bezahlt. Das Schlimmste, was ein anonymer Aufrufer tun kann, ist eine kostenlose Prüfung zu verbrauchen und einem echten Hauseigentümer einen legitimen Link zu seiner eigenen Immobilie zu senden.
Die gleiche Funktionalität ohne MCP, ohne Schlüssel.
curl -s https://saveproptax.com/api/agent/check \
-H 'Content-Type: application/json' \
-d '{"address": "123 Main St, Walnut Creek"}'Eine qualifizierte Antwort:
{
"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"
}Übergeben Sie dann das Token und die Daten des Eigentümers zur Vorbereitung:
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"
}'GXP6 Abfrage des Status-Endpunkts, um den Fortschritt zu verfolgen:
curl -s 'https://saveproptax.com/api/agent/status?doc=d0c1d2...'status | Bedeutung |
| Vergleichbare Verkäufe stützen einen vertretbar niedrigeren Wert, die Einsparungen übersteigen 500 $ pro Jahr und das Antragsfenster des County: ist geöffnet. Der einzige Status, der ein |
| Die Verkäufe stützen in diesem Jahr keinen Wert unterhalb der derzeitigen Bewertung. |
| Zu wenige eng passende aktuelle Verkäufe für einen vertretbaren Antrag. |
| Der County-Daten zur Immobilie weisen nicht auf Wohnzweck hin. |
| Das Antragsfenster des County: hat geschlossen; |
| Ein kalausissches County, das noch nicht abgedeckt. |
| Für dieses Grundstück wurde in diesem Jahr bereits ein Prüfungsantrag eingereicht. |
| Versuchen Sie es erneut, gibt wieder zugriff mit der Stadtangabe. |
| Die Nachricht sagt, was fehlt, z. B. eine Wohnungsnummer. |
| Hohe Auslastung: Neue Prüfungen werden kurzzeitig pausiert, zwischengespeicherte Antworten werden weiterhin ausgeliefert. Bitte kurze Zeit später erneut versuchen. |
Jede message ist eine weiterreichtbare Erklärung in einem Satz, die Sie Ihren Benutzer:innen unverändert weitergeben können.
GXP8
Gibt sofort einen Schlüssel zurück, ohne Genehmigungsschritt. Senden Sie ihn als x-agent-key-Header, um den doppelten Spielraum für neue Prüfungen und eine namentliche Zuordnung zu erhalten. Anonyme Verwendung funktioniert einwandfrei; die Registrierung stellt eine Identität dar, keine Berechtigung.
Pro-Adress-Cache, 24 Stunden: Wiederholte Prüfungen sind sofort, kosten uns nichts und werden mit cached: true markiert. Gecachte Antworten unterliegen niemals einer Ratenbegrenzung.
Stündliches Budget für neue Prüfungen: Neue Prüfungen holen echte Datensätze und Verkaufsdaten und teilen sich daher einen gemeinsamen kontrollierten Pool. Bei hoher Last antworten neue Prüfungen mit busy, während gecachte Antworten weiterhin ausgeliefert werden. Die Pipeline verschlechtert sich nie zu einer billigeren Bewertungsmethode; sie verzögert nur gelegentlich.
Beschränkung der Vorbereitung: Erfordert einen Token aus einer echten Prüfung und ist auf drei Unterzeichungslink pro Tag und pro Posteingang des Eigentümers begrenzt.
Abgedeckt sind die Counties 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 und Yolo. Die Antragefenster sind je nach Landkreis saisonal; aktuelle Fristen finden Sie unter https://saveproptax.com/counties.html.
Vollständige Referenz: https://saveproptax.com/agents
OpenAPI: https://saveproptax.com/openapi.json
llms.txt: https://saveproptax.com/llms.txt
Registry-Metadaten: server.json
Partnerschaften und Mengenvereinbarungen: support@saveproptax.com
SavePropTax erstellt Prüfungsanforderungen auf Grundlage öffentlicher Aufzeichnungen und der eigenen Formes des Landkreis; Eigentümer prüfen und unterschreiben sie. Wir sind keine Anwaltskanzlei und übernehmen keinerlei Rechts- oder Steuerberatung. Ermäßigungen werden ausschließlich vom County Assessor festgelegt.
MIT. Siehe LICENSE. Diese Lizenz gelten für die Inhalte dieses Repositories; der gehostete Dienst untersteht den Bedingungen von https://saveproptax.com/legal.html.
Der gehostete Server erfordert keine Installation. Für Stdio-only-MCP-Clients enthält dieses Repo eine nicht von Abhängigkeiten entkoppelte Brücke (Node 18+):
{
"mcpServers": {
"saveproptax": {
"command": "node",
"args": ["bridge.js"]
}
}
}Oder mit Docker: docker build -t saveproptax-mcp . && docker run -i saveproptax-mcp.
Die Einführung (Introspection) wird lokal beantwortet; Tool-Aufrufe werden an saveproptax.com/mcp weitergeleitet.
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.
| 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" |
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.
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.
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.
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.
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.
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.
Coarse progress for a filing: awaiting_signature, awaiting_payment, filed, delivered. Returns no personal information.
| Name | Required | Description | Default |
|---|---|---|---|
| docId | Yes |
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.
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.
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.
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.
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.
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 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.
| Name | Required | Description | Default |
|---|---|---|---|
| ownerName | Yes | ||
| ownerEmail | Yes | ||
| ownerPhone | Yes | ||
| continueToken | Yes |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0check_property_tax_savingsget_filing_statusstart_filingScored across 3 tools
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.
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.
Three tools is ideal for this narrow domain, covering the essential workflow (check → start → status) without redundancy or bloat. Each tool earns its place.
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.
Check any US address for property tax over-assessment: value, appeal deadline, exemptions. No login.
AI transaction coordinator + legal-matters platform for real estate and law firms.
AI title risk analysis for US real estate closing docs. Get an API key at curagent.io
Real estate data for AI agents: property lookup, comps, search, skip tracing, phone/address checks
