get_saved_listReturns one authenticated user's saved list with type-discriminated items. The protected default Watchlist supports stocks and funds; named lists also support politicians and insiders.
| Name | Required | Description | Default |
|---|---|---|---|
| list_id | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
| list | Yes | ||
| items | Yes | ||
| access | No | ||
| outcome | Yes | ||
| provenance | No | ||
| data_status | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, so the read-only nature is established. The description adds useful context about user-scoping and which list kinds support which item types, but it does not disclose edge-case behavior such as invalid list IDs or inaccessible lists.
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 concise and front-loaded: the first sentence states the core behavior, and the second sentence adds the important type-support distinction in a compact way. There is no redundant wording.
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 that there is one simple UUID parameter, an output schema, and read-only annotations, the description provides sufficient context about which resource is returned and what item types are supported. Edge-case behavior is omitted, but that is a minor gap for this low-complexity tool.
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 input schema has 0% description coverage, and the description does not explicitly explain the list_id parameter. It implies list_id identifies a saved list, but it does not clarify ownership expectations, how the ID is obtained, or what happens when the user does not have access to that list 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 has a specific verb and resource: 'Returns one authenticated user's saved list with type-discriminated items.' It also distinguishes the default Watchlist from named lists, which helps an agent understand exactly what this tool fetches relative to list-management siblings.
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 tool's usage is reasonably clear: use it to fetch a single saved list for the authenticated user. However, it does not explicitly name alternatives such as list_saved_lists or explain when not to use this tool, so the agent must infer the boundary from sibling names.
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.
Every tool has a clearly distinct purpose, reinforced by explicit 'WHEN TO USE' and 'WHEN NOT TO USE' guidance. Overlapping concepts like get_13f_activity vs get_stock_holders vs get_fund_holdings are precisely scoped to changes, holders, or full portfolios, leaving no ambiguity for an agent.
Names largely follow a verb_noun pattern with consistent snake_case, but there is minor variation in CRUD verbs: add_saved_list_item vs create_saved_list, delete_saved_list vs remove_saved_list_item, and update_saved_list_item_notes. These are understandable but not perfectly uniform; otherwise naming is predictable.
At 24 tools, the server is on the heavy side of the ideal range, but the breadth of the domain (stocks, funds, politicians, insider trades, activist stakes, screenings, saved lists, status) justifies each tool. It feels comprehensive without being bloated, though it could benefit from consolidation in a few areas.
The tool surface covers the full lifecycle of the domain: security lookups, stock analysis, fund profiling and comparison, backtesting, politician trading, insider and activist feeds, screenings, quarter metadata, and saved-list management. There are no obvious gaps or dead ends; the set feels complete for the stated purpose.