Liveness + freshness — host, total docs, earliest, latest. No auth required.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
| 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?
The description adds meaningful context beyond the annotations: it explicitly states that no authentication is needed and enumerates the returned fields (host, total docs, earliest, latest). This is consistent with the readOnlyHint and idempotentHint annotations, and it supplements the output schema with a clear summary.
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 exceptionally concise, using a single phrase and one short sentence. Every word contributes to understanding the tool's purpose and output, with no filler or redundant information. It is well-structured and front-loaded.
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?
For a simple health-check tool with no parameters and an existing output schema, the description covers the essential aspects: what it returns and the auth requirement. It is sufficiently complete for an agent to select and invoke the tool correctly, though it could optionally explain 'liveness' and 'freshness' more explicitly.
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, so there are no parameter semantics to clarify. The description does not need to add parameter-related information, and the baseline for 0-parameter tools is 4. The description adds no conflicting or redundant parameter details.
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 conveys that the tool provides liveness and freshness metrics, listing the specific fields (host, total docs, earliest, latest). While it lacks an explicit verb like 'check' or 'get', the purpose is unambiguous and distinct from sibling tools. The 'No auth required' note further clarifies its role.
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 mentions 'No auth required', which is a useful access condition, but it does not explicitly state when to use this tool versus alternatives. The health-check purpose is implied by the name and content, but no direct comparison or exclusion of other tools is provided.
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.
Several tools overlap significantly: fillin_query, glyph_search, and retrieve_auto all perform post-cutoff retrieval and differ only in output substrate, and fillin_health and fillin_stats both report corpus stats. This creates ambiguity for agents choosing between them.
Tool names mix three conventions: fillin_* (fillin_query, fillin_mint), query_* (query_cves, query_papers), and bare names (encode, glyph_search, retrieve_auto). While readable and mostly snake_case, the lack of a uniform prefix or verb pattern makes naming inconsistent.
14 tools is within the acceptable range for a multi-feature server, but there is some redundancy (two health/stats tools, three retrieval variants), making the count feel slightly inflated.
The server covers retrieval (text/glyph/auto), encoding, marketplace operations (mint, search, buy), and domain-specific queries (CVEs, frontier AI, markets, papers), with no obvious missing capabilities.
