Get degree program curriculum structure

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

With no annotations, the description carries the burden of disclosing behavior. It reveals the fallback resolution of the newest StuPO/semester when omitted and notes that data comes from Moses. It does not discuss caching behavior (though the refresh parameter implies it) or error conditions, but the core behavioral traits are transparently stated.

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 two sentences, immediately front-loaded with the primary purpose. It includes concrete examples and a clear next-step reference without any fluff or redundancy. Every sentence 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 explains the output scope (curriculum areas with module/credit counts) and the fallback resolution, which is essential for using the tool. However, without an output schema, it could more precisely specify the exact structure of the returned data, but the description is sufficient for basic invocation and interpretation.

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?

The schema already provides 100% coverage with descriptions for all parameters. The description adds value by explaining the omission behavior for stupo/semester and how the returned values should be used with list_area_modules. This goes beyond the schema's basic descriptions, enhancing the agent's understanding of parameter relationships.

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 clearly states the tool's function: retrieving curriculum areas (Pflichtbereich, Wahlpflichtbereich, Wahlbereich, Bachelorarbeit) for a degree program under a specific StuPO and semester, including module/credit counts. It distinguishes itself from siblings by focusing on the structural overview and explicitly referencing list_area_modules for module-level detail.

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?

It provides explicit usage guidance: when StuPO/semester are omitted, it resolves the newest available data; and it directs the user to use the returned values with list_area_modules for module-level details. This clearly communicates when to use this tool and how it fits into the workflow with sibling tools.

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