Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@a207-router-mcp Classify intent 'my child hasn't urinated in 12 hours' and check safety gate"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
调度 Agent 独占的确定性判定层。安全红线不交给概率模型：P0 危急词、三条互斥硬规则 （MX-1/MX-2/MX-3）、权限矩阵，全部落成可单测的纯函数。
技术栈：FastMCP ≥2.0 + pydantic ≥2 + Python 3.13，stdio 传输
依据：docs/01_多智能体与MCP总体需求梳理_v1.md §5/§6/§7、docs/02_Wave1_构建规格_v1.md §2.1
零跨包引用：不 import 任何其他 a207-* 包，入参由调度 Agent 从 PCP 取值后显式传入
src/a207_router_mcp/
core.py 安全闸 + 意图分类（纯逻辑，无 fastmcp）
permissions.py 权限矩阵执行点 + 写工具识别（MX-3 落点）
constants.py 角色、13 个 MCP 登记表、权限矩阵、写权策略
lexicon.py P0 危急词、分期词族、意图路由表、槽位词典
slots.py 正则抽槽位
models.py pydantic 请求/响应模型
server.py FastMCP 实例，挂载四个工具
tests/test_tools.py 46 个断言，纯 python 可跑Related MCP server: NORNR MCP Control
判定顺序固定：P0 危急词 → 入参登记校验 → MX-1 → MX-2 → MX-3 → 权限矩阵兜底。
返回：{allow, reason, applied_rule, gate, delegate_to, requires_confirmation, matched_keywords}
applied_rule：MX-1 | MX-2 | MX-3 | none
gate：P0_EMERGENCY | INPUT | MX | PERMISSION_MATRIX | PASS，用于区分同为 none 的拒绝来源
规则 | 内容 |
P0 | 命中危急词（抽搐/少尿/无尿/大量出血/意识不清等 30 余条）即断崖终止，不进入任何业务 MCP |
MX-1 | 分期/eGFR/几期/肾小球滤过/PEW/生长障碍/血压百分位类问题，caller 为 nutritionist 或 parent_assistant 时拒绝并 |
MX-2 |
|
MX-3 | 写工具 → 允许 caller： |
intent 可传用户原文，也可直接传工具名；中文写入说法（写回病历、录入化验、打卡等）已登记别名，避免绕过 MX-3。
规则命中优先，未命中返回 intent="unknown" 且 fallback="llm"，由上层软分类后再过一次安全闸。
返回：{intent, mcp, slots, confidence, allowed_callers, matched_keywords, candidates, fallback, note}
intent | 目标 MCP | 允许 caller |
emergency_red_flag | a207-router-mcp | 全部（强制前置， |
patient_profile | a207-his-mcp | 调度/医生/营养师(RL)/家长(RL)/风险预警 |
clinical_staging | a207-ckd-clinical-calc-mcp | 仅 doctor_assistant |
lab_result | a207-lis-mcp | 医生/家长(受限视图)/风险预警 |
nutrition_calc | a207-nutrition-calc-mcp | 医生/营养师/家长 |
meal_plan | a207-meal-plan-mcp | 医生/营养师 |
risk_assessment | a207-risk-rules-mcp | 医生/风险预警 |
nutrition_assessment | a207-nutrition-assessment-mcp | 见权限矩阵，写入按 MX-3 |
gamification | a207-gamification-mcp | 仅 child_companion |
notify | a207-notify-mcp | 仅 risk_warning 可写 |
report | a207-report-mcp | 医生/营养师/家长(RL)/风险预警 |
knowledge | a207-knowledge-mcp | 全部，按角色切语料 |
followup | a207-followup-mcp | 医生/营养师/风险预警 |
打分口径：命中关键词长度求和，同分按优先级（P0→P5）取胜；confidence = min(0.95, 0.50 + 0.05 × 分数)。
"排食谱/一周食谱/三餐怎么安排"路由到 M7；裸词"食谱"按构建规格 §2.1 归 M5，由调用方结合上下文决定是否转交。
需求文档 §7 权限矩阵的执行点。action 可传 read/write，也可直接传工具名。
返回：{allow, access, resolved_action, reason, write_tool, requires_confirmation, limited_view}
access 为矩阵原始格子：R / RL / R/W / -；limited_view=true 表示只能给受限视图
精度说明：命中已登记写工具时，MX-3 映射优先于矩阵格子（v1.2 已用 MX-3 收口写入路径），
因此 parent_assistant + a207-nutrition-assessment-mcp + upsert_food_diary 放行，其余读操作仍按矩阵为 -。
正则 + 词典抽槽位，抽不到留空，绝不猜测。
返回：{patient_id, food[], analyte[], date[], number[], age_years, weight_kg, height_cm, time_window_days, meal, measure[]}
patient_id 匹配 PCP 契约 ^P[0-9]{4,}$
analyte 归一到 PCP 字段名（potassium / phosphorus / scr / albumin / hemoglobin …），单位口径以
contracts/pcp-schema.json 为准：Scr μmol/L，K/P/Ca mmol/L，能量 kcal，蛋白 g，身高 cm，体重 kg
number 保留原始单位；斤自动折算 kg，月龄自动折算岁
python -m py_compile src/a207_router_mcp/*.py
python tests/test_tools.py # total=46 passed=46 failed=0单测覆盖：MX-1/MX-2/MX-3 越权拒绝与正常放行、P0 断崖、未登记 caller/MCP、矩阵兜底、 意图路由 8 例、权限矩阵 6 组、槽位抽取 6 例，另含"无跨 a207 包引用 + 纯逻辑层不依赖 fastmcp"的静态自查。
启动（需先安装 fastmcp）：fastmcp dev src/a207_router_mcp/server.py 或 python -m a207_router_mcp.server。
权限矩阵执行点：caller x MCP x read/write，写工具按 MX-3 收口判定。
| Name | Required | Description | Default |
|---|---|---|---|
| action | No | read | |
| caller | Yes | ||
| mcp_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It mentions an 'execution point' and a rule for write tools, but does not clarify side effects, authorization requirements, or what happens when permission is denied. The behavior remains largely opaque.
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 and thus concise, but it is densely packed with jargon and lacks any structural separation of concepts. It is not well-organized for quick comprehension, though it does fit in minimal space.
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 has three parameters, no annotations, and an output schema that is not described, the description is insufficient. The agent is left without understanding when to invoke it, what the return format looks like, or how the permission decision is made, making it incomplete for reliable invocation.
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 any of the three parameters. While 'caller' and 'MCP' are implicit, the 'action' parameter is not mentioned, and no guidance is given for valid values or how parameters interact with the permission matrix.
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 it is a permission matrix execution point checking caller x MCP x read/write, which identifies the resource and action. However, it is phrased as a noun phrase rather than a clear verb+resource imperative, and the term 'MX-3 收口判定' is cryptic without context, making the purpose somewhat vague.
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 hints that write tools are judged by a specific rule ('写工具按 MX-3 收口判定'), but it does not clearly state when to use this tool versus alternatives like check_safety_gate or classify_intent. No explicit conditions, prerequisites, or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
安全闸：P0 危急词扫描 + MX-1 分期互斥 / MX-2 游戏化隔离 / MX-3 写权收口。
返回 allow 为 false 时，调度 Agent 必须终止本次路由并按 reason 处置。
| Name | Required | Description | Default |
|---|---|---|---|
| caller | Yes | ||
| intent | Yes | ||
| target_mcp | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses the gate's blocking behavior (allow=false → terminate routing) and lists the three policy domains, offering useful operational context beyond a simple 'check.' It does not detail side effects or permissions, but for a read-only-style safety gate, this is adequate.
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 two sentences: the first fronts the primary function with policy specifics, and the second gives the critical operational instruction. Every phrase earns its place with no redundancy or fluff.
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?
The description covers the tool's gate role and the required action on denial, and an output schema exists to define return values. However, it lacks parameter explanations and explicit usage conditions relative to sibling tools, leaving moderate gaps for a tool with 3 parameters and no annotations.
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?
The schema has three parameters with 0% description coverage, and the tool description does not explain any of them. The 'P0 critical word scan' hints that the 'intent' parameter is likely scanned, but no explicit mapping is provided, leaving the agent to infer parameter meanings.
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 defines the tool as a safety gate with specific responsibilities: P0 critical word scanning and enforcement of MX-1/MX-2/MX-3 policies. This distinguishes it from siblings like check_permission and classify_intent, and the behavioral consequence (terminate routing on allow=false) further specifies its unique role.
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 states when this tool must be used by the scheduling agent (before routing) and mandates termination on a negative result, providing clear contextual guidance. However, it does not explicitly contrast with alternatives or state when not to use it, so it falls short of full exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
意图路由：规则命中优先，返回目标 MCP、允许的 caller、槽位与置信度。
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral details beyond nothing (no annotations) by noting that rule matches take priority and listing return fields. However, it does not disclose side effects, authorization needs, or failure behavior, leaving the full burden unmet.
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, information-dense sentence. It front-loads the action and includes the key rule-priority constraint without any filler.
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 simple single-parameter classifier, the description covers the core behavior and outputs, especially with the output schema present. Missing usage guidance and edge-case behavior are notable but not critical.
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?
The schema has one parameter 'text' with 0% description coverage, and the description does not mention this parameter or its format. It fails to compensate for the coverage gap, though the parameter name is self-explanatory.
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 the tool performs 'intent routing' and specifies the exact outputs: target MCP, allowed caller, slots, and confidence. This clearly distinguishes it from sibling tools like check_permission, extract_slots, and check_safety_gate, which handle different concerns.
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?
No explicit guidance is given on when to use this tool versus the siblings. There is no mention of prerequisites, sequencing, or exclusions; the rule-priority note is algorithmic, not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
规则抽槽位：patient_id / food / analyte / date / number / 量具 / 时间窗。
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for disclosing behavior. It mentions 'rule-based' but does not describe whether it modifies input, what the output structure is, error handling, or side effects. The presence of an output schema mitigates this somewhat, but the description itself is insufficient.
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 appropriately short and front-loaded with the core purpose. It is a single, direct sentence without filler, though it could benefit from a brief note on input. It is concise but not minimal to the point of under-specification.
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?
This is a simple tool with a single parameter and an output schema, so it does not require extensive description. However, the lack of usage or behavioral context makes it incomplete for an agent encountering it for the first time. Given the sibling tools, some integration guidance would help but is not critical.
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%, so the description must compensate. It lists slot types (which are likely output fields) but gives no explanation of the 'text' parameter's meaning or format. The description does not help an agent understand what value to pass, only what the tool extracts.
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's function: rule-based slot extraction, listing specific slot types (patient_id, food, etc.). This is a specific verb+resource that distinguishes it from siblings like check_permission or classify_intent. However, it does not explicitly mention that the input is text, which the schema reveals.
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?
No guidance is provided on when to use this tool versus alternatives, or any context for its invocation. The description is purely functional without usage scenarios, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool purposes are mostly distinct, but check_permission and classify_intent both deal with caller permissions, and extract_slots overlaps with classify_intent's slot output, creating potential confusion about when to call each. Descriptions help clarify the different aspects (permission matrix vs routing vs safety gate vs slot extraction).
All tool names follow a consistent verb_noun pattern with lowercase snake_case: check_permission, check_safety_gate, extract_slots, classify_intent. Predictable and uniform.
With only 4 tools, the server is tightly focused on routing and safety. Each tool covers a distinct aspect of the routing pipeline without redundancy, making the count well-scoped.
The tool set covers the full routing lifecycle: intent classification, slot extraction, permission checking, and safety gating. No obvious missing operations for the stated router purpose; the safety gate includes comprehensive MX-1/MX-2/MX-3 rules.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP enforcement layer that intercepts AI agent actions and blocks rule violations before execution.
Zero-secret MCP gateway for AI agents: risk-scored, audited calls with human-in-the-loop approval.
MCP gateway with runtime security policy, tool-call-level control, and audit of agent actions.
Pre-execution governance for AI agents. Deterministic PASS/FAIL/REVIEW verdicts, replayable proof.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ayeyouok/a207-router-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
