mcp-agent-hub

set_master

Designate a specific agent as the sole master; when exclusive is enabled, demote other masters to subagents and redirect their reporting lines to the new master.

Instructions

手动指定某个 Agent 为唯一主理人。exclusive=true 时把其他 master 降为 subagent，并把子代理的汇报线改到新的主理人。用法：set_master(name='boss')。

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "name": "<name>"
    },
    "name": "set_master"
  }
}

Input Schema

Name	Required	Description	Default
`name`	Yes
`exclusive`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 27, 2026

TDQS

A3.8/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden, and it does disclose the key side effects: other masters are demoted to subagent and subordinate reporting lines are rewired to the new master when exclusive=true. It omits permissions, reversibility, and behavior when the agent does not exist.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences plus a usage line, with the core action front-loaded and zero filler. Every sentence adds either purpose or behavior.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be described, and the mutation's ripple effects are covered. The remaining gaps—error behavior for unknown names and the exclusive=false branch—are relatively minor for a 2-parameter tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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 explains the effect of exclusive=true and shows name in an example call, which is meaningful, but it never states what exclusive=false does and leaves the 'name' parameter's meaning (agent identifier vs display name) implicit.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific action (manually designate an Agent as the sole 主理人) with a clear verb and resource, which is distinct from siblings like set_status or list_agents. It is not tautological with the name, but it does not explicitly position itself against the closest sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The '用法：set_master(name=...)' line gives a concrete call example and '手动指定' implies a manual override scenario, but there is no explicit when-to-use vs when-not, nor any mention of alternatives such as set_status for non-exclusive role changes.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.