Return corpus stats: total/free/premium counts, per-category counts, tag count, newest/oldest update dates, the 10 most recently updated resources, feed URLs — plus an editorial block (guide count, words, newest publish) merged at runtime from the static articles index. A small freshness/size signal to poll before deciding whether to re-ingest.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. It is transparent about the runtime merge from the static articles index and frames the output as a lightweight freshness signal. It does not mention cost, caching, or failure modes, but that is less critical for a parameterless stats endpoint.
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 dense but well-structured, with the core purpose front-loaded and each element earning its place. The comma-separated enumeration is easily parseable, and the final sentence provides a clear, short takeaway about how to use the tool.
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 there is no output schema and no parameter schema, this description is exceptionally complete: it spells out nearly every returned component and even notes the runtime merge behavior. An agent can confidently predict what this tool will return and why it is useful before invoking it.
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 tool has zero parameters and an empty schema, so the baseline is 4. There are no parameters for the description to explain, and the description correctly focuses entirely on the return value rather than inventing parameter semantics.
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 specifies a clear verb ('Return') and a precise resource ('corpus stats') and goes on to enumerate exactly what kinds of statistics are included: total/free/premium counts, category counts, tag count, dates, recent resources, feed URLs, and an editorial block. This is detailed enough to distinguish get_stats from sibling tools like get_corpus or list_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 provides clear context: this tool returns a freshness/size signal to poll before deciding whether to re-ingest. It does not explicitly name alternatives or state when not to use it, but it gives a concrete use case that helps an agent select it correctly.
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.