list_library_itemsList documents in a library folder, or at the root if no folder is given.
Args:
folder_id: Folder UUID to list (optional — omit for root-level items)
| Name | Required | Description | Default |
|---|---|---|---|
| folder_id | No |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds the behavioral nuance that omitting folder_id lists root-level items, which is useful but does not go further (e.g., no pagination or sorting details). This aligns with the 'with annotations' baseline.
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 two sentences long, front-loaded with the primary purpose, and includes an 'Args' section for the parameter. Every sentence earns its place with no redundancy or filler.
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 (one optional parameter, no nested objects, and an output schema present), the description is sufficiently complete. It explains the key behavioral distinction (root vs. folder) and does not need to detail return values since the output schema handles that.
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 provides only the property name, type, and default. The description adds meaning by explaining folder_id is a Folder UUID and that omitting it yields root-level items, which is essential for correct use. This compensates well for the lack of parameter descriptions in the schema.
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?
Clearly states the tool lists documents in a library folder, with an explicit fallback to root-level items. The verb 'List' and resource 'library items' are specific, and it distinguishes from sibling tools like list_library_folders by focusing on documents rather than folders.
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?
Provides clear context: use this to list documents, optionally within a specified folder, or at root if no folder is given. It does not explicitly name alternatives or exclusions, but the intended usage is unambiguous given the sibling tools and the optional folder_id parameter.
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.
Each tool targets a distinct resource and action. Portfolio, alert, watchlist, library, journal, and search tools have clearly separated purposes with no overlapping functionality. Even similar tools like get_portfolio_statistics and get_positions provide different outputs.
The majority follow a clear verb_noun pattern in snake_case (e.g., create_portfolio, delete_library_item). However, 'finance_search' inverts the verb-noun order and 'run_deepdive' uses a less common verb, creating minor but noticeable exceptions.
31 tools is on the high side but each serves a distinct purpose across portfolio management, alerts, watchlists, library, journal, search, and bug reporting. The library subsystem alone accounts for 11 tools (CRUD + versions + move + rename + search), which is justifiable for a full document manager.
Core operations are present but several lifecycle gaps exist: no delete_watchlist, delete_portfolio, update_portfolio, update_alert, or delete_transaction. The journal and deepdive areas also lack update/delete capabilities. Agents may hit dead ends when trying to remove or modify certain resources.