Keyword search across ALL ChangeGamer content (resources and editorial guides) with server-side ranking: term hits in title weigh most, then tags, then description. Returns ranked rows with type, slug, title and .md URL (no body content). Use get_resource/get_article to fetch winners.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Search query — one or more keywords | |
| limit | No | Max results (default 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of explaining behavior. It discloses server-side ranking weights, the returned fields (type, slug, title, and .md URL), and the exclusion of body content. It does not, however, discuss errors, rate limits, or empty-result behavior.
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?
Three sentences, front-loads the core action and scope, and every sentence adds information: ranking logic, result fields, and a follow-up tool recommendation. There is no wasted 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 two simple parameters, complete schema coverage for both, and no output schema, this description provides a full end-to-end picture of what the tool returns and how to proceed. The return shape and the absence of body content are explicitly covered, which is the key guidance agents need to invoke fetch tools next.
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%, so the baseline is 3. The tool description adds meaningful context beyond the schema: it explains how us q's keyword hits are ranked (title heaviest, then tags, but since no enums or output schema exist, the description covers the essential operational details. It explains the response shape, what is not returned, and the next step for fetching full content. A minor gap remains regarding output format and error cases, but those are not critical for invocation.
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 names a precise verb and resource: 'Keyword search across ALL ChangeGamer content (resources and editorial guides)'. This differentiates the general search from the sibling search_resources by emphasizing scope and content type.
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 clearly states the search scope and tells the agent to use get_resource or get_article for the actual content after searching. However, it does not explicitly differentiate from the sibling search_resources, though 'ALL ChangeGamer content' implies a broader scope than a resource-only search.
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.