Read-only MCP endpoint for WorkBuddy growth-task autopilot from IHUI-AI (智汇AI). Tools: wb_server_info (engine intro, anti-fraud discipline, self-hosting guide) and wb_action_routes (task-code to execution-route map). Zero credentials, no write-side tools exposed publicly. Apache-2.0; self-host for the full write-side toolset.
Scored across 2 tools
The two tools are clearly separated in content: one returns the action-routing map for registered task codes, the other returns server/capability metadata. There is minor conceptual overlap since both are read-only informational introspection tools, but an agent can easily pick the right one.
Both names use a consistent `wb_` prefix with snake_case noun phrases, which is predictable and readable. The only slight deviation is that neither uses a clear verb, so the action is implied rather than stated.
Two tools is thin for something branded an 'autopilot' engine; the descriptions themselves admit the full write-side toolset is only unlocked under self-hosting. It is a borderline surface — reasonable for a read-only preview, but light for the stated purpose.
The surface offers only introspection: routing map and server info, with no tools to actually register, run, or inspect tasks. Descriptions explicitly note that all write-side capability is gated behind self-hosting, leaving a significant gap for an autopilot domain.
只读返回动作表选路图:每个已登记任务码走 desktop 链 / generic 直连链 / 无 verified 链(零出站登记)。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full burden; it does disclose that the operation is read-only and that one branch means '零出站登记' (zero outbound registration), which is genuinely useful behavioral context about side effects. It stops short of describing the shape or size of the returned map, or whether discoveries/registrations are needed before the map is populated.
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?
A single front-loaded sentence with zero filler — the read-only qualifier comes first, then the resource, then the enumeration of outcomes. The slash-and-parenthesis enumeration is dense and slightly hard to parse, which keeps it from a 5.
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 zero parameters and no output schema, the description must carry the entire burden of explaining what comes back. It sketches the return categories but does not define them, so an agent knows the tool's topic without knowing how to interpret 'desktop 链' versus 'generic 直连链' in the response.
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 tool takes zero parameters, so there is no parameter semantics to explain; baseline 4 applies. The description correctly implies the scope is all registered task codes with no filtering arguments available.
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 ('只读返回' — returns read-only) and a specific resource ('动作表选路图' — action-table routing map), plus the unit of granularity (per registered task code). An agent can tell it produces a routing classification, not metrics or config. It loses a point because the three routing outcomes ('desktop 链 / generic 直连链 / 无 verified 链') are domain jargon that is named but never defined.
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?
There is no when-to-use statement, no prerequisite, and no mention of the sole sibling wb_server_info as an alternative or complement. The only usage signal is implicit in the words '只读返回' — that it is a safe inspection call — which the agent must infer rather than being told.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
智汇AI(IHUI-AI)WorkBuddy autopilot 引擎介绍:能力边界、防伪造纪律、Apache-2.0 开源仓库、自托管指引(自托管可解锁全量写侧工具)。只读、零凭据。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations supplied, the description carries full burden, and it does disclose the two most important behavioral facts: 'read-only' and 'zero credentials' (no auth needed, no side effects). It does not describe the return shape (e.g., markdown docs vs. structured object), which is the main remaining gap for a zero-param info tool.
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?
A single dense line front-loads the identity and the guarantee ('read-only, zero credentials') at the end. The mid-sentence enumeration is a bit list-like, but every clause names a distinct content area, so little is wasted.
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, no-output-schema documentation tool, the description covers what the call yields (the four topic areas) plus the safety profile. Only the exact return format and the recommended call ordering relative to wb_action_routes are left unspecified.
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 tool takes zero parameters, so the baseline is 4. There is nothing for the description to explain parameter-wise, and it correctly does not waste text on inputs.
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 is an introduction to the IHUI-AI WorkBuddy autopilot engine and enumerates the covered topics (capability boundaries, anti-forgery discipline, Apache-2.0 repo, self-hosting guide). It is clearly an informational/documentation tool, not an action tool. However, it never contrasts itself with the sibling wb_action_routes, so the agent cannot tell from the description alone which of the two to call first.
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 parenthetical 'self-hosting unlocks full write-side tools' implies this tool is where you learn the capability envelope before attempting writes, which hints at usage. But there is no explicit when-to-use, no 'call this first' instruction, and no rule for choosing between this and wb_action_routes — the agent must infer.
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.
wb_action_routeswb_server_info
Add one secure layer between your agents and this server.