tos_watch_timeline
Time-ordered events only for a ToS document (the differentiator: when it appeared and each revision since). Includes firstSeenAt and ledgerVerified.
Input Schema
TableJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| itemId | Yes |
mcp-revenue-empire — Japan public-data ledgers
TDQS
A3.6/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions 'time-ordered' and 'includes firstSeenAt and ledgerVerified', implying a read operation, but does not explicitly state read-only behavior or side effects. The behavioral traits are partially disclosed but not comprehensively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences that front-load the core purpose and include key differentiators. Every word adds value without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description partially describes return fields (firstSeenAt, ledgerVerified) but lacks full structure (e.g., event types, timestamps). The tool's complexity is low (one parameter), so completeness is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no description for 'itemId'), and the tool description does not explain the parameter beyond context ('ToS document'). No format or usage hints are given, so the description fails to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly defines the tool's purpose: retrieving time-ordered events for a ToS document, specifically focusing on firstSeenAt and ledgerVerified. This distinguishes it from sibling tools like tos_watch_get (current state) and tos_watch_search (search). The verb 'timeline' implies retrieval, and 'differentiator' adds specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for timeline queries ('Time-ordered events only') but does not explicitly state when to choose this over siblings like tos_watch_get or tos_watch_search. No exclusions or alternatives are mentioned, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Try in Browser
Glama MCP Gateway
Add one secure layer between your agents and this server.
TDQS
B3.1/5.0
Disambiguation4/5
Most tools are clearly distinguished by domain prefixes (e.g., bid_watch, grant_watch) and specific action verbs. However, the high number of similarly structured watch tools could still cause confusion, though descriptions clarify exact purposes.
Naming Consistency5/5
Every tool follows a consistent `domain_subdomain_action` pattern with underscores, e.g., `agent_audit_query`, `bid_watch_search`. Even long names like `commerce_catalog_agent_readiness_score` adhere to this structure.
Tool Count2/5
With 147 tools, the server is far too broad, covering weather, carbon estimates, domain intel, and more—well beyond its stated 'Japan public-data ledgers' scope. This sheer volume overwhelms agents and dilutes focus.
Completeness3/5
The server offers many read-only tools for Japanese public data (bids, grants, licenses, etc.), but lacks create/update/delete operations for those domains. Additionally, numerous unrelated tools (e.g., carbon estimates, weather) feel tacked on, leaving gaps in core coverage.