カリフォルニア州の固定資産税不服申立てのためのリモートMCPサーバー兼オープンHTTP API。
住宅が過大評価されていないか問い合わせることができます。直近の類似売買事例がより低い価値を裏付ける場合、カウンティ自身のProposition 8減額審査フォームを作成し、署名リンクを住宅所有者にメールで送信します。所有者が署名し、定額$29を支払います。確認は無料、キー不要で、税額を下げることしかできず、上げることは決してありません。
インストールするものは何もありません。サーバーはホスト型です：
https://saveproptax.com/mcpストリーミングHTTP、認証なし、ステートレス。
Claude: 設定、コネクタ、カスタムコネクタの追加の順に進み、上記のURLを貼り付けます。
ChatGPT: 設定、コネクタ（またはアプリ）の順に進み、プランがカスタムコネクタに対応している場合は、URLでMCPサーバーを追加します。
Claude Code:
claude mcp add --transport http saveproptax https://saveproptax.com/mcp任意のMCPクライアント: ストリーミングHTTPトランスポートをURLに向けます。トークンは不要です。
Related MCP server: Property MCP Server
ツール | 引数 | 機能 |
|
| カリフォルニアの住宅1件を無料で確認します。ステータス、現在の査定額、直近の類似売買事例に基づく価値の見解、推定年間節約額を返します。条件を満たす結果には |
|
| カウンティのフォームを作成し、署名リンクを所有者にメールで送信します。リンクがクライアントに返されることはありません。 |
|
| 大まかなステータスのみ： |
エージェントが署名や金銭を扱うことは決してありません。 署名リンクは所有者の受信トレイに届きます。所有者はカウンティ自身のフォームを確認し、署名し、支払います。匿名の呼び出し元ができる最悪のことは、無料の確認を使い、実際の住宅所有者に自分の物件への正当なリンクを送ることだけです。
MCPを使わずに同じ機能を利用できます。キー不要です。
curl -s https://saveproptax.com/api/agent/check \
-H 'Content-Type: application/json' \
-d '{"address": "123 Main St, Walnut Creek"}'条件を満たすレスポンス：
{
"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"
}次に、トークンと所有者の詳細を提出準備に渡します：
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 }ステータスエンドポイントをポーリングして進捗を確認します：
curl -s 'https://saveproptax.com/api/agent/status?doc=d0c1d2...'ステータス | 意味 |
| 類似売買事例が防御可能な低い価値を裏付けており、節約額が年間$500を超え、カウンティの受付期間が開いています。 |
| 売買事例が今年の現在の査定額を下回る価値を裏付けていません。 |
| 防御可能な申請のための直近の類似売買事例が少なすぎます。 |
| 区画のカウンティ記録が住宅用ではありません。 |
| カウンティの受付期間が終了しました。 |
| まだ対応していないカリフォルニア州のカウンティです。 |
| この物件に対する減額審査請求が今年すでに提出されています。 |
| 市区町村を含めて再試行してください。 |
| メッセージに不足している内容（例：部屋番号）が示されます。 |
| 高負荷時：新規確認は一時停止されますが、キャッシュ済みの回答は引き続き提供されます。しばらくして再試行してください。 |
すべてのmessageは、そのままユーザーに伝えられる一文の説明文です。
curl -s https://saveproptax.com/api/agent/register \
-H 'Content-Type: application/json' \
-d '{"agentName": "MyAssistant", "contactEmail": "dev@example.com"}'承認手順なしで即座にキーが返されます。x-agent-keyヘッダーとして送信すると、新規確認の上限が2倍になり、名前付きの帰属が付与されます。匿名での利用も問題なく機能します。登録は身元確認であり、許可ではありません。
住所ごとのキャッシュ、24時間。 繰り返しの確認は即座に完了し、コストはかからず、cached: trueとして返されます。キャッシュ済みの回答にレート制限はありません。
1時間ごとの新規確認予算。 新規確認は実際の記録と売買データを購入するため、1時間ごとの共通プールを共有します。高負荷時、新規確認はbusyを返しますが、キャッシュ済みの回答は引き続き提供されます。パイプラインがより安価な評価方法に劣化することはなく、遅延するだけです。
提出のゲーティング。 実際の確認からのトークンが必要で、所有者の受信トレイ1つにつき1日3件までの署名リンクに制限されています。
アラメダ、コントラコスタ、ロサンゼルス、マリン、ナパ、プレイサー、リバーサイド、サクラメント、サンベニート、サンバーナーディーノ、サンフランシスコ、サンホアキン、サンマテオ、サンタクララ、サンタクルーズ、ソラノ、サッター、ヨロの各カウンティ。受付期間はカウンティごとに季節変動します。現在の締切はhttps://saveproptax.com/counties.htmlをご覧ください。
完全なリファレンス：https://saveproptax.com/agents
llms.txt：https://saveproptax.com/llms.txt
レジストリメタデータ：server.json
パートナーシップおよびボリューム契約：support@saveproptax.com
SavePropTaxは公的記録とカウンティ自身のフォームから減額審査請求を作成します。所有者が確認し署名します。当社は法律事務所ではなく、ここにあるものは法的助言や税務助言ではありません。減額はカウンティ査定官のみが決定します。
MIT。LICENSEをご覧ください。ライセンスはこのリポジトリの内容を対象とします。ホスト型サービスはhttps://saveproptax.com/legal.htmlの規約に従います。
ホスト型サーバーにはインストールは不要です。stdioのみのMCPクライアント向けに、このリポジトリには依存関係のないブリッジ（Node 18以上）が同梱されています：
{
"mcpServers": {
"saveproptax": {
"command": "node",
"args": ["bridge.js"]
}
}
}またはDockerで：docker build -t saveproptax-mcp . && docker run -i saveproptax-mcp。イントロスペクションはローカルで応答され、ツール呼び出しはsaveproptax.com/mcpに転送されます。
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
