Click on "Deploy 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., "@pkulaw-mcp 查看北大法宝当前账户有哪些可用工具，再检索与劳动合同解除有关的法规"
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.
把北大法宝接入支持 MCP 的 AI 客户端，用自然语言检索法规、查询案例，并按账户权限获取法律资料。
这个项目在客户端与北大法宝 MCP 服务之间做了一层转接：安装包不含凭据，Token 配置在运行桥接服务的环境中。模型通过两个工具查看可用接口、发起查询，不需要在每次调用时传入 Token。
需要 Node.js 22 或更高版本、支持 stdio 的 MCP 客户端，以及可用的北大法宝 Token。
安装 Node.js 22 或更高版本，运行 node --version 和 npx --version 确认命令可用。
打开目标客户端的 MCP 配置，新增一个 stdio 服务。先在本地私密位置备份原配置，保留已有的其他服务。
使用下面的配置；Token 通过客户端的私密环境变量设置或本地私人配置填写，不要把示例占位符当作真实凭据。
{
"mcpServers": {
"pkulaw": {
"command": "npx",
"args": ["-y", "@adelagary/pkulaw-tokenless-bridge@0.1.0"],
"env": {
"PKULAW_TOKEN": "YOUR_PKULAW_TOKEN"
}
}
}
}PKULAW_TOKEN 只填写 Token 本身，不要加 Bearer 前缀。不要带空格或换行。程序不会自动读取 .env 文件，需要由客户端或运行环境传入变量。不同客户端的配置文件位置和外层字段可能不同，请按客户端要求填写。
配置中的启动命令为 npx -y @adelagary/pkulaw-tokenless-bridge@0.1.0。首次启动会由 npx 获取对应 npm 包；stdio 服务等待客户端通信，不会打开登录页或提供 HTTP 地址。
保存后重新加载 MCP 服务，检查初始化是否成功，以及客户端是否能列出下方两个桥接工具。这只能确认程序可运行，不能证明 Token 有效或账户具有数据权限。确认查询可能消耗账户额度后，再发起一次需要的只读查询。
例如，可以让 AI：
查看北大法宝当前账户有哪些可用工具，再检索与劳动合同解除有关的法规。
把下面的提示词交给能操作本机配置的 AI Agent。涉及 Token 时，请自己在客户端或本地安全输入界面填写，不要粘贴到对话中。
请阅读 https://github.com/shiroidaoqi/pkulaw-mcp 的 README，帮我安装北大法宝 MCP。先检测或询问操作系统和目标客户端，确认其 stdio 配置方式与 Node.js ≥22；不要猜配置路径。在本地私密位置备份配置，保留其他 MCP 服务，再按 README 配置指定版本。Token 由我通过安全输入或客户端环境变量设置，不要索取、显示或写入聊天及公开文件；只填纯 Token，不加 Bearer 前缀，不走 OAuth，不额外授予权限。完成后验证初始化及两个桥接工具可见；这不代表法宝认证成功。如需查询验证，先说明可能消耗积分或额度，得到我授权后仅做最小只读查询。报告实际结果与错误，不要把安装成功当成查询成功。Related MCP server: MarketSage
桥接层提供两个工具：
工具 | 参数 | 用途 |
| 可选 | 获取当前账户可用的工具及参数说明；如返回 |
| 必填 | 按工具名称和参数对象调用北大法宝接口。 |
通常先查看工具列表，再按返回的参数说明发起查询。工具清单来自上游服务，不在项目中写死；不同账户的可用工具、数据范围和调用额度可能不同。
可用于法规检索、法规正文获取、案例检索等工作，具体以当前账户返回的工具为准。案例检索结果不等于裁判文书全文，能否获取全文取决于上游是否提供相应接口及账户权限。
每次调用使用独立会话，操作超时为 30 秒；输入参数上限 128 KiB，返回数据上限 1 MiB。结果较大时，可按上游工具支持的分页方式分次获取。
安装包不附带凭据，使用时需要配置自己的北大法宝 Token。tokenless 指分发包不含 Token，工具调用参数中也不需要填写 Token，并不代表匿名访问法宝。
Token 仅通过 PKULAW_TOKEN 环境变量传入，不要放在工具参数、聊天、Issue 或公开配置中。查询内容和返回结果会经过所用的 MCP 客户端与北大法宝；如果另行部署到托管环境，也会经过该环境，请留意敏感材料和凭据的访问权限。
本程序通过 stdio 与客户端通信，不直接提供远程 HTTP 服务。账户的数据权限、调用额度与 Token 有效期由北大法宝决定。
认证失败
检查 Token 是否有效、PKULAW_TOKEN 是否传入运行环境，以及是否误加了 Bearer 前缀。
客户端只显示两个工具
这是桥接层的设计。先调用 pkulaw_list_upstream_tools 查看北大法宝提供的具体工具，再通过 pkulaw_call_upstream_tool 使用它们。
工具能调用，但没有返回预期资料
先核对工具参数，再检查账户的数据权限、调用额度和服务可用性。桥接层不会增加账户权限或绕过额度限制。
在仓库目录中运行：
npm ci
npm run check
npm test使用 npm start 启动 stdio 服务，PKULAW_TOKEN 仍需由运行环境传入。
MIT。北大法宝数据与接口的使用以其服务条款及账户权限为准。
按pkulaw_list_upstream_tools返回的真实name/schema调用官方工具。arguments不可放入凭据；凭据仅由实例环境配置。本工具不是18个原生工具的schema直通。
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| arguments | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden; it usefully discloses that credentials must not be passed in arguments and are supplied by the instance environment (auth context). It says nothing about side effects, error behavior, or whether the invoked tool may mutate state, which matters for an arbitrary dispatcher.
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 compact sentences with the dispatch rule front-loaded and the credential constraint immediately after. The closing 'not a schema pass-through' sentence is short but its referent (18 native tools) is unexplained, slightly reducing clarity.
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?
No output schema and no annotations, so the description should say more about what happens on success/failure and that the target tool's own semantics apply. The credential and sourcing rules are covered, but behavioral coverage is partial for a generic proxy.
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% and the schema only declares a bare string and object, so the description must compensate. It explains that 'name' must be the real name returned by the list tool and that 'arguments' are the payload for that tool and must exclude credentials, adding real meaning beyond the 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 action (invoke an official upstream tool) and ties it to the name/schema returned by the sibling list tool, which separates it from pkulaw_list_upstream_tools. The final sentence about '18 native tools' is somewhat obscure, but the core verb+resource 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?
Explicitly directs the agent to obtain the real name and schema from pkulaw_list_upstream_tools before calling, which is a concrete prerequisite and an implicit ordering versus the sibling. No explicit when-not guidance, but the workflow is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
使用本实例用户自己的法宝凭据读取官方聚合MCP真实工具名称和schema。无凭据将失败；不是公开匿名服务。可用nextCursor分页。
| Name | Required | Description | Default |
|---|---|---|---|
| cursor | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden, and it does disclose two important traits: credential dependency with an explicit failure mode, and pagination support. It still omits return shape details beyond 'tool names and schemas' and any rate-limit/caching behavior, keeping it short of a 5.
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 compact clauses ordered by importance: what it reads, the auth caveat, then pagination. No repetition, no filler, and the core action is front-loaded.
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 one-parameter discovery tool with no annotations and no output schema, the description covers action, authentication requirement, failure mode, and pagination. The remaining gap is the missing explicit hand-off to pkulaw_call_upstream_tool, which the agent must infer from the names.
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 single input parameter 'cursor' has 0% schema description coverage, so the description must compensate. It does mention pagination, but names 'nextCursor' (an output field) rather than the input 'cursor', leaving the agent to infer that the returned nextCursor feeds back into the cursor argument.
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+resource: read the official aggregated MCP's real tool names and schemas using this instance's own Pkulaw credentials. The verb '读取'(list/read) is distinguishable from the sibling pkulaw_call_upstream_tool (invoke), though the sibling is never named explicitly.
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?
Provides a clear precondition (must be authenticated; fails without credentials; not an anonymous public service), which implies when it is usable. However, it never states the workflow relationship to pkulaw_call_upstream_tool (e.g. 'use this first to discover names, then invoke them') or any when-not 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.0pkulaw_call_upstream_toolpkulaw_list_upstream_toolsScored across 2 tools
The two tools have clearly distinct roles: one discovers upstream tool names and schemas, the other invokes them. The descriptions explicitly clarify the relationship and prevent confusion between listing and calling.
Both names use a consistent pkulaw_ prefix and verb_noun structure (list_upstream_tools, call_upstream_tool). There is a minor singular/plural mismatch between 'tools' and 'tool', but the pattern remains predictable.
Two meta-tools are appropriate for a gateway/proxy server whose real surface is discovered dynamically. The count is slightly below the typical 3-15 range, but each tool earns its place and avoids unnecessary duplication.
The list-and-call pair covers the core proxy lifecycle: discover upstream schemas and invoke them. Minor gaps exist around explicit credential status or single-tool metadata, but the list tool returns the necessary schemas for invocation.
Connect AI clients to biomedical data and tools.
36 SEC, WCAG and entity-diligence tools behind 2 low-context ones: discover_tools, call_tool.
Human-input bridge for AI agents with voice-first answer links, MCP tools, and HTTP APIs.
Gateway between LLM agents and world data through eight tools and a bundled endpoint catalog.
