get_program_modules

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

Annotations already provide readOnlyHint and openWorldHint, so the description only needs to add non-annotation-redundant context. It does add that the result excludes courses and is cheap, which sets expectations about content and performance, but does not discuss error handling, semester interpretation, or result size.

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 sentence is front-loaded with the main resource 'Module tree of a programme or department', and the exclusion 'without any courses' is integrated right away. The phrase 'a cheap overview...' adds a little extra but does not feel padded, so the description is short and stays focused.

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?

Given the output schema and the annotations already present, the description covers the basic shape of what is returned. It is simple enough that this explanation suffices, though it could mention that program codes also correspond to department names and that the semester parameter is optional but can affect results.

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?

Input schema description coverage is 100%, and the description only restates that the program can be a programme/department name or VVZ path, which is already present in the schema. It adds no further details about the semester format or the relationship between modules and curriculum.

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 identifies the resource as a module tree and scopes it to a programme or department, and explicitly notes 'without any courses', which differentiates it from the sibling get_program_courses. It lacks an explicit verb like 'retrieves' or 'lists', so the action is not stated as directly as it could be.

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 implies when to use the tool, 'a cheap overview of how a curriculum is structured', and tells you the result contains no courses, suggesting this is the lightweight structure-level option. However, it never names the alternatives or gives an explicit when-not-to-use condition, so the guidance remains mostly inferred.

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