Short catalog of common HTTP status codes.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | HTTPS URL to normalize or cite | |
| host | No | Public hostname | |
| json | No | JSON text to validate; discarded after the check | |
| zone | No | IANA timezone name |
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?
annotations为空,所以描述负有完全披露责任。除了说明这是一个“short catalog”外,没有提供任何行为细节:未说明返回格式、查询限制、是否执行网络请求、是否写入数据等。对工具行为的可预测性帮助有限。
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?
描述简短直接,仅一句话,没有冗余;内容聚焦在工具核心用途上。
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?
工具无output schema、无annotations,仅有的描述没有说明查询结果的结构、对参数的处理方式或与其他工具的分工,信息不足以支撑代理可靠地选择并调用此工具。
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覆盖率为100%,四个参数都在schema中有描述,因此描述无需补充参数含义。但描述也没有额外提供任何参数使用细节,如格式要求或关联关系,只能给中等偏基础分数。
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?
描述直接且具体地说明“Short catalog of common HTTP status codes—util解析,便于快速了解工具的用途。虽然清晰,但工具名本身已高度自描述,描述对其帮助有限,且与兄弟工具的区分度没有说明。
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?
描述只暗示了一个用途方向(查询HTTP状态码),但完全没有说明在什么场景下优先选择此工具,与citation/compatibility等其他get_类型工具的区别未透露,缺少使用时机的指引。
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 operate on URLs and return overlapping metadata (citation vs normalize-url vs compatibility), and timezone overlaps with tz-australia-sydney. While descriptions add detail, an agent could easily select the wrong tool for host/status or local-time tasks.
Tool names mix single nouns (citation, timezone), hyphenated noun compounds (domain-shape, status-catalog), and verb_noun commands (inspect-robots, validate-json). There is no consistent verb_noun or resource_action pattern, making the surface feel ad hoc.
Eleven tools is not inherently too many, but for a server named 'Australia/Sydney clock' the majority of tools are unrelated URL/HTTP/JSON utilities. The set would be better split into a clock server and a web-metadata server.
The time-related surface is reasonably complete with UTC, named timezone, Sydney time, and a zone catalog, but notable gaps remain such as timezone conversion and offset information. The URL/HTTP tools cover several metadata operations but lack obvious related operations, so overall domain coverage is uneven.