Удалённый MCP-сервер и открытый HTTP API для апелляций по налогу на недвижимость в Калифорнии.
Спросите его, завышена ли оценка дома. Если недавние сопоставимые продажи подтверждают более низкую стоимость, он готовит форму округа для пересмотра в связи со снижением стоимости (Proposition 8) и отправляет владельцу ссылку для подписания по электронной почте. Владелец подписывает и платит фиксированные $29. Проверка бесплатна, не требует ключа и может только снизить налоговый счёт, но никогда не повысить его.
Устанавливать ничего не нужно. Сервер размещён:
https://saveproptax.com/mcpStreamable HTTP, без аутентификации, без сохранения состояния.
Claude: Настройки, затем Connectors, затем Add custom connector, и вставьте указанный выше URL.
ChatGPT: Настройки, затем Connectors (или Apps), затем добавьте MCP-сервер по URL, если ваш тариф поддерживает пользовательские коннекторы.
Claude Code:
claude mcp add --transport http saveproptax https://saveproptax.com/mcpЛюбой MCP-клиент: укажите transport streamable-HTTP на этот URL. Токен не нужен.
Related MCP server: Real Estate MCP Server
Инструмент | Аргументы | Что делает |
|
| Бесплатная проверка одного калифорнийского дома. Возвращает статус, текущую оценку, мнение о стоимости на основе недавних сопоставимых продаж и предполагаемую годовую экономию. При положительном результате возвращается |
|
| Подготавливает форму округа и отправляет ссылку для подписания владельцу по электронной почте. Ссылка никогда не возвращается клиенту. |
|
| Только общий статус: |
Агент никогда не обрабатывает подпись или деньги. Ссылка для подписания приходит на почту владельца. Владелец просматривает форму округа, подписывает её и оплачивает. Худшее, что может сделать анонимный вызывающий, — потратить бесплатную проверку и отправить реальному владельцу легитимную ссылку на его собственную недвижимость.
Та же возможность без 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 для удвоенного лимита свежих проверок и именованной атрибуции. Анонимное использование работает нормально; регистрация — это идентификация, а не разрешение.
Кэш по адресу, 24 часа. Повторные проверки мгновенны, ничего нам не стоят и возвращаются с пометкой cached: true. Кэшированные ответы никогда не ограничиваются.
Почасовая квота свежих проверок. Свежие проверки покупают реальные записи и данные о продажах, поэтому они используют общий почасовой пул. При нагрузке свежие проверки отвечают busy, а кэшированные ответы продолжают работать. Конвейер никогда не деградирует до более дешёвого метода оценки; он только задерживается.
Ограничение подготовки. Требуется токен от реальной проверки, и ограничено тремя ссылками для подписания на один почтовый ящик владельца в день.
Округа Аламеда, Контра-Коста, Лос-Анджелес, Марин, Напа, Плейсер, Риверсайд, Сакраменто, Сан-Бенито, Сан-Бернардино, Сан-Франциско, Сан-Хоакин, Сан-Матео, Санта-Клара, Санта-Круз, Солано, Саттер и Йоло. Окна сезонные для каждого округа; текущие сроки на https://saveproptax.com/counties.html.
Полная документация: https://saveproptax.com/agents
OpenAPI: https://saveproptax.com/openapi.json
llms.txt: https://saveproptax.com/llms.txt
Метаданные реестра: server.json
Партнёрства и объёмные соглашения: support@saveproptax.com
SavePropTax готовит запросы на пересмотр на основе публичных записей и собственных форм округа; владельцы просматривают и подписывают их. Мы не юридическая фирма, и ничто здесь не является юридической или налоговой консультацией. Снижение определяется исключительно окружным оценщиком.
MIT. См. LICENSE. Лицензия покрывает содержимое этого репозитория; размещённый сервис регулируется условиями на https://saveproptax.com/legal.html.
Размещённому серверу не требуется установка. Для MCP-клиентов, поддерживающих только stdio, в этом репозитории есть мост без зависимостей (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.
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
Deal intelligence for agents: SEC-verified financials, validation, institutional deal scoring.
Flat-rate US property/parcel search & CSV export for AI agents via MCP.
