Get metadata for one canonical Stock Token or core asset by symbol (e.g. NVDA) or contract address on Robinhood Chain 4663. Use to verify a token is official before trading.
| Name | Required | Description | Default |
|---|---|---|---|
| symbolOrAddress | Yes | Ticker like NVDA or 0x contract address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It correctly identifies this as a read operation ('Get metadata') and specifies the network and input types. However, it does not disclose how invalid symbols or addresses are handled, rate limits, or authentication requirements. For a simple read tool, this is adequate but not comprehensive.
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, consisting of two sentences (24 words). The first sentence clearly states the action and inputs, and the second adds the use case. No filler or redundant information. It is well-structured and front-loaded.
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 simplicity (1 parameter, no output schema, no annotations), the description provides all necessary information: what it does, inputs, network, and a practical use case. An agent can correctly invoke this tool without confusion. It is complete for its complexity level.
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 schema covers 100% of parameters with descriptions. The description adds significant value by providing examples (NVDA) and clarifying that the input can be a ticker or contract address, as well as specifying the network (Robinhood Chain 4663) and the notion of 'canonical' tokens. This goes beyond the schema's basic description.
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 ('Get metadata'), the resource ('one canonical Stock Token or core asset'), and the inputs (symbol or contract address). It also specifies the network (Robinhood Chain 4663) and gives a concrete example (NVDA). This distinguishes it from sibling tools that perform different operations like listing, pricing, or execution.
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 explicitly states when to use the tool: 'Use to verify a token is official before trading.' This provides clear context. However, it does not mention when not to use it or suggest alternative tools (e.g., stocktoken_list for a broader view). The guidance is sufficient for a simple lookup 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.
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.