Get the user's currently active (Manager Mode) fund.
Args:
user_id: The user's ID.
Returns the active fund object or null if Manager Mode is not active.
| Name | Required | Description | Default |
|---|---|---|---|
| user_id | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It clearly states that the tool returns either the active fund object or null when Manager Mode is inactive, which is a meaningful behavioral trait. It does not mention potential errors or permissions, but the getter nature and null condition are well covered.
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 extremely concise and well structured: a one-line purpose, an Args line, and a Returns line. Every sentence earns its place and the key behavior (null when Manager Mode is inactive) is front-loaded through the purpose statement.
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 getter with one parameter, the description is largely complete: it identifies the resource, the parameter, and the null-case behavior. Since an output schema exists, the full return structure is presumably available. The main missing context is explicit differentiation from sibling fund tools, but the active/Manager Mode qualifier mitigates this.
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, user_id, has 0% schema description coverage. The description's 'user_id: The user's ID' is a minimal clarification that ties the parameter to the user whose fund is being fetched, but it adds little beyond the parameter name and schema title. It is adequate for a single self-explanatory parameter but does not go deeper into expected format or semantics.
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 a specific verb ('Get'), a clear resource ('the user's currently active (Manager Mode) fund'), and explicitly distinguishes it from the broader get_fund/list_funds siblings by qualifying it as the active Manager Mode fund. This is unambiguous and actionable.
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 given about when to prefer this tool over siblings like get_fund or list_funds. The null-return condition implies a use case, but there is no explicit statement such as 'Use get_fund when you have a specific fund ID' or 'Use this only when checking the active Manager Mode fund.'
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.
Most tools target a distinct resource and action, but browse_fund_marketplace and get_marketplace_bots are easy to confuse since both surface marketplace bots with performance metrics. The detailed descriptions clarify their different intents, though the naming does not strongly reinforce the distinction.
The set almost uniformly uses snake_case verb_noun names like create_fund, list_funds, and update_fund_weights. Minor inconsistencies exist, such as get_marketplace_bots returning a list instead of a single item and browse_fund_marketplace using a different pattern from the other marketplace tools.
At 26 tools, the server is on the heavy side and above the typical well-scoped range. The broad domain of funds, strategies, marketplaces, and market data helps justify the count, but several overlapping marketplace/list tools inflate the surface and could be consolidated.
The set covers the core fund lifecycle, roster management, strategy validation/deployment, marketplace browsing, and market data reads quite thoroughly. Minor gaps remain, such as no update/delete operations for strategies and no direct tool for publishing a bot to the marketplace, but these are workable within the existing workflow.