Build non-custodial ERC-4626 deposit plan (approve USDG + deposit) into Morpho Steakhouse Earn vault. Does NOT broadcast.
| Name | Required | Description | Default |
|---|---|---|---|
| owner | Yes | ||
| assets | No | Raw USDG amount (6 decimals) | |
| approveMax | No | ||
| assetsHuman | No | Human USDG amount e.g. "100" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It explains that the tool builds a plan (non-custodial, involves approval and deposit) and does not broadcast. However, it does not disclose what the plan consists of (e.g., typed data, signatures), side effects, or required permissions. More detail on the output or state changes would improve 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 a single sentence that packs key elements (action, resource, target, caveat) without unnecessary words. It is front-loaded and efficient.
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?
Given the tool's complexity (4 parameters, no output schema), the description is minimal. It does not explain what a 'plan' is, how to use the result, or the return format. For a plan-building tool, context on subsequent steps (e.g., execution via stocktoken_execute_plan) is missing.
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 50%: assets and assetsHuman have descriptions, but owner and approveMax do not. The description adds no parameter-level information, leaving the required 'owner' and the 'approveMax' boolean unexplained. It mentions 'approve USDG' but does not map to parameters.
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 clearly states the action ('build'), the resource ('non-custodial ERC-4626 deposit plan'), and the steps involved ('approve USDG + deposit') into a specific vault. It also distinguishes from broadcasting by noting 'Does NOT broadcast', which differentiates it from sibling tools like stocktoken_execute_plan.
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 description mentions that the tool does not broadcast, implying that the plan must be executed separately, but it does not explicitly name the sibling tool for execution (e.g., stocktoken_execute_plan). It also does not provide guidance on when to use this tool over similar ones like stocktoken_morpho_withdraw_plan or stocktoken_subscribe_plan.
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.
All tools have clearly distinct purposes, covering access management, token queries, trading, sessions, subscriptions, tips, and system operations. No two tools appear to do the same thing; even related tools like deposit/withdraw plans are differentiated.
All tools follow a consistent 'stocktoken_' prefix with lowercase underscore-separated names. The pattern is uniform (e.g., verb_noun or single noun), with no mixing of camelCase or other styles.
37 tools is high for an MCP server but each tool addresses a specific function within a complex domain (tokenized stock OS, on-chain payments, subscriptions, etc.). The count is justified, though slightly beyond typical scoping.
The tool surface covers all major aspects: access lifecycle, token metadata, trading (simulate, quote, execute plan), sessions, subscriptions, tips, policies, liquidity, and system status. No obvious gaps exist for the stated domain.