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

No annotations are supplied, so the description carries the full disclosure burden. It does establish that the search spans all faculties and is restricted to elective/selective course types, which is meaningful behavioral scope, but it says nothing about ordering, truncation behavior, or the fact that this is a passive read that changes no state.

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?

A single front-loaded sentence with no filler. The parenthetical gloss of "volitelné - category C" is the one added detail and it earns its place by disambiguating a term an agent would otherwise not know.

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?

An output schema exists, so return values need not be explained and all three parameters are documented in the schema. Still, for a tool whose nearest neighbours are get_enrolled_courses and get_course_details, the description should have made the catalogue-vs-enrolled distinction explicit; that omission is the main completeness 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?

Schema description coverage is 100%, so the schema already documents query, faculty, and limit with examples, and the baseline of 3 applies. The description adds only the domain context that results are elective/selective courses reachable across all faculties; it adds no syntax or format guidance 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 names a specific verb pair ("search and discover") and a specific resource scope (elective category C / volitelné and selective courses across all faculties). It is clear what the tool returns conceptually, but it never names or distinguishes itself from siblings such as get_enrolled_courses or get_course_details, so an agent must infer that this is catalogue discovery rather than enrolled-course listing.

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?

Usage is implied by the framing as discovery of elective and selective courses, which tells an agent roughly when this tool is relevant. However, there is no explicit when-to-use/when-not-to-use statement and no pointer to alternatives (e.g. use get_course_details for a specific course, get_enrolled_courses for what the student already takes), leaving the routing decision to inference.

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?

No annotations are supplied, so the description carries the full behavioral burden. It does disclose a genuinely non-obvious trait: the tool returns either a student profile or setup instructions instead of erroring, which is useful. It says nothing about side effects, whether it touches the network or session state, or what an agent should do with the unauthenticated branch.

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, front-loaded with the purpose and followed by the outcome branches. No filler, no repetition of the title, nothing that could be cut.

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?

An output schema exists, so return values need not be spelled out, and the zero-parameter schema makes this a low-complexity tool. The description covers purpose and both outcome modes; the only real gap is not pointing to set_session_cookies as the recovery action, which would have made it fully self-sufficient.

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 tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly does not waste space re-explaining an empty 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 opens with a specific verb and resource ("Check whether the IS MU client is authenticated") and then names the two possible outcomes. It is unambiguous what the tool does, though it never names a sibling such as set_session_cookies as the remedy for the unauthenticated branch, so sibling differentiation is only implicit.

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?

Usage is implied rather than stated: an agent can infer this is a precondition check to run before the other IS MU tools, and the mention of "setup instructions if unauthenticated" hints at a follow-up path. There is no explicit when-to-use/when-not-to-use statement or named alternative.

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?

No annotations are supplied, so the description carries the full behavioral burden. It discloses the substantial payload returned (syllabus, assessment rules, timetable, literature), which tells the agent this is a heavy read, but never states that it is read-only, whether authentication is required, or what happens for an unknown course code.

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?

A single front-loaded sentence with the resource stated first and the field list after, no filler or repetition. The enumeration is long but every item conveys real payload information rather than restating the name.

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 output schema exists, so return values need not be explained, and the one-sentence body is adequate for a simple lookup. However, with no annotations at all, gaps remain around side effects, auth, and the consequence of omitting faculty/semester, which for a three-parameter course lookup matters.

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%, so all three parameters, their formats and examples are already documented in the schema; baseline 3 applies. The description adds nothing about the parameters themselves, notably it never clarifies how the optional faculty and semester narrow or disambiguate the lookup.

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 uses a specific verb ('Get') plus resource ('full course details') and enumerates exactly what is returned: syllabus, objectives, instructors, assessment rules, timetable, literature. That enumeration alone separates it from catalogue-browsing or enrolled-course siblings, 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance and no mention of alternatives such as browse_course_catalogue (discovery) or get_interactive_syllabus / get_enrolled_courses, which a reader could easily confuse with this lookup. The agent must infer that this is the single-course detail call from the description of returned fields alone.

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. 'Retrieve' implies a read-only operation, and the embedded /auth/ URL usefully signals that an authenticated IS session is required — real information beyond the name. It stops short of stating what happens when unauthenticated (relevant given the set_session_cookies and check_auth_status siblings) or any pagination/result-size behavior.

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?

A single front-loaded sentence with no filler; the core action leads. The appended URL is compact and carries the auth-signal payload rather than being redundant padding, though it is marginally less useful than a plain statement of the authentication prerequisite.

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?

An output schema exists, so return shape need not be described, and the lone parameter is fully documented. What remains missing is the prerequisite chain — whether the agent must have a session established first — and any disambiguation from the catalogue/course-detail siblings, which matters in a toolset this crowded.

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%: the single optional 'semester' parameter is fully documented in the schema with examples ('jaro2026', 'podzim2026') and default behavior. The description adds nothing beyond that, so the baseline of 3 applies.

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?

States a specific verb and resource: 'Retrieve all enrolled courses for the student', which tells an agent exactly what data comes back. It does not, however, distinguish itself from siblings like get_course_details or browse_course_catalogue, so an agent must infer that this is the enrollment-scoped list rather than a catalogue search or per-course detail lookup.

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 no when-to-use guidance, no exclusions, and never names an alternative among the ~20 sibling tools. The only implicit signal is 'for the student', suggesting current-user scope, but nothing tells the agent when to prefer this over browse_course_catalogue or get_course_details.

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?

No annotations are supplied, so the description carries the full behavioral burden. 'Retrieve' signals a read-only operation and the enumerated content suggests a broad aggregate read, but there is nothing about authentication, whose data is returned (self vs. all students), or whether omitted parameters cause auto-discovery lookups. 'Capacities' and 'enrolled reservations' are left undefined, which matters for interpreting results.

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?

A single front-loaded sentence with no filler; every listed item is a concrete data category. Slightly weakened by loosely defined list items ('capacities', 'enrolled reservations') that add breadth without precision.

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?

An output schema exists, so return formatting need not be explained, and both parameters are optional and fully documented. What is missing is the scoping and selection context an agent needs: how this differs from adjacent read tools and whether results are personal or term-wide. Adequate but with clear gaps for a tool sitting among many overlapping read siblings.

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%, so term_id's semester semantics and study_id's auto-discovery behavior are already documented in the schema. The description adds no meaning beyond that — it never mentions term scoping or the default-to-active-semester behavior. Baseline 3 applies when the schema does the heavy lifting.

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?

States a specific verb ('Retrieve') and resource ('examination dates'), then enumerates the content areas: midterm test slots, enrolled reservations, capacities, deadlines. That is far more specific than the name alone. It stops short of a 5 because it never distinguishes this from siblings like get_registration_timeline or get_student_timetable, which plausibly overlap.

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?

There is no when-to-use guidance, no exclusions, and no named alternative. An agent cannot tell from this description whether exam dates belong here or in get_registration_timeline/get_student_timetable, nor that both parameters are optional and auto-resolved. Usage must be inferred entirely from the tool name.

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 behavioral burden, yet it does not say whether authentication/session cookies are required (relevant given the set_session_cookies and check_auth_status siblings), whether results span all enrolled courses or only the current term, or whether the returned set is bounded. The parenthetical domain term 'poznámkové bloky' is the only added context, and return values are covered by the output schema.

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?

One front-loaded sentence with no filler, leading with the verb and the returned resource set. The untranslated Czech term in parentheses is minor domain clarification rather than wasted text.

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?

This is a simple one-optional-parameter read tool with a full output schema, so return-value documentation is not needed. What remains missing is only peripheral: authentication expectations and how to choose this tool over its siblings.

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% and the single optional course_code parameter is already documented in the schema with an example. The description adds no meaning about how the filter interacts with results (e.g. what is returned when omitted), so the baseline applies.

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 uses a specific verb ('Fetch') with a concrete set of resources: evaluation records, test points, homework scores, and grades from course evaluation notebooks. An agent can tell this is a grades/evaluation retrieval tool rather than an email, timetable, or course-catalogue tool, though it never names the nearest sibling (get_study_credit_summary, get_study_progress_check) to draw a hard boundary.

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?

There is no when-to-use or when-not-to-use guidance and no mention of alternatives among the 21 siblings. The agent must infer from the resource name alone whether this or get_study_credit_summary / get_study_progress_check is the right call for a given question.

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?

No annotations are supplied, so the description carries the full behavioral burden. It does disclose the returned payload content, notably that direct upload URLs come back, which is a meaningful trait for an agent about to upload. However, it says nothing about authentication/session prerequisites (relevant given the check_auth_status and set_session_cookies siblings), whether upload URLs expire, or whether the listing is paginated or complete.

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?

A single front-loaded sentence with no filler; the highest-value elements (vaults, instructions, upload URLs) appear immediately after the verb. Nothing would be lost by leaving it as is.

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 tool is simple (one required parameter) and the output schema already documents return values, so the description needn't explain them. Still missing is the operational context an unannotated tool should provide: that a valid session is required and how this relates to the submit_homework_file sibling.

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%, so course_code, faculty, and semester are already documented with defaults and an example format. The description adds only the implicit "for a course" scoping and no extra semantics for the faculty or semester slugs, so the baseline 3 applies.

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?

Uses a specific verb ("List") with the resource spelled out in three parts: homework submission vaults (odevzdávárny), assignment instructions, and direct upload URLs, scoped to a course. The Czech term in parentheses helps an agent match local terminology. It stops short of explicitly differentiating itself from submit_homework_file, the adjacent write-side sibling.

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?

There is no when-to-use guidance, no mention of prerequisites, and no named alternative. An agent must infer that this is the discovery step before calling submit_homework_file, and that it applies only to homework-type vaults versus other course resources.

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?

No annotations are supplied, so the description must carry the behavioral burden: it does state what the tool returns, but it omits authentication requirements, behavior when a course has no interactive syllabus, and whether the course must be enrolled. An output schema exists, so the omission of return-value detail is acceptable. The gaps around permissions and failure modes still matter for a read tool on a session-authenticated system.

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 tool definition is a single tightly written sentence. It leads with the action and resource, then lists the concrete payload contents. There is no redundant or filler wording.

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?

Because an output schema exists, the definition need not describe return values. It is still thin on whether the tool requires authentication, how it behaves for a course without a syllabus, and whether the tool uses the optional faculty or semester parameters for disambiguation. It is adequate overall but not complete for a multi-parameter, session-authenticated lookup.

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%, so all three parameters are already documented, and the description adds nothing beyond the schema. It does not mention the optional faculty or semester parameters, nor does it explain how they affect the lookup.

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 uses a specific verb ('Fetch') plus a precise resource ('interactive syllabus / interaktivní osnova') and enumerates the content it returns: a week-by-week topic outline, homework assignments, reading tasks, and linked lecture resources. This clearly distinguishes it from tools such as get_course_details or list_study_materials. It does not name a sibling to contrast with, however.

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 usage is only implied by the described content, and the description gives no explicit instruction on when to choose this tool over get_course_details, list_study_materials, or browse_course_catalogue. There are also no stated prerequisites (for example, enrollment or authentication via set_session_cookies, which a sibling tool provides).

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?

No annotations are supplied, so the description carries the full disclosure burden. It does convey scope ('across all university faculties') and the kinds of data surfaced, but says nothing about authentication requirements, whether results are cached or live, or freshness of the dates, which matter for a registration-deadline tool.

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 short sentences, front-loaded with the resource and scope. The second sentence largely enumerates return fields rather than adding new guidance, which is mild redundancy given an output schema exists.

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 optional-parameter read tool with a full output schema and 100% schema coverage, the description covers purpose and data scope adequately. The missing piece is authentication/freshness context, which is a minor gap rather than a blocking one.

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%, and the single term_id parameter is documented with a default and an example alternate value. The description never references term selection, so it adds no meaning beyond the schema; the documented baseline of 3 applies.

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 names a specific verb ('Retrieve') and resource ('course registration waves, enrolment periods, and change periods'), plus the attribute set returned (student credit standing, registration shift, exact opening dates). That is enough to distinguish it from siblings like get_exam_dates or get_student_timetable, though it never explicitly contrasts with them.

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?

Usage is only implied: an agent can infer this is the tool for registration/enrolment timing questions. There is no statement of when to prefer it over get_study_credit_summary for credit standing, no exclusions, and no prerequisite 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 the full burden; it does disclose the backing endpoint (/auth/mail/) which hints at session authentication, and it enumerates returned attributes. It never states that the operation is read-only, that a valid session/cookie is required (siblings check_auth_status and set_session_cookies suggest this matters), or how ordering and pagination behave.

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?

One front-loaded sentence with a clear verb and scope, no filler or hedging. The enumeration of returned fields ('read/unread flags, sender, date, and subject') is somewhat redundant given an output schema exists, which is the only real waste.

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 two-parameter read tool with a full output schema, the core purpose is covered and return values need no explanation here. However, with zero annotation coverage the description should have addressed auth/session requirements and result ordering or pagination, both of which are absent and relevant given the sibling tools.

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%, so both limit and folder are already fully documented including defaults and allowed folder values. The description adds no meaning beyond the schema – it never mentions filtering by folder or capping results at all, so baseline 3 applies.

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?

States a specific verb ('Retrieve') and resource ('message list from university email') plus the endpoint path, which clearly separates it from single-message or send siblings. It does not name read_email_message or send_student_email explicitly, so the differentiation is inferred rather than stated.

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?

Usage is only implied by 'message list' – an agent can guess this is the listing counterpart to read_email_message, but the description never says when to use this versus those siblings or what prerequisites apply. No exclusions or alternatives are named.

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?

No annotations are supplied, so the description carries the full burden. 'Fetch' reasonably implies a read-only operation with no side effects, which is useful, but it says nothing about authentication or session requirements (notable given siblings like check_auth_status and set_session_cookies) or about ordering of the 'recent' notices.

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?

A single front-loaded sentence with no filler, and the parenthetical Czech term aids disambiguation. It is close to minimal, though it could have spent a few more words on scope or ordering without becoming bloated.

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 tool is simple (one optional parameter) and has an output schema, so return values need no explanation. However, with zero annotations the definition leaves auth/session expectations and recency ordering unaddressed, which is a meaningful gap for an agent operating among session-dependent siblings.

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% and the single 'limit' parameter is fully documented in the schema with its default. The description adds no additional meaning such as a maximum cap or how notices are ordered before truncation, so the baseline of 3 applies.

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 names a specific verb ('Fetch') and a concrete resource (announcements, updates, notices from the student noticeboard / nástěnka), so an agent immediately knows what data comes back. It does not distinguish itself from siblings like get_student_emails or get_interactive_syllabus, which also surface course-related communications, so the differentiation is left implicit.

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?

There is no when-to-use or when-not-to-use guidance, and no named alternative despite a large sibling set that overlaps in content (emails, syllabus, course details). The only implicit cue is the word 'noticeboard', which an agent must itself map to a selection decision.

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 must carry the behavioral burden; it does disclose the exact source URL and the shape of the data retrieved, which is genuinely useful provenance. However, it says nothing about authentication requirements (relevant given set_session_cookies and check_auth_status among siblings) or about behavior when no timetable is published. The existence of an output schema relieves it of describing return values.

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?

A single front-loaded sentence naming the resource and its contents, with no filler. The trailing source URL is somewhat operational detail an agent may not need, but it is compact and does add provenance.

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 zero-argument read tool with a full output schema, the description covers what is fetched and where from, which is nearly everything needed. The notable omission is the authentication/session prerequisite, which matters in a toolset that includes login helpers.

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 tool takes zero parameters, so there is no parameter meaning for the description to add; the documented baseline for a no-parameter tool is 4.

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 uses a specific verb ('Fetch') with a specific resource ('the student's personal timetable') and enumerates the returned content types (lectures, seminars, labs, rooms, and times), which distinguishes it from siblings like get_exam_dates and get_enrolled_courses. It never names a sibling explicitly, so it stops short of a 5.

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?

Usage is only implied: an agent can infer this is the tool for the weekly class schedule, and the absence of parameters makes misuse unlikely. There is no statement of when-not-to-use it, no pointer to get_exam_dates or get_enrolled_courses as alternatives, and no mention of any prerequisite session/auth state despite auth-related siblings existing.

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 must carry the full behavioral burden, and it adds nothing beyond the field list. It does not state whether authentication or session cookies are required (relevant given the 'check_auth_status' and 'set_session_cookies' siblings), whether the call is read-only, or what happens when a student record cannot be resolved.

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?

A single well-formed sentence that front-loads the verb and then lists the returned data. No filler or redundancy, though the enumerated field list is slightly dense for one sentence.

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?

An output schema exists, so return-value details need not be described, and the single optional parameter is fully documented in the schema. However, for a zero-annotation tool with an overlapping sibling and implicit auth/session dependencies, the definition stops short of the behavioral context an agent needs to choose and call it confidently.

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%, and the schema already explains that study_id is optional and auto-discovered when omitted. The description does not mention study_id at all, so it adds no meaning beyond the schema; baseline 3 applies.

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 gives a specific verb ('Retrieve') and enumerates the concrete resource contents: credit progress, earned credits per semester, enrolled credits, and remaining graduation credits. That distinguishes it from most siblings, but it does not explicitly separate it from the closely named 'get_study_progress_check', which an agent could plausibly confuse it with.

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?

There is no explicit when-to-use or when-not-to-use guidance, and no mention of the alternative 'get_study_progress_check'. The only implied condition is that the caller wants credit/graduation data, which the agent must infer from the field list.

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?

No annotations are supplied, so the description must carry the full behavioral burden. It partially does by disclosing that the audit runs against 'assigned monitoring templates' and by enumerating what the response reports, but it omits permission/auth requirements, what happens when no templates are assigned, and whether the audit is a heavy or rate-limited operation.

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, both front-loaded and functional: purpose first, returned data second. The only mild drag is the untranslated parenthetical and the unexplained phrase 'assigned monitoring templates', but neither is padding.

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?

Because an output schema exists, the description need not explain return values, and its stated response contents are a helpful preview. For a one-optional-parameter read tool this is close to adequate, but with zero annotations the missing note about it being a read-only audit and about template prerequisites leaves a real 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?

There is a single optional study_id parameter with 100% schema description coverage, and the schema already explains the auto-discovery fallback when it is omitted. The description adds nothing about the parameter, so the baseline of 3 applies.

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 states a specific verb and resource: 'Perform official degree audit check (Kontrola průchodu studiem)', and it names the payload the tool returns (required course groups, completed/enrolled courses, missing requirements). It is clear what the tool does, though it never names the closest sibling, get_study_credit_summary, so an agent still has to compare the two by inference.

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?

There is no explicit when-to-use guidance and no exclusions. The description never says how this official audit differs from get_study_credit_summary or get_enrolled_courses, nor does it state any prerequisite such as having monitoring templates assigned, which it implies are required.

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?

No annotations are supplied, so the description carries the full behavioral burden. The verb "List" reliably signals a non-destructive read, but nothing is said about permissions, whether folders are returned recursively, or how large listings behave. The implied read-only nature prevents a lower score, but the description stops well short of full transparency.

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?

One compact sentence with the resource front-loaded and no wasted clauses. It is efficient, though the brevity comes at the cost of the usage and behavioral detail noted elsewhere.

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?

An output schema exists, so return values need no explanation, and the tool itself is a simple two-parameter listing. However, for a tool sitting beside read_study_material, the definition leaves the agent to guess the browse-then-read workflow and any access constraints.

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%, with course_code and folder_path both documented including an example and a default. The description adds no meaning beyond that, so the baseline 3 for schema-driven parameter documentation applies.

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 pairs a specific verb ("List") with a specific resource ("files and folders in the course study materials repository"), giving the agent an immediate picture of a browsing operation. It does not explicitly contrast itself with the closest sibling, read_study_material, but the list-vs-read distinction is inferable from the wording.

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?

There is no explicit statement of when to use this tool rather than read_study_material, nor any mention of prerequisites such as enrollment or authentication. The agent must infer that listing precedes reading from the verb alone, which is a real gap given how similar the two siblings are.

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 supplied, the description carries the full disclosure burden. It does disclose the content returned (headers through body plus a download link), which is the most useful behavioral fact for a read tool, but it says nothing about authentication requirements, whether reading marks the message as read, or error behavior on an invalid mail_id.

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?

A single front-loaded sentence with no filler; the verb and resource lead and the field enumeration follows. The long field list is slightly list-like rather than structured, but every item conveys what the caller gets back.

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?

This is a simple one-parameter read tool with full schema coverage and an output schema, so return values need no explanation in prose. The description covers purpose and content retrieved; only the provenance of mail_id and any side effects of reading are unaddressed, which is a minor gap at this complexity.

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% and the single parameter mail_id is documented with a format example, so the schema does the heavy lifting. The description adds no meaning beyond it, such as where identifiers come from or whether it accepts other ID formats. Baseline 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 uses a specific verb ('Read') and resource ('full email message') and enumerates the returned content (headers, sender, recipients, date, subject, body, download link), which distinguishes it from the list-oriented sibling get_student_emails and the write-oriented send_student_email. It stops short of naming those siblings explicitly, so it's clear but not maximally differentiated.

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?

There is no explicit when-to-use guidance: nothing says this should be called after get_student_emails to fetch a specific message, nor that mail_id must come from a prior listing. The word 'full' hints that this retrieves one complete message rather than a list, but the agent must infer the workflow and the alternative.

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 it does disclose the operation mode (download plus text extraction) and the accepted input formats. However, it says nothing about authentication/session requirements (relevant given the check_auth_status and set_session_cookies siblings), network failures, or truncation behavior when limits are hit, which are meaningful for a fetch tool.

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 short sentences with the action and supported formats front-loaded; nothing is redundant. The second sentence is somewhat generic ('Allows the AI assistant to...') and could have been spent on routing or prerequisites instead.

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?

An output schema exists and all three parameters are documented, so return-value detail is not needed here. What is missing is the relationship to list_study_materials and any access prerequisites, but for a simple two-sentence fetch-and-extract tool the coverage is close to sufficient.

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%, so url, max_chars and max_pages are already documented, and the baseline is 3. The description adds only indirect meaning by naming PDF pages as an input type, which contextualizes max_pages but does not explain resolution of relative paths or what happens on truncation.

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 uses a specific verb ('Download and extract') on a specific resource ('textual content from a study material') and enumerates supported formats (PDF slides, HTML, code, TXT). It does not distinguish itself from the obvious sibling list_study_materials, so an agent must infer that this one fetches content rather than metadata.

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?

Usage is only implied through 'read lecture materials, assignments, or slides and summarize or explain them'. There is no explicit statement that list_study_materials should be called first to obtain the URL/path, and no when-not-to-use guidance or note about unsupported formats.

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?

No annotations are supplied, so the description carries the full behavioral burden, yet it says nothing about whether the search is federated across all entities, how results are ranked or capped, whether it requires an authenticated session, or what happens with an empty query. An output schema exists, so return shape is partially covered elsewhere, but the search behavior itself is 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?

A single well-formed sentence with no filler, and the verb and scope are front-loaded. Slightly more context could be added without hurting readability, but nothing present is wasted.

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?

This is a simple one-parameter tool with an output schema, so the bar is low and the description is minimally sufficient to know what it addresses. It falls short on cross-entity result behavior and any auth or result-limit context that an agent would need to interpret or sequence calls correctly.

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?

There is a single required parameter and schema description coverage is 100%, with the schema itself giving examples (teacher name, course code, topic). The description adds only marginal meaning by listing what entity types a query can target, which hints that one query spans multiple result kinds, but gives no syntax, matching, or partial-match guidance.

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 names a concrete verb ('Search') and enumerates the resource types it covers (people/teachers/students, courses, documents, publications) plus the system ('IS MU'), which is more specific than the bare name 'search_is'. It does not differentiate itself from the closest sibling, browse_course_catalogue, which also surfaces courses.

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?

Usage is only implied: the enumeration of entity types suggests this is a free-text lookup tool for when you do not already have an identifier. There is no explicit when-to-use or when-not-to-use guidance, and no mention of alternatives such as browse_course_catalogue or get_course_details for structured course retrieval.

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?

No annotations are supplied, so the description carries the full burden, yet it omits that sending mail is an irreversible external side effect, gives no error/failure behavior, no rate limits, and no indication of what happens if the UČO or attachment_path cannot be resolved. It does add one useful behavioral detail — that the message is sent from the student's university account via /auth/mail/ with optional attachments — but that is thin for a write action with an external recipient.

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?

A single tight sentence with the action front-loaded and no filler; the '/auth/mail/' path snippet is the only slightly cryptic element. Nothing is redundant, but the brevity comes at the cost of the missing guidance noted elsewhere.

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 6-parameter, irreversible outbound-send tool with zero annotations, the definition should at minimum state the authentication prerequisite and the one-way nature of sending. Because an output schema exists, return values need not be explained, but the omission of prerequisites and side-effect semantics leaves the agent under-informed.

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%, so every parameter including cc, bcc and attachment_path is already documented in the schema; the description only echoes 'optional attachments'. Baseline 3 applies because the schema does the heavy lifting and the description adds no syntax, format, or validation detail beyond it.

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 states a specific verb pair ('Compose and send') and resource ('an email') plus the originating account ('student's university account'), so the agent can tell it apart from read-only siblings such as get_student_emails and read_email_message. It does not explicitly name or exclude any sibling, which keeps it below a 5.

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?

There is no when-to-use / when-not-to-use guidance, no mention of prerequisites such as an authenticated session (despite check_auth_status and set_session_cookies existing as siblings), and no note on what to do if the send fails. The only implied guidance is the obvious fact that this is the outbound counterpart to the read-email 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 disclose a real side effect: the value is persisted to disk at ~/.config/mcp-is-muni/config.json, and three distinct input encodings are tolerated. It does not say whether cookies are validated on write, what happens on an invalid token, or whether existing values are overwritten, which keeps it from a 5.

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?

Purpose is front-loaded in the first line, accepted formats are a scannable bullet list, and the persistence note closes it out. Every line adds information; nothing is redundant.

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?

An output schema exists, so return values need no explanation, and the accepted-format and persistence details cover the main gaps for a one-parameter credential-setting tool. What is missing is failure behavior and any warning that the input is a sensitive credential, which matters for a tool with no annotations.

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 0% and the single parameter is an undescribed plain string, so the description must compensate — and it does by enumerating three accepted formats (raw Cookie header with __Host-issession/__Host-iscreds, browser-extension JSON export, single token). It adds clear meaning beyond type: string, though it does not say which format is preferred or whether the raw header must include both cookies.

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 gives a specific verb and resource (configure session cookies) plus the reason (IS MU authentication), which clearly separates it from the sibling read tools. It does not explicitly contrast itself with check_auth_status, which is the closest related tool, so it stops short of a 5.

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?

Naming the authentication purpose implies the usage context, but there is no explicit statement of when to call it (e.g. before other tools, after auth failure) or that check_auth_status is the way to verify success. The agent must infer the workflow.

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?

No annotations are provided, so the description carries the full behavioral burden. It implies a write/submission action but never states whether a submission is final or replaceable with instructors, whether deadlines or authentication are required, or that overwrite defaults to true and can silently replace an existing file — the most consequential behavior for this tool.

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?

A single front-loaded sentence with zero filler that immediately identifies the action and target. It is efficient, though its brevity contributes to the behavioral gaps noted elsewhere.

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 output schema means return values need not be explained, and the schema fully covers parameters. However, for an unannotated mutation tool with an overwrite-defaulting flag, the description should at minimum flag the destructive default and any prerequisite session/authentication state, which it does not.

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%, so all five parameters including overwrite, description, display_name and vault path already carry their own documentation and an example path. The description adds no meaning beyond the schema, so the baseline of 3 applies.

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?

States a specific verb pair (upload/submit) and a specific resource (assignment file into an IS MU homework vault or folder), including the local term 'odevzdávárna'. An agent can tell this is the write/submission tool among otherwise read-oriented siblings, though the description does not explicitly name those siblings.

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?

There is no explicit when-to-use or when-not-to-use guidance, and no pointer to get_homework_vaults as the way to obtain the vault path that the required vault_url_or_path expects. Usage is only implied by the tool name and the word 'submit'.

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