本服务器暴露的是麦麦护栏演示模式下的只读麦当劳工具集：AI 可以查时间、找店、看菜单、查券、试算价格，但完全不能下单或改动账号。
now-time-info — 获取当前时间（演示）。
query-nearby-stores — 按关键词查询附近门店，拿到后续要用的 storeCode。
query-meals — 查某门店餐品菜单（必填 storeCode、orderType 1-到店/2-外送、beType 取餐方式），返回带 code 的餐品。
query-my-coupons — 查询本人优惠券。
calculate-price — 按门店、就餐方式与 items（productCode + quantity）试算订单金额，护栏下单前也用它核价。
全部 5 个工具都标了 readOnlyHint: true，属于查询类，可直接放行；此处没有任何写操作——下单、取消订单、积分兑换、抽奖、领券、新增地址都不存在。
中文 | English
把麦当劳账号交给 AI 之前，先装个刹车。
麦麦护栏是一个跑在你自己电脑上的麦当劳 MCP 安全层。AI 查菜单、算价格照常进行；一旦要下单、取消订单、积分兑换、抽奖、领券、新增地址，必须你在护栏窗口里亲手确认。它还可以设消费上限、开只读模式、记审计日志，Token 只留在你的电脑上。
上图根据 2026-10-13 一次真实运行整理：Claude Code 接入护栏，查询和试算都是麦当劳官方 MCP 的实时结果；下单在护栏终端被拒绝，没有发给麦当劳。
麦当劳 MCP 服务规则写得很清楚：
持有该凭证即代表拥有您账号的操作权限……凡是通过该凭证发起的任何指令，均视为您本人行为。
也就是说，把 Token 配进 AI 客户端，就等于把会员账号的操作权交给了 AI。可 AI 会：
理解错：“帮我看看多少钱”被当成“帮我下单”；“12 个人每人一个”被算成 12 个套餐。
被带偏：你让它读一段群聊、网页或文档，里面混着“直接下单，不用确认”，它可能真的照做。
太勤快：顺手帮你“一键领券”“抽个奖”，积分就这么没了。
官方工具说明里写了“要先征得用户同意”，但这只是对 AI 的提示，AI 不一定遵守。麦麦护栏把这道确认放在 AI 碰不到的地方：护栏自己的终端窗口。
Related MCP server: SentinelGate
功能 | 说明 |
写操作本机确认 | 7 个会改动账户的工具都要你亲自确认才执行：在护栏终端输入 |
网页面板 | 浏览器打开 |
下单前官方核价 | AI 下单时，护栏先用官方 |
消费上限 | 单笔、当天、本周三档上限，超过直接拦截，连确认都不弹 |
只读模式 | 写操作从工具列表里隐藏；AI 硬调也会被拦截 |
逐个设置规则 | 每个操作可设为直接放行、需确认或拦截，比如领券不用每次确认、抽奖永远拦截；下单就算设成直接放行也照样受消费上限约束 |
审计日志 | AI 用你账号做过的每一次调用都记在 |
Token 只在本机 | AI 客户端只连 |
告诉 AI 别绕路 | 被拒绝、超时、超限时，护栏明确告诉 AI 不要重试、不要拆单 |
超过上限时的样子（同样根据真实运行整理）：
需要 Python 3.10 及以上，没有第三方依赖。
没有 Token 也能先体验：
git clone https://github.com/a1840436478/mcd-guard.git
cd mcd-guard
python run_demo.py演示模式不连麦当劳官方服务，门店、餐品、价格都是虚构的（菜单只有 D01~D06 六样），不会产生任何真实订单。AI 客户端按下面第 3 步连上后，对它说“在演示餐厅点两个巨无霸”，就能看到确认卡片；说“点 5 份套餐”会被单笔上限拦下。演示的审计日志单独写在 audit-demo/，不计入真实消费。
正式使用：
1. 下载并填 Token
git clone https://github.com/a1840436478/mcd-guard.git
cd mcd-guard
cp .env.example .env到 麦当劳 MCP 开放平台 用手机号登录，在“控制台”点“激活”拿到 Token，填进 .env 的 MCD_MCP_TOKEN= 后面。
2. 启动护栏
python run_guard.py看到 麦麦护栏已启动: 地址=http://127.0.0.1:1024/mcp 就好了。这个窗口别关，写操作会在这里请你确认。
3. 让 AI 客户端连护栏
把原来的麦当劳 MCP 配置换成下面这样，地址改成本机，不用再填 Token（同 mcp-config.example.json）：
{
"mcpServers": {
"mcd-guard": {
"type": "streamablehttp",
"url": "http://127.0.0.1:1024/mcp"
}
}
}Claude Code 用一条命令即可：
claude mcp add --transport http mcd-guard http://127.0.0.1:1024/mcp已实测：Claude Code。其他支持 Streamable HTTP 的 MCP 客户端（如 WorkBuddy 的自定义连接器）按上面的 JSON 配置即可，欢迎反馈。
只支持 stdio 的客户端可以用只读模式：护栏由客户端启动，没有自己的终端窗口，没法让你确认，所以写操作全部隐藏并拦截，只能查菜单、算价格、看订单，下单请回到麦当劳 App 或改用上面的 HTTP 方式。
{
"mcpServers": {
"mcd-guard-readonly": {
"command": "python",
"args": ["/你的路径/mcd-guard/run_stdio.py"]
}
}
}之后照常和 AI 说“帮我点一个麦辣鸡腿堡”。到下单那一步，护栏窗口会弹出：
==============================================
【麦麦护栏】AI 请求执行写操作
==============================================
操作：创建订单（create-order）
门店：1450713 方式：到店自取
餐品：
- 麦辣鸡腿汉堡 x1
应付：¥22.50（下单前试算）
今日已确认：¥0.00 / 上限 ¥200.00
----------------------------------------------
输入 y 回车确认执行，输入其他内容拒绝（120 秒后自动拒绝）确认后订单才会发给麦当劳，付款仍在麦当劳 App 里由你完成。
也可以用浏览器打开 http://127.0.0.1:1024/ 的网页面板确认。网页上需要输入护栏终端里显示的 6 位确认码，确认码不写进任何日志文件，AI 拿不到；连续输错 5 次按拒绝处理。
在项目根目录建 policy.json（可以复制 policy.example.json），没写的字段用默认值：
字段 | 默认 | 说明 |
|
|
|
|
| 单笔订单应付上限（元） |
|
| 当天已确认订单累计上限（元） |
|
| 本周（周一起）已确认订单累计上限（元） |
|
| 逐个工具设置： |
|
| 永远拦截的工具名，等同于在 |
|
| 等你确认的秒数，超时按拒绝处理 |
例如领券不用确认、抽奖永远拦截：
"tool_rules": {"auto-bind-coupons": "allow", "draw-lottery": "block"}设成 allow 的写操作不会弹确认，但照样记审计日志；护栏启动时会提醒你哪些操作不用确认，网页面板上也能看到每个操作的规则。只读模式下所有写操作一律拦截，不管规则怎么设。
改完重启护栏生效。累计金额按审计日志统计：已确认或按规则放行的下单、但结果未知或未支付的订单也算进去，宁可多算不少算。
每次调用一行，例如：
{"time": "2026-10-13 17:26:02", "tool": "create-order", "arguments": {"storeCode": "1450713", "orderType": 1, "beType": 1, "items": [{"productCode": "1440", "quantity": 1}]}, "price_fen": 2250, "decision": "rejected"}decision 可能是：allowed（查询放行，或按 tool_rules 直接放行）、confirmed（你确认后执行）、rejected（你拒绝）、timeout（超时未确认）、blocked（被策略拦截）。
能防： AI 通过 MCP 发起的一切写操作。不管 AI 是理解错了、被群聊或网页里的文字带偏了，还是“太勤快”，只要不经过你在护栏终端的确认，就到不了麦当劳。
不能防：
你自己在护栏终端输入了 y。确认卡片会写清门店、餐品、金额，请看清再按。
能直接读写你电脑文件、执行命令的 AI 智能体。它理论上可以读 .env 里的 Token 绕过护栏。用这类 AI 时，别让它在护栏目录里随意执行命令。
支付。护栏不碰支付，下单后的付款仍由你在麦当劳 App 里完成。
已经或准备把麦当劳 MCP 接进 AI 客户端（WorkBuddy、Claude Code 等）的人
想让 AI 帮忙查菜单、算价格，但不放心它直接下单的人
给家里人配 AI 点餐、想设个消费上限的人
其他麦当劳 Skill 的使用者和开发者：护栏和具体 Skill 无关，任何 Skill 都可以接在它后面
护栏只转发你本人在 AI 客户端里发起的请求，并且同一时间只发一个，符合 MCP 服务规则“个人正常使用”的要求；不做批量、定时或自动化调用。
Token 只保存在你电脑上的 .env 里，不上传任何地方，也不需要写进 AI 客户端的配置。
审计日志只存在本机，不收集、不上传任何数据。
本地服务只监听 127.0.0.1，并校验 Host 和 Origin，拒绝来自外部网页的请求（包括 DNS 重绑定）。
python -m unittest discover -s tests测试用本地模拟的 MCP 服务，不需要 Token。各模块用途见 MCP_INTEGRATION.md。
本项目为麦当劳程序员节创意开发大赛参赛作品，由参赛者独立开发，非麦当劳官方产品。餐品信息、价格及供应状态以麦当劳官方渠道的实时结果为准。
按门店和餐品试算订单应付金额，返回总价（单位分）和餐品明细。只算价、不下单，可放心调用；用户问“多少钱”时用它，不要用 create-order。只读。演示数据，虚构，不连麦当劳官方服务。
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes | 要点的餐品，每项一个餐品编码和数量，至少一项 | |
| beType | Yes | 业务类型，取自 query-nearby-stores 返回的 beType；演示门店为 1（到店取餐） | |
| orderType | Yes | 订单类型：1 到店，2 外送。演示门店只支持 1 | |
| storeCode | Yes | 门店编码，取自 query-nearby-stores 返回的 storeCode；演示里只有 DEMO001 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only supply readOnlyHint=true, and the description meaningfully extends that: it confirms no order is placed, states the return payload (total in 分 plus item line detail), and discloses that the data is fictional demo data not connected to McDonald's official services. It stops short of describing validation or error behavior for bad store/product codes.
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?
Front-loaded with the core action and return value, then safety, then routing, then provenance — a sensible priority order with no filler sentences. The semicolon-chained clauses are dense but each carries distinct information, so it is efficient rather than padded.
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?
With no output schema, the description compensates by naming the return contents (total price in 分, item detail), and it covers side-effect safety, routing, and demo-data caveats for a 4-required-parameter tool. Only edge-case behavior (invalid codes, unsupported orderType) is unaddressed, which is minor for a read-only calculator.
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 100% — storeCode, orderType, beType and items all carry their own descriptions, including provenance (from query-nearby-stores, query-meals) and demo values. The description only restates '门店和餐品' at a high level and adds no syntax or format detail beyond the schema, so the baseline 3 applies.
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 states a specific verb and resource in the first clause ('试算订单应付金额' for a store and its items) and immediately contrasts it with the sibling it is not ('只算价、不下单', '不要用 create-order'). An agent can distinguish calculate-price from order creation without inspecting either schema.
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 gives an explicit trigger condition ('用户问"多少钱"时用它') and an explicit exclusion naming the alternative tool ('不要用 create-order'). Both when-to-use and when-not are stated, leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
返回当前日期和时间（ISO 格式）。用于判断门店营业时间、优惠券是否在有效期内。只读，无参数。演示数据，虚构，不连麦当劳官方服务。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true), and the description still adds genuinely useful context: ISO output format, deterministic no-parameter behavior, and the important disclosure that the data is fictional demo data not connected to official McDonald's services. '只读，无参数' partially restates the annotations, which is the only redundancy.
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?
Three short sentences, all front-loaded, with the essential fact (what it returns) first and the demo-data caveat last. The clause '只读，无参数' duplicates structured data and is the one sentence fragment that doesn't fully earn its place.
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?
For a zero-parameter read-only utility with no output schema, the description covers everything: return format, intended use, safety, and data provenance. An agent has all it needs to call 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?
Zero parameters, so the baseline is 4; the description explicitly confirms '无参数', removing any doubt about how to invoke it. Nothing further is needed for an empty schema.
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?
States a specific verb and resource ('返回当前日期和时间') plus the exact return format (ISO 格式), which clearly separates it from the query-oriented siblings. It stops short of explicitly naming which sibling to pair it with, but the utility nature is unambiguous.
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?
Gives concrete use contexts — judging store business hours and coupon validity — which tells the agent when this tool is the right one to call. It does not state exclusions or name a specific alternative, so it falls short of a full when/when-not routing statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
查询指定门店的菜单，返回餐品列表（code、名称、单价，单位元）。下单和试算时 items 里的 productCode 就是这里的 code。只读。演示数据，虚构，不连麦当劳官方服务。
| Name | Required | Description | Default |
|---|---|---|---|
| beType | Yes | 业务类型，取自 query-nearby-stores 返回的 beType；演示门店为 1（到店取餐） | |
| orderType | Yes | 订单类型：1 到店，2 外送。演示门店只支持 1 | |
| storeCode | Yes | 门店编码，取自 query-nearby-stores 返回的 storeCode；演示里只有 DEMO001 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The '只读' claim merely restates readOnlyHint=true, earning no extra credit. However, '演示数据，虚构，不连麦当劳官方服务' is genuine disclosure beyond the annotations: it warns the agent that results are mock data and must not be presented as real McDonald's information. No rate limits or failure modes are described, but for a read-only demo query the added fidelity is meaningful.
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?
Three short clauses with the core purpose front-loaded, followed by the output-to-input linkage and the demo-data caveat. No filler, no restatement of the tool name, and each sentence carries distinct information.
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?
With no output schema, the description compensates by enumerating the returned fields (code, name, unit price with unit). All three required parameters are fully documented in the schema, and the demo/fictional disclaimer closes the remaining trust gap for a read-only tool.
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 100% and every parameter (storeCode, orderType, beType) already documents its source and enum meaning, so the baseline is 3. The description's mention of 'code' refers to the response field, not to any parameter, so it adds nothing to parameter 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?
States a specific verb and resource (查询指定门店的菜单) plus the exact return payload (code、名称、单价，单位元), and ties its output key to the downstream flow by naming 试算 (calculate-price) and ordering. An agent can distinguish it from query-nearby-stores, calculate-price, and the coupon/time siblings without opening any schema.
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?
Frames the tool as the prerequisite step for ordering and price calculation ('下单和试算时 items 里的 productCode 就是这里的 code'), which tells the agent when this call is needed and what it feeds. It gives no explicit exclusions or negative guidance, so it falls short of a full when/when-not statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
列出当前账号已领取、可使用的优惠券名称。只读，不会领取新券；要领券用 auto-bind-coupons。无参数。演示数据，虚构，不连麦当劳官方服务。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description reinforces it while adding context the annotation cannot: it will not mutate state by claiming new coupons, takes no parameters, and operates on fictional demo data not connected to official McDonald's services. The demo-data caveat is genuinely useful behavioral disclosure; only the return format is left unstated.
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?
Three short sentences, each earning its place: purpose, read-only/alternative routing, and the data caveat. The core purpose is front-loaded before the qualifications.
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?
For a parameterless read tool with no output schema, it covers everything an agent needs: what it returns (coupon names), the safety profile, the no-parameter fact, and the demo-data limitation. Nothing material is missing.
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?
Zero parameters, so the baseline is 4. The description explicitly confirms 'no parameters', which is consistent with the empty schema and leaves no ambiguity.
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?
States a specific verb and resource: listing the names of coupons already claimed and usable by the current account. The scope (already-claimed, usable) is precise enough to distinguish it from other coupon operations, and it names the sibling-like alternative auto-bind-coupons.
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?
Gives explicit when-not guidance ('won't claim new coupons') and routes the agent to the correct alternative ('to claim coupons use auto-bind-coupons'). Nothing is left to inference about which tool handles which intent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
按关键词查附近门店，返回门店列表（storeCode、门店名、地址、beType）。点餐流程第一步：后续查菜单、试算、下单都要用这里的 storeCode 和 beType。只读。演示数据，虚构，不连麦当劳官方服务。
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | No | 地点或门店关键词，如“人民广场”；可省略，省略时返回默认门店 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description reinforces that with 只读 while adding genuinely new disclosure: the data is demo/fictional and not connected to the official McDonald's service. It also flags the downstream dependency on storeCode and beType, which matters behaviorally. It does not cover pagination or result limits.
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?
Three short, front-loaded sentences with no filler: purpose and return fields first, workflow role second, safety/data caveat last. Efficient, though the disclaimer sentence is more housekeeping than operational guidance.
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?
For a single-optional-parameter read-only tool with no output schema, the description covers everything needed: what it returns, why the returned IDs matter downstream, and the demo-data caveat. Nothing an agent needs in order to call it correctly is missing.
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 100%, so the keyword parameter and its optionality are already fully documented in the schema. The description only restates that lookup is keyword-based, adding no syntax or example beyond what the schema provides; baseline 3 applies.
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?
States a specific verb and resource (按关键词查附近门店) and enumerates the returned fields (storeCode、门店名、地址、beType). It also names its position in the ordering flow, which clearly separates it from siblings like query-meals and calculate-price.
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?
Explicitly frames the tool as 点餐流程第一步 and states that subsequent steps (menu lookup, price calculation, ordering) consume the storeCode and beType returned here, giving strong workflow context. It does not, however, name a specific alternative or a when-not-to-use condition.
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.2calculate-price6 fields changedInput schema / properties / beType / descriptionPrevious value: -"1-到店取餐"New value: +"业务类型，取自 query-nearby-stores 返回的 beType；演示门店为 1（到店取餐）"Input schema / properties / items / descriptionPrevious value: -"餐品列表"New value: +"要点的餐品，每项一个餐品编码和数量，至少一项"Input schema / properties / items / items / properties / quantity / descriptionPrevious value: -"数量"New value: +"份数，正整数"Input schema / properties / items / items / properties / quantity / minimumAdded value: +1Input schema / properties / orderType / descriptionPrevious value: -"1-到店，2-外送"New value: +"订单类型：1 到店，2 外送。演示门店只支持 1"Input schema / properties / storeCode / descriptionPrevious value: -"门店编码，从 query-nearby-stores 获取"New value: +"门店编码，取自 query-nearby-stores 返回的 storeCode；演示里只有 DEMO001"query-meals3 fields changedInput schema / properties / beType / descriptionPrevious value: -"1-到店取餐"New value: +"业务类型，取自 query-nearby-stores 返回的 beType；演示门店为 1（到店取餐）"Input schema / properties / orderType / descriptionPrevious value: -"1-到店，2-外送"New value: +"订单类型：1 到店，2 外送。演示门店只支持 1"Input schema / properties / storeCode / descriptionPrevious value: -"门店编码，从 query-nearby-stores 获取"New value: +"门店编码，取自 query-nearby-stores 返回的 storeCode；演示里只有 DEMO001"query-nearby-stores1 field changedInput schema / properties / keyword / descriptionAdded value: +"地点或门店关键词，如“人民广场”；可省略，省略时返回默认门店"v0.1.0calculate-pricenow-time-infoquery-mealsquery-my-couponsquery-nearby-storesScored across 5 tools
Each tool covers a clearly distinct function: time, store search, menu lookup, coupon listing, and price calculation. Descriptions explicitly differentiate calculate-price from order placement and query-meals, leaving no overlap.
Names use consistent kebab-case and mostly follow a verb_noun pattern (query-nearby-stores, query-meals, query-my-coupons, calculate-price), but now-time-info deviates as a noun phrase rather than a verb-led action.
Five tools is a reasonable, focused set for query and pricing operations, and each tool earns its place. It is slightly thin given the broader ordering workflow implied by the descriptions.
The descriptions reference create-order and auto-bind-coupons, but those tools are absent, leaving no way to place an order or claim coupons. This creates significant dead ends for the core ordering domain.
Zero-secret MCP gateway for AI agents: risk-scored, audited calls with human-in-the-loop approval.
Security & DLP proxy for MCP: tool-poisoning scans, PII redaction on tool args/results. Beta.
MCP server for your apps' tools and custom tools, plus hosted AI agents and approval-gated workflows
REST-to-MCP for UK hospitality. Safety proxy: circuit-breakers, rate limits, whitelists. Apache 2.0.
