get_statsLive public numbers for whycantwehaveanagentforthis.com: total ideas roasted, live results, % told to ship, % that already exist, roast battles, and how many roasts came in via MCP. Read-only, no rate-limit cost.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It states 'Read-only' (no side effects) and 'no rate-limit cost' (performance implication), along with 'Live' indicating real-time data. This covers the key traits for a simple stats tool, though it doesn't describe response format or potential latency.
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 pack all essential info: the resource, the specific data points, and behavioral caveats. No filler or redundancy; every phrase earns its place.
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 description fully covers what the tool does and returns (list of stats), and with zero params and no output schema, there is no missing behavioral or usage information. An agent can confidently invoke this tool knowing exactly what it will get.
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?
There are zero parameters, so the baseline is 4. The description adds no parameter details but none are needed. The schema coverage is trivially 100%, and the lack of parameters means no semantics to explain.
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 this tool provides 'Live public numbers' for a specific domain, listing the exact metrics (ideas roasted, live results, percentages, roast battles, MCP roasts). This distinguishes it from the sibling tools (browse_explore, get_verdict, roast_idea), which serve different purposes.
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 makes it obvious this is the go-to tool for aggregate stats, not for individual items or actions. It mentions 'Read-only, no rate-limit cost,' implying safe use anywhere, but it does not explicitly state when not to use it or name alternatives. Clear context without exclusions.
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: browse_explore lists existing roasts, get_stats returns site-wide metrics, get_verdict retrieves a specific roast, and roast_idea creates a new roast. There is no overlap between these operations, and the descriptions reinforce the boundaries.
All tool names follow a clear verb_noun pattern: browse_explore, get_stats, get_verdict, roast_idea. The verbs are action-oriented and the nouns are logical objects, making it easy to predict what each tool does.
Four tools is well-scoped for this server's purpose: explore, retrieve, create, and stats. Each tool earns its place, and the count is neither too thin nor overly heavy for the domain.
The tool set covers the full lifecycle of the domain: browsing existing roasts, fetching a specific verdict, creating a new roast, and viewing site statistics. There are no obvious dead ends or missing core operations.