obs_public_registration_termFind the current term as reported by the registration system, accounting for lag behind the published schedule. No login required.
Return the term the registration system reports as current, which lags the published schedule. No login required.
| Name | Required | Description | Default |
|---|---|---|---|
| level | No | LS |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.2.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It usefully discloses the lag behavior and the lack of an auth requirement, but it doesn't describe failure modes, caching, or what happens when no term data is available. It is adequate for a simple public read, but not rich.
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 a single front-loaded sentence with no filler. It states the core action first, then the key behavioral caveat, then the authentication requirement. Every word 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 covers the basic action, auth requirement, and temporal behavior, and an output schema exists to explain the return shape. However, the undocumented 'level' parameter and the lack of an explicit pointer to the related obs_public_active_term leave meaningful gaps for an agent trying to invoke the tool correctly.
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 description coverage is 0%, and the description never mentions the only parameter, 'level,' or its default 'LS.' An agent cannot determine what values are valid or how they affect the returned term. The description entirely fails to compensate for the schema's lack of parameter meaning.
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 uses a specific verb and resource: 'Return the term the registration system reports as current.' It also differentiates this tool from the published-schedule concept via 'lags the published schedule,' which is relevant given the sibling obs_public_active_term. It does not explicitly name the sibling, but the semantic distinction is clear.
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 conveys when this can be used through 'No login required' and implies a timing caveat with 'lags the published schedule.' However, it does not explicitly say when to use this tool instead of obs_public_active_term or other public registration tools, nor does it state exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.