Skip to main content
Glama

法令の改正履歴

law_history

Retrieve a Japanese law's amendment history to see version changes since 2017, including enforcement dates and whether each version is current, past, or not yet enforced.

Instructions

法令の改正履歴(2017-04-01 以降の版)を新しい順に返します。施行日・改正法令・現行/過去/未施行の区別。

Input Schema

NameRequiredDescriptionDefault
lawYes法令名・略称・法令ID
limitNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden and does disclose meaningful behavior beyond the schema: newest-first ordering, the 2017-04-01 coverage cutoff, and the categories returned (施行日/改正法令/現行・過去・未施行). It omits pagination/truncation behavior tied to the limit parameter, but the read-only nature is implied by 返します.

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?

Two compact, front-loaded sentences with no padding: purpose first, then ordering/scope and returned categories. Every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 2-parameter read tool with no output schema, the description covers purpose, ordering, time window, and returned field categories, which is enough to invoke it correctly. The remaining gap is the completely undocumented limit parameter, which leaves an agent unable to reason about result-set size.

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 description coverage is 50%: the law parameter is documented in the schema (法令名・略称・法令ID) but limit has no description anywhere. The description text mentions neither parameter, so it adds no semantics beyond the schema and fails to compensate for the undocumented limit/default/paging behavior.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource: it returns the amendment history of a law, in newest-first order, with a clear temporal scope (2017-04-01 onward). This is distinguishable from siblings like find_law or get_article, though it never names an alternative explicitly.

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?

Usage is only implied: an agent can infer you call this to see a law's revision history, but the description offers no when-to-use statement, no prerequisites, and no routing against siblings such as find_law or compare_article.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.