Un servidor MCP remoto y una API HTTP abierta para apelaciones de impuestos a la propiedad en California.
Pregúntale si una vivienda está sobrevalorada. Si ventas comparables recientes respaldan un valor más bajo, prepara el formulario de revisión por disminución de valor de la Proposición 8 del propio condado y envía por correo electrónico un enlace de firma al propietario. El propietario firma y paga una tarifa fija de 29 $. La comprobación es gratuita, sin clave, y solo puede reducir una factura de impuestos, nunca aumentarla.
No hay nada que instalar. El servidor está alojado:
https://saveproptax.com/mcpStreamable HTTP, sin autenticación, sin estado.
Claude: Ajustes, luego Conectores, luego Añadir conector personalizado, y pega la URL anterior.
ChatGPT: Ajustes, luego Conectores (o Apps), y añade un servidor MCP por URL, si tu plan admite conectores personalizados.
Claude Code:
claude mcp add --transport http saveproptax https://saveproptax.com/mcpCualquier cliente MCP: apunta un transporte streamable-HTTP a la URL. Sin token.
Related MCP server: Property MCP Server
Herramienta | Argumentos | Qué hace |
|
| Comprobación gratuita de una vivienda de California. Devuelve un estado, la valoración actual, una opinión de valor a partir de ventas comparables recientes y el ahorro anual estimado. Un resultado que cumple los requisitos lleva un |
|
| Prepara el formulario del condado y envía por correo electrónico el enlace de firma al propietario. El enlace nunca se devuelve al cliente. |
|
| Solo estado general: |
Un agente nunca gestiona la firma ni el dinero. El enlace de firma llega a la bandeja de entrada del propietario. El propietario revisa el formulario del propio condado, lo firma y paga. Lo peor que puede hacer una llamada anónima es gastar una comprobación gratuita y enviar a un propietario real un enlace legítimo a su propia propiedad.
La misma capacidad sin MCP. Sin clave.
curl -s https://saveproptax.com/api/agent/check \
-H 'Content-Type: application/json' \
-d '{"address": "123 Main St, Walnut Creek"}'Una respuesta que cumple los requisitos:
{
"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"
}Después, pasa el token y los datos del propietario para preparar:
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 }Consulta el endpoint de estado para ver el progreso:
curl -s 'https://saveproptax.com/api/agent/status?doc=d0c1d2...'estado | significado |
| Las ventas comparables respaldan un valor inferior defendible, el ahorro supera los 500 $ al año y la ventana del condado está abierta. El único estado que lleva un |
| Las ventas no respaldan un valor inferior a la valoración actual este año. |
| Demasiado pocas ventas recientes bien emparejadas para una presentación defendible. |
| El registro del condado de la parcela no es residencial. |
| La ventana de revisión del condado se ha cerrado; |
| Un condado de California aún no cubierto. |
| Ya se presentó una solicitud de revisión para esta propiedad este año. |
| Reintenta incluyendo la ciudad. |
| El mensaje indica qué falta, por ejemplo un número de unidad. |
| Carga alta: las comprobaciones nuevas se pausan brevemente, las respuestas en caché siguen sirviéndose. Reintenta en breve. |
Cada message es una explicación de una sola frase que puedes transmitir a tu usuario tal cual.
curl -s https://saveproptax.com/api/agent/register \
-H 'Content-Type: application/json' \
-d '{"agentName": "MyAssistant", "contactEmail": "dev@example.com"}'Devuelve una clave de inmediato, sin paso de aprobación. Envíala como cabecera x-agent-key para duplicar el margen de comprobaciones nuevas y obtener atribución con nombre. El uso anónimo funciona bien; el registro es identidad, no permiso.
Caché por dirección, 24 horas. Las comprobaciones repetidas son instantáneas, no nos cuestan nada y vuelven marcadas con cached: true. Las respuestas en caché nunca están sujetas a límites de tasa.
Presupuesto horario de comprobaciones nuevas. Las comprobaciones nuevas compran registros reales y datos de ventas, por lo que comparten un fondo horario. Bajo carga, las comprobaciones nuevas responden busy mientras las respuestas en caché siguen sirviéndose. El proceso nunca degrada a un método de valoración más barato; solo se retrasa.
Restricción de la preparación. Requiere un token de una comprobación real y está limitado a tres enlaces de firma por bandeja de entrada del propietario al día.
Los condados de 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 y Yolo. Las ventanas son estacionales según el condado; los plazos actuales están en https://saveproptax.com/counties.html.
Referencia completa: https://saveproptax.com/agents
OpenAPI: https://saveproptax.com/openapi.json
llms.txt: https://saveproptax.com/llms.txt
Metadatos del registro: server.json
Asociaciones y acuerdos de volumen: support@saveproptax.com
SavePropTax prepara solicitudes de revisión a partir de registros públicos y de los formularios del propio condado; los propietarios las revisan y firman. No somos un bufete de abogados y nada de esto constituye asesoramiento legal o fiscal. Las reducciones las decide únicamente el asesor fiscal del condado.
MIT. Consulta LICENSE. La licencia cubre el contenido de este repositorio; el servicio alojado se rige por los términos disponibles en https://saveproptax.com/legal.html.
El servidor alojado no necesita instalación. Para clientes MCP solo stdio, este repositorio incluye un puente sin dependencias (Node 18+):
{
"mcpServers": {
"saveproptax": {
"command": "node",
"args": ["bridge.js"]
}
}
}O con Docker: docker build -t saveproptax-mcp . && docker run -i saveproptax-mcp. La introspección se responde localmente; las llamadas a herramientas se reenvían a 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
