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.

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

With no annotations, the description carries the full burden and does well by disclosing the returned fields and the critical behavior that omitting version resolves the current version. It also surfaces the usedInPrograms list as a key output. It could mention caching or error behavior, but the schema's refresh parameter already hints at data sourcing.

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 front-loaded with the action and object, then packs field details, use case, and version behavior into two additional sentences. Every sentence earns its place with no filler or unnecessary elaboration.

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 provides a comprehensive view of the tool's output in the absence of an output schema, enumerating most return fields. It also gives the intended use case and default version resolution, making it sufficient for the tool's simplicity. Sibling tools add context, but the description stands alone well.

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 description coverage is 100%, providing clear descriptions for moduleNumber, version, and refresh. The description mostly re-states the version default already present in the schema ('If version is omitted, resolves the current version') and adds no new parameter-level meaning, so the baseline of 3 is appropriate.

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 opens with a specific verb and resource ('Get a module version's full description') and enumerates exact fields returned, including the unique 'usedInPrograms' list. It clearly distinguishes from sibling tools by focusing on detailed module data rather than degree program searches or module listings.

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?

The description explicitly states when to use the tool: 'Use this to answer what other majors could take this module.' It also clarifies the version default behavior. It does not explicitly mention when not to use it or name alternative tools, but the use case is strong enough for guidance.

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

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

With no annotations, the description carries full responsibility for behavioral disclosure. It explains output fields and suggests client-side filtering, which adds useful context. However, it does not mention the local caching mechanism exposed via the 'refresh' parameter, potential side effects away from read-only retrieval, or error behavior, leaving some behavioral traits undisclosed.

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 composed of three sentences that front-load the main action and include helpful examples. It is efficient but slightly dense due to parentheticals and multiple clauses, so it loses a point for not being as crisp as possible.

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 read-only list tool with no output schema, the description covers the key return fields, prerequisite calls, and intended usage patterns. It lacks detail on pagination, error cases, and caching behavior, but given the tool's simplicity, it is nearly complete.

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%, so the baseline is 3. The description adds meaningful context by telling users to get StuPO and semester from get_degree_program_structure and by clarifying the 'area' parameter with examples, going beyond the raw schema definitions.

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 specifies the action ('List') and the resource ('modules assigned to one curriculum area of a degree program'), with concrete examples of area names. It also distinguishes itself from siblings by referencing get_degree_program_structure as the source for required parameters, making the tool's specific role 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?

The description states that StuPO and semester should be obtained from get_degree_program_structure first, giving clear context for when to use this tool. It also advises filtering results client-side. However, it does not explicitly mention alternatives like search_modules for global module searches, so exclusions are not fully spelled out.

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

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

With no annotations, the description carries the transparency burden. It discloses return fields and the id's role, but omits behavioral details such as caching (despite a refresh parameter) and search matching rules (case sensitivity, partial matches). This provides moderate transparency but leaves some important behavior unspecified.

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?

Two sentences with no filler. The purpose and key outputs are front-loaded, making it highly efficient and easy to scan. 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 is complete enough for a search tool: it names the resource, provides examples, and lists return fields. It doesn't mention pagination or caching behavior, but given the absence of an output schema and the simplicity of the tool, this is a minor gap.

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 input schema covers all 4 parameters with descriptions, so the baseline is 3. The description adds only redundant examples (e.g., 'Informatik') and restates that search is by name, providing little additional semantic value beyond the schema.

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 action ('Search TU Berlin Moses degree programs') with a specific resource and examples. It also lists the exact return fields, distinguishing it from the sibling search_modules by focusing on degree programs and noting the id is needed by get_degree_program_structure.

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 clear usage context: search by name to get program ids for use with get_degree_program_structure. It doesn't explicitly mention when not to use it, but the relationship to the sibling tool is well implied. No competing alternative is mentioned, but the context is sufficient for most cases.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It lists the returned fields (module number/version, title, language(s), credits, grading, responsible person, organizational unit), which is helpful, but omits limitations like result count, pagination, or the partial-match behavior for titles (only described in the schema). No contradictions with annotations.

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 three concise sentences, front-loaded with the core purpose, then the use case, then return fields, and finally an alternative tool. Every sentence earns its place with no redundant content.

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 lack of output schema and annotations, the description covers the main purpose and return fields, but misses important operational details such as partial title matching, caching/refresh behavior (beyond the schema), and any limits on result size. It is adequate but not fully complete for confident tool selection.

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 describes all three parameters with 100% coverage, so the baseline is 3. The description adds a small amount of context for the 'query' parameter (title or exact module number) but does not add meaningful semantics for 'refresh' or 'semester' beyond the schema.

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 'searches TU Berlin Moses modules by title or exact module number,' with a concrete example ('Computer Vision'). It also distinguishes itself from get_module_details by noting when to use the latter for full descriptions and degree program information.

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?

The description gives explicit context: 'Useful for discovering/recommending modules by topic' and directs users to use get_module_details for full descriptions and degree programs. However, it lacks an explicit 'when not to use' statement for other sibling tools like search_degree_programs or list_area_modules.

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