get_judgment

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

No annotations provided, so description carries the burden. It discloses the tool is 'Live from SAOS' (network dependency) and 'not legal advice' (user-facing caveat). But it doesn't disclose behavioral traits like response size, pagination, error handling for invalid ids, or rate limits despite being a live fetch.

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?

Front-loaded with the core purpose in the first clause, then efficiently enumerates return fields. The field enumeration is slightly verbose but useful. Second sentence adds context. Approaching appropriately compact given the informational payload.

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 single-param fetch tool, the description covers purpose, id provenance, return fields, and caveats. No output schema exists, so the description's enumeration of return content (judges, decision, summary, legal bases, referenced_regulations) compensates well. Slight gap on error/not-found behavior but adequate.

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 coverage is 100% for the single param 'id' with description 'SAOS judgment id.' The description adds the crucial context that this id comes from search_case_law and is a SAOS identifier, enriching the schema meaning. For a single well-documented param, this is solid.

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?

Specific verb 'Fetch' + clear resource 'single Polish court judgment' identified by SAOS id. Clearly distinguishes from siblings by explicitly referencing search_case_law as the source of the id, and lists detailed return content. Purpose is unambiguous.

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?

Tells the agent the id comes from search_case_law, establishing usage context. Notes it's 'Live from SAOS' and 'not legal advice'. However, doesn't explicitly contrast against siblings like find_judgments_for_provision or caselaw_about, nor give when-not-to-use guidance.

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