Activate Manager Mode for a fund — starts the personal router.
This deploys capital across the fund's roster bots according to their
weights and the fund's risk caps. The main platform router is paused
while Manager Mode is active.
Args:
fund_id: The fund's ID.
Returns success or error.
| Name | Required | Description | Default |
|---|---|---|---|
| fund_id | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
Input schema / properties / user_idRemoved value: -{
- "title": "User Id",
- "type": "string"
-}Input schema / requiredPrevious value: -[
- "user_id",
- "fund_id"
-]New value: +[
+ "fund_id"
+]Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It discloses the main side effects: deploying capital according to weights and risk caps, and pausing the main platform router. It does not cover edge cases such as repeated activation or failure conditions, so it stops short of full transparency.
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 compact and well-structured: a one-line purpose, a short behavior paragraph, and an Args/Returns section. Every sentence contributes meaningful information, and the core action is front-loaded for quick scanning.
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 action with an output schema, the description covers the purpose, key behavior, side effect, and argument. It could mention deactivation or prerequisites, but those are reasonably inferable from the sibling tool list and the simplicity of the API surface.
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 only parameter is fund_id. The description says 'The fund's ID,' which is minimal and largely repeats what the property name already implies. Since schema description coverage is 0%, this is adequate but not enriching; it provides no additional constraints, format guidance, or provenance for the ID.
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 opens with a specific action ('Activate Manager Mode for a fund') and resource, then clarifies the mechanism ('starts the personal router'). It further differentiates itself by describing unique behavior: deploying capital across roster bots and pausing the main platform router, making it clearly distinct from siblings like deactivate_fund or get_active_fund.
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 clear context for when the tool should be used: when Manager Mode should be activated for a fund. It also implicitly warns that the main platform router is paused while active, which is a relevant consideration for choosing this tool. It does not explicitly name alternatives or preconditions, but the purpose is unambiguous for a single-action tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.