carsensor 价格区间 MCP 服务器（面向 AI 智能体）

如果你正在构建一个 AI 智能体、聊天机器人或应用，需要回答"这辆二手车的要价是否合理？"——不是猜测，而是基于真实市场数据的数字——这个 MCP 服务器只需一次工具调用就能给你精确答案。resolvePriceRange(carModel, year) 返回一个市场价格区间（最低价 / 最高价 / 中位数），实时根据 carsensor.net 官方按车型年份发布的市场统计数据计算得出——正是 carsensor 自己在 相場（市场价格）页面上发布的数据，被转化为结构化、可直接使用的数字，而不是需要你自己阅读和解读的页面。

你将获得：

• 一个工具 resolvePriceRange，只需输入车型名称和年份——无需为底层数据源管理 API 密钥，也无需自己解析 HTML

• priceRangeYen: { min, max, median } 以及 sampleSize（估算所基于的真实 carsensor 列表数量）和 confidence（normal / low——当年份无法完全对照 carsensor 自身数据验证时，会如实降级而非隐藏；参见"已知限制"）

• 通过 Apify Standby 模式实现常驻托管——无需自己运行服务器。可将任何 MCP 客户端（Claude Desktop、Claude Code、你自己的智能体）直接连接到稳定的 HTTPS 端点，或从你自己的应用代码中将其作为普通 Streamable HTTP MCP 服务器调用

{
  "ok": true,
  "carModel": "プリウス",
  "year": 2018,
  "priceRangeYen": { "min": 750000, "max": 4772500, "median": 1573112 },
  "sampleSize": 412,
  "confidence": "normal",
  "disclaimer": "carsensor.net上の公開情報(相場ページの価格×年式集計)を基にした参考値です。個体差・装備差・実際の商談結果は反映されません。"
}

按事件计费——参见下文"定价"。完整的输入/输出详情、设置和技术设计见本页下方。

⚠️ 免责声明（请阅读）

• 本 Actor 自动检索 carsensor.net 上公开可用的信息。你需自行负责如何检索和使用这些数据。

• 网站所有者的使用条款、robots.txt 或访问限制可能随时变更，这可能导致本 Actor 停止工作或输出意外变化。

• priceRangeYen 是基于 carsensor 自身发布的"价格×车型年份"汇总数据得出的统计估算，不保证任何单台车辆的真实价值。 它不考虑车况、配置/等级差异或行驶里程（参见"已知限制"）。在基于此数据做出任何购买或出售决定之前，请务必在 carsensor.net 上核实具体车辆的价格。

Related MCP server: japan-market-mcp

适用对象

• AI 智能体和聊天机器人——需要将"这辆车实际值多少钱？"的答案建立在真实市场数据之上，而不是模型自身（往往过时或幻觉的）二手车定价知识

• 应用/工具开发者——正在构建购车、估值或置换估价功能，希望直接使用现成的价格区间查询，而不是自己抓取和维护 carsensor.net 集成

• 任何希望以普通 MCP 工具调用而非批量抓取方式使用此功能的人——本 Actor 是我们面向批处理的 carsensor-resale-value-scout Actor（对整批列表基于同一底层市场数据进行评分）的单工具、按需调用对应版本

它不能做什么（集成前请阅读）

• 行驶里程尚不支持作为输入。 仅使用车型和年份——价格区间反映的是 carsensor 自身的车型年份汇总数据，而非里程调整后的估算。未来版本可能增加此功能。

• 对于不熟悉的车型，车型名称解析偶尔可能失败或首次使用较慢——原因参见"已知限制"，以及缓存如何在首次调用后缓解此问题。

• 这是统计估算，而非评估报告。 参见上方免责声明。

输入 / 输出

输入（MCP 工具调用参数）：

输出（成功）：

输出（未找到车型 / 该年份无数据）：{ "ok": false, "reason": "no_code_resolved" | "no_matching_data", "message": "..." }——不收费（参见"定价"）。

使用示例

Claude Desktop / 任何 MCP 客户端配置：

{
  "mcpServers": {
    "carsensor-price-range": {
      "url": "https://woolen-snake--carsensor-price-range-mcp.apify.actor/mcp",
      "headers": { "Authorization": "Bearer YOUR_APIFY_TOKEN" }
    }
  }
}

从你自己的应用直接调用（Node.js，@modelcontextprotocol/sdk）：

import { Client } from '@modelcontextprotocol/sdk/client/index.js';
import { StreamableHTTPClientTransport } from '@modelcontextprotocol/sdk/client/streamableHttp.js';

const transport = new StreamableHTTPClientTransport(
  new URL('https://woolen-snake--carsensor-price-range-mcp.apify.actor/mcp'),
  { requestInit: { headers: { Authorization: `Bearer ${process.env.APIFY_TOKEN}` } } },
);
const client = new Client({ name: 'my-app', version: '1.0.0' });
await client.connect(transport);

const result = await client.callTool({
  name: 'resolvePriceRange',
  arguments: { carModel: 'プリウス', year: 2018 },
});
console.log(JSON.parse(result.content[0].text));

定价

无论调用是命中缓存数据还是触发对 carsensor.net 的新请求，均为统一价格——完整理由参见下文"定价依据"，包括为何有意拒绝按缓存层级定价。

定价依据

$0.03 介于本 Actor 家族的基础分类层级（$0.015，例如我们 carsensor-resale-value-scout Actor 上的 listing-extracted）和更重的派生信号层级（$0.045–$0.065，例如 value-score-computed）之间——反映价格区间是计算得出的市场信号而非原始数据获取，同时此工具的底层基础设施成本（每次调用远低于 $0.001，且大多数调用由缓存服务）无论哪种方式都留有较大利润空间。

为何缓存命中与未命中定价相同：交付的价值——priceRangeYen、sampleSize、confidence——在两种情况下完全相同；缓存纯粹是内部性能/成本优化，并非你所获内容的差异。若区别定价，还会产生缩短缓存 TTL 的逆向激励（更多未命中 = 更多收入），这直接违背本工具自身"最小化 carsensor.net 负载"的设计目标。

数据来源与计算

使用 carsensor.net 自身公开发布的所解析车型的 相場（市场价格）页面（/usedcar/souba/{makerCode}_S{modelCode}/），具体为其"价格×车型年份"交叉表（价格区间、年份区间、每格列表数量）——这是 carsensor 根据自身实时库存计算出的官方汇总数据，而非第三方估算。

• median 是每个匹配年份区间价格区间中点的按数量加权平均值

• min / max 来自匹配单元格的实际价格区间边界（开放式区间，例如"¥4,150,000 或以上"，使用 ±15% 启发式近似——这是经验性调整，而非统计推导）

• 这是等级级汇总数据（例如所有丰田普锐斯配置合并），而非单条列表定价——不考虑配置/等级差异、装备或车况

缓存（2 层）

两层均缓存命中意味着该调用对 carsensor.net 的 HTTP 请求数为零。在 Apify 托管版本上，此缓存限定于单个 Standby 运行/容器实例——并发会话可能落在具有独立缓存的不同容器实例上，因此托管版本的实际命中率可能低于单个长期运行的本地进程。如果未来实践中发现这确实重要，可能会将此迁移到 Apify 的 Key-Value Store（跨运行共享）。

访问间隔与日志记录

对 carsensor.net 的请求以最小 1000ms 间隔（默认 1500ms）进行限速，作为负载降低措施——与我们 carsensor-resale-value-scout Actor 使用的下限相同。每次调用都会记录日志（车型、年份、各层缓存命中/未命中、实际发出的 HTTP 请求、响应时间、结果），用于未来监控——不向调用方公开，仅用于负责任地运营本 Actor。

常见问题

为什么 confidence 有时为 "low"？ carsensor 自身数据中的年份轴有一个开放式的底部区间（例如"2012 年或更早"）。任何在该边界或更早的年份都会匹配它，无论该车型当年是否实际存在——仅凭此数据无法完全验证合理性，因此 confidence 被如实降级而非报告为确定。此类响应的 note 字段会说明具体原因。

为什么某个车型的首次调用需要几秒钟，而重复调用快得多？ 对于不熟悉的车型，首次调用需要最多 3 次对 carsensor.net 的真实请求（搜索 → 详情页 → 市场价格页）来解析这是哪个车型。解析完成后，车型→代码映射被近乎永久缓存，价格数据本身缓存 12 小时——因此同一车型的重复调用几乎是即时的。

是否涵盖行驶里程？ 尚未涵盖——参见"它不能做什么"。

这与 carsensor-resale-value-scout 有何不同？ 该 Actor 是批量抓取器：给它一个搜索词，返回一份实时列表，每条都基于同一市场数据评分。本 Actor 是单次调用、按需的对应版本，专为希望获得单个车型/年份的单一数字——而非需要抓取和处理的列表——的 AI 智能体和应用而构建。

已知限制

• 型号名称解析没有直接查找——它通过 carsensor 自身的自由词搜索进行，并读取匹配列表页面来识别型号。 对于真正无法识别的型号（拼写错误、不存在的型号），carsensor 的搜索结果页面仍会包含一个"你可能还喜欢"的组件，其中展示不相关的汽车；此 Actor 会明确检测并排除该组件，以免被误认为真实匹配——已通过实时测试确认。

• confidence 无法完全验证查询的年份对于给定型号是否合理——参见 FAQ。

• 这是等级级别的聚合值，而非单个列表的价格——参见"数据来源与计算"。

• 基于文件的缓存是托管版（Apify Standby）中每个容器独立的——参见"缓存"。

• 此工具底层的抓取逻辑是刻意从 carsensor-resale-value-scout 的代码库复制而来，而非导入，以保持两个独立部署的 Actor 解耦。carsensor.net 的标记变更若影响其中一个，可能需要对另一个进行相应的修复。

• 未在 Smithery 上列出：Apify Standby 的认证响应不符合 OAuth 发现规范，这会在到达此服务器自身的基于配置的认证之前就中断 Smithery 的自动连接扫描——目前暂无计划中的解决方案。

可能的未来扩展（本版本未实现）

• 将里程作为第三个输入，使用 carsensor 的价格×里程矩阵（已确认可获取，尚未接入）

• 将缓存迁移到 Apify 的 Key-Value Store，以便在 Standby 容器实例之间共享

• 在 Apify Store 之外的其他 MCP 目录中上架