list_topicsThe canonical list of management topics Flevy's catalog is organized under, each with its known aliases (e.g. "Digital Transformation" and "Digital Transformation Strategy" may be the same topic) and content counts. Use this to map a user's phrasing to the exact topic filter accepted by search_content, or to show what subject areas Flevy covers.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful context beyond this: it reveals that the list is 'canonical', includes known aliases (with a concrete example), and supplies content counts, all of which affect how the agent might use the output. It doesn't describe pagination or ordering, but for a zero-parameter read-only list, the transparency is strong.
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?
Two sentences deliver full purpose, usage guidance, and key output details without redundancy. The description is front-loaded with the essential 'canonical list' concept and wastes no words.
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?
With no parameters and a simple list result, the description covers the essentials: what is returned (topics with aliases and counts), why it matters (canonical mapping), and how it connects to sibling tools. The absence of an output schema is compensated by the description's explicit mention of output contents and aliases, making the tool's behavior well understood.
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 has no parameters (100% coverage, 0 params). The baseline for zero parameters is 4, and the description provides no misleading parameter information. It appropriately focuses on the tool's output and uses cases rather than parameter details, which are nonexistent.
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 identifies the tool as returning 'the canonical list of management topics' with aliases and content counts. It uses a specific verb ('list') and resource ('management topics'), and explicitly distinguishes its role from search_content by noting it returns the topic filter. This is a model of clarity.
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?
Explicitly states two concrete use cases: mapping user phrasing to the exact topic filter for search_content, and showing Flevy's subject areas. It also implicitly differentiates from sibling tools like search_content and get_topic_details, providing clear guidance on when to choose this 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.
Each tool targets a distinct action: searching the catalog, retrieving item metadata, previewing slides, listing topics, and deep-diving into a single topic. No two tools serve the same purpose; even list_topics and get_topic_details are clearly differentiated by scope (all topics vs one topic).
All tools follow a verb_noun pattern with snake_case: get_content_details, get_slide_deep_dive, get_topic_details, list_topics, search_content. The verbs (get, list, search) are appropriate for their actions and consistent throughout.
With 5 tools, the set is well-scoped for a content marketplace, covering search, retrieval, preview, and topic exploration without redundancy. It fits comfortably within the ideal 3-15 range and each tool earns its place.
The tools cover the full discovery journey: browse topics, search content, get detailed metadata, and preview slides. There are no critical gaps for the marketplace's purpose; even author and related topic information are accessible through existing tools, so the workflow has no dead ends.