Retrieves session-level search statistics such as cache usage, source priors, documentation drift, and search counts to help agents inspect search behavior and diagnose ecosystem state.
Wnętrze ekosystemu: cache, prior, drift, liczba wyszukań w sesji.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full burden: it must establish that this is a read of internal state, whether counters reset on read, whether values are per-session or global, and what shape the data takes. It does none of this. The noun list implies an internal-state inspection and hence a read-only operation, but that is inference, not disclosure.
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?
It is short, but the brevity comes from under-specification rather than economy — a colon-delimited fragment with no subject or verb. A handful more words stating what is reported would cost little and remove the ambiguity. Nothing is padded, but nothing is front-loaded either, since there is no main clause to front-load.
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 output schema, no annotations, and no parameters, the description is the only channel for understanding the result, and it delivers a word list instead of a contract. An agent cannot tell whether the response is scalar counters, nested objects, or prose. For a zero-argument introspection tool this is the one place the return description was mandatory.
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 takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. No parameter-level meaning is missing because no parameters exist.
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 is a bare noun list ("cache, prior, drift, session search count") with no verb, so it never states what the tool actually does with those things — read them? reset them? aggregate them? It hints at the subject matter of "stats" but only broadens the name into adjacent nouns rather than specifying an operation. Siblings such as web.drift_report, web.cache, and web.drift overlap these same concepts, and nothing here distinguishes web.stats from them.
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?
There is no when-to-use guidance, no when-not-to-use, and no reference to any of the twelve sibling tools. An agent seeing this next to web.cache, web.drift, and web.drift_report has no basis for choosing one over another. The listed terms arguably overlap three siblings, making the ambiguity worse rather than better.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.