List all ChangeGamer editorial guides (always free, separate from the licensable corpus): cluster-first hub/spoke graph with every article's title, search intent, word count, takeaways count and variant URLs. No body content — fetch bodies with get_article.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description responsibly carries the burden of behavioral disclosure. It explains that the output is a cluster-first hub/spoke graph with a defined list of fields, explicitly notes that body content is absent, and clarifies the resource scope. It leaves out details like auth requirements or pagination, but for a zero-parameter list endpoint this is sufficient.
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 accomplish multiple goals: scope, fairness, content taxonomy, field list, and routing to get_article. Nothing is redundant; the most important 'free and separate from corpus' positioning is front-loadaded, and the exclamation body fetch note is at the end.
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 zero parameters and no output schema, the description covers the essential return values (a structured graph of article metadata), the limitation (no body content), and the clear fallback (get_article). It is also easy for an agent to select this tool against all sibling tools because its scope is explicit.
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 no parameters, so baseline 4 is granted. The description adds no parameter-level information because none is needed; it fully describes what is returned without referencing any inputs.
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 opens with a specific verb and resource: 'List all ChangeGamer editorial guides.' It clearly distinguishes these guides from the 'licensable corpus' and enumerates exactly what fields appear in the results (title, search intent, word count, takeaways count, variant URLs). This makes its role unambiguous and separates it from sibling tools like list_resources or search_resources.
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 (for editorial guides, which are always free) and when not to use it: 'No body content — fetch bodies with get_article.' It names the correct sibling alternative and the condition that triggers it, leaving no ambiguity about routing.
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: checking access, fetching corpus (free vs full), pricing, payment, listing, searching, stats, and single resource retrieval. No significant overlap.
All tools follow a consistent verb_noun pattern in snake_case (e.g., check_access, get_corpus, list_resources). Verbs are uniform and descriptive.
With 10 tools, the set is well-scoped for a resource access and management API. Each tool serves a clear purpose without redundancy or excessive number.
The toolset covers core operations: access verification, corpus retrieval (free and premium), pricing, payment info, resource listing, search, and stats. Missing write operations (e.g., purchase), but acceptable for a read-focused server.