Search agentic trading prompts by keyword, category, or tag. Returns matching prompts with ID, title, use case and direct URL.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | Filter by tag (e.g. 'Execution', 'NVDA', 'Healthcare') | |
| limit | No | Max results to return (default 10, max 50) | |
| query | No | Keyword to search in prompt title and content | |
| category | No | Filter by category (e.g. 'Options Strategies', 'DCA & Dip Buying') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear the full burden. It does not disclose behaviors such as rate limits, authentication requirements, what happens when no matches are found, or whether filters are combined with AND/OR. The return fields are mentioned, but edge cases are ignored.
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, front-loads the action and filters, and contains no unnecessary words or redundancy. Every sentence adds value.
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?
The tool has 4 optional parameters and no output schema. The description explains what fields are returned, which is helpful. However, it does not cover behavior for empty results, pagination (though limit is explained), or filter combination logic. Sibling tools exist but are not referenced. Adequate but with clear gaps.
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 description coverage is 100% (all 4 parameters have descriptions in the schema). The tool description does not add semantic context beyond what the schema already provides; it merely restates the filter dimensions. Baseline of 3 is appropriate.
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 tool's action ('Search'), the resource ('agentic trading prompts'), and the filtering dimensions ('by keyword, category, or tag'). It also specifies the return fields (ID, title, use case, direct URL), distinguishing it from sibling tools like get_prompt which retrieves a single prompt.
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 implies usage when you have keyword, category, or tag to filter by, but does not explicitly state when to use alternatives (e.g., get_prompt for a specific prompt, or get_prompts_by_category for listing all in a category). No when-not-to-use guidance is provided.
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 has a distinct purpose: retrieving a single prompt by ID, fetching prompts by category, listing categories, and searching prompts. No functional overlap.
All tool names follow a consistent verb_noun pattern in snake_case (get_prompt, get_prompts_by_category, list_categories, search_prompts). Predictable and clear.
4 tools is well-scoped for a prompt library server. Each tool covers a core operation without redundancy, and the count feels neither too sparse nor overwhelming.
The tool set covers retrieval and search comprehensively, but lacks create/update/delete operations. Given the server's likely read-only purpose, this is a minor gap.