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. "Mengambil" implies a non-mutating read, and the parenthetical usefully discloses what the response contains (jumlah tugas aktif belum dikerjakan, evaluasi, materi, pengumuman) in the absence of an output schema. However, it does not state whether results are scoped to the authenticated user, whether login is required first (despite elearning_login being a sibling), or whether the numbers are cached/refreshed.

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 sentence with the resource stated first and the indicator list in a compact parenthetical. Every clause earns its place and nothing is padded or restated from the title.

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-parameter, no-annotation, no-output-schema tool, the description covers the essential question of what comes back by naming the four indicator groups. The remaining gap is the return shape (are these counts, objects, or labels?) and any auth/session precondition, which keeps it just short of 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?

The tool takes zero parameters and the schema is an empty object, so there is nothing for the description to disambiguate. Baseline of 4 applies; the description correctly signals that no arguments are needed by describing a pure aggregate retrieval.

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 ("Mengambil" - retrieve) with a precise resource ("ringkasan indikator dashboard E-Learning ITG") and enumerates the four indicator categories it aggregates. That enumeration implicitly distinguishes it from the detail-oriented siblings such as elearning_list_tugas and elearning_get_materi, since this returns counts/summaries rather than records, though no sibling is named 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?

Usage is only implied: an agent can infer this is the overview/landing call before drilling into tugas, materi, or pengumuman. There is no explicit when-to-use or when-not-to-use statement, no mention that a session/login is a prerequisite, and no named alternative for agents that want per-item data.

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 provided, the description carries the full disclosure burden. 'Mengambil' implies a read-only operation, but it says nothing about authentication requirements (a sibling login tool exists), whether the result reflects the current semester, or what an empty schedule looks like. Given the zero-parameter simplicity, this is a moderate gap rather than a critical one.

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 that names the action, the resource, and the returned fields with zero filler. Nothing is wasted and nothing important is buried.

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 simple no-argument read tool with no output schema, the description covers what is fetched and what the response contains. It stops short of mentioning login dependency or empty-state handling, but those are minor for a tool of 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?

The tool takes no parameters, so the baseline is 4. The description usefully confirms the implicit scoping — the schedule is for the logged-in student and is weekly — which is the only semantic an agent could otherwise misunderstand.

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 plus resource ('Mengambil jadwal perkuliahan mingguan mahasiswa') and even enumerates what the schedule contains (jam, ruangan, dosen pengampu). This clearly separates it from sibling tools like elearning_list_tugas or elearning_get_khs, though it does not explicitly name those alternatives.

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 it should call this to obtain the student's weekly class schedule. There is no explicit statement of when to prefer it over the dashboard tool or what preconditions (e.g. being logged in) apply.

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 and it largely does not meet it. "Mengambil" implies a read, but the description says nothing about authorization requirements, whether results are scoped to the logged-in student, whether the call fails or returns all semesters when the parameter is omitted, or what the response contains beyond a generic list of grades.

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 that names the returned artifacts without padding. Nothing is redundant against the name or schema, and it is sized appropriately for a one-parameter read tool.

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 simple read with one optional parameter and no output schema, naming the returned content (KHS, grades, SKS) covers the essentials. However, with zero annotation coverage the description should have addressed the authentication context and the no-parameter default, both of which materially affect correct invocation.

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 enum-like examples ('1', '2', 'Ganjil', 'Genap') are already documented in the schema. The description adds only the framing that the record is per-semester; it does not clarify the default behavior when the optional semester is omitted, which is the one piece of meaning the schema leaves open.

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 ("Mengambil" = retrieve) with concrete resources: Kartu Hasil Studi, grade list, and SKS credits per semester. That is enough to separate it from siblings like elearning_get_jadwal or elearning_get_materi, though it never explicitly names those alternatives.

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 the resource itself: an agent can infer this is the tool for exam results rather than schedules or assignments. There is no explicit when-to-use/when-not guidance, no mention of whether elearning_login is a prerequisite, and no statement about what happens if the tool is called before authentication.

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 burden; it usefully discloses that results include download links for uploaded files, which is behavior beyond the tool name. However, it says nothing about authentication requirements, pagination, ordering, or whether results are scoped to the logged-in student.

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; it states the resource and the return content efficiently. Slightly more value could be packed in without sacrificing brevity.

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 simple read-only list tool with one optional parameter and no output schema, the description adequately conveys what is returned (materials plus file links). The main omissions are pagination and auth context, which are minor for this complexity level.

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 optional mapel_id parameter is already documented in the schema as an optional course-ID filter. The description adds no further parameter detail such as behavior when the filter is omitted, 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?

The description names a specific verb and resource: retrieving a list of lecture materials uploaded by lecturers, including file download links. This clearly separates it from siblings like elearning_list_tugas (assignments) or elearning_get_jadwal (schedule), though it does not explicitly reference any 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 guidance on when to use this tool versus alternatives such as elearning_get_tugas_detail or elearning_get_dashboard. Usage is only implied by the word 'mengambil' (retrieve), with no stated prerequisites, exclusions, or routing hints.

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 burden, and it does add real behavioral value by disclosing the return contents and decoding the 'status 2' face-photo authorization lock semantics. However, it never states that the operation is read-only, whether authentication/session is required, or what happens for an invalid or inaccessible tugas_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?

It is a single front-loaded sentence with no filler, and the most decision-relevant element (the upload-lock check) is included rather than buried. The sentence is somewhat dense with three stacked clauses, which slightly reduces scannability.

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 one-parameter read tool with no output schema and no annotations, the description covers what the agent needs: what comes back and the meaning of the lock flag. The remaining gap is the absence of any statement about auth/session requirements or failure behavior, which is modest given the tool's simplicity.

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% for the single parameter tugas_id, so the schema already explains it fully. The description adds no format, range, or sourcing guidance (e.g., where to obtain the ID) beyond what the schema provides, making the baseline 3 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 names a specific verb ('Mengambil') and resource ('rincian instruksi tugas'), and enumerates the payload: instruction details, lecturer attachment files, and a lock/face-photo authorization flag. This clearly separates it from sibling elearning_list_tugas (listing) and elearning_submit_tugas (submission), though it never names those siblings 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 explicit when-to-use or when-not-to-use statement, and no prerequisites are given. The mention of checking whether uploads are locked implies the natural pre-submission check flow, but the agent must infer that this tool should be called before elearning_submit_tugas rather than being told so.

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 burden. "Mengambil" implies a safe read, and the returned fields are listed, but nothing is said about authentication requirements, result volume/pagination, or whether the list is scoped to the logged-in student or spans all courses. Adequate but with clear gaps for an unannotated 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?

One well-formed sentence with the action front-loaded and the return payload compactly enumerated; nothing is wasted. It could be slightly stronger if it added a routing clause toward the detail tool.

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?

A simple read tool with one optional parameter and no output schema; the description covers the action and the fields returned, which is most of what an agent needs. The absence of authentication and scoping context is the remaining shortfall.

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 mapel_id parameter is already documented as an optional course-ID filter, so the schema does the work. The description adds no filter semantics beyond what the schema states, which is the baseline-3 case.

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 ("Mengambil daftar tugas kuliah mahasiswa") and enumerates the returned fields (deadline, mata kuliah, dosen, status pengerjaan), so the agent knows exactly what it gets. It does not distinguish itself from the sibling elearning_get_tugas_detail, so it falls 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?

No when-to-use or when-not-to-use guidance. The word "daftar" (list) hints that this is the bulk-listing counterpart to elearning_get_tugas_detail, but that contrast is never made explicit, and there is no mention of prerequisites such as needing to authenticate via elearning_login first.

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. It does add genuinely useful behavior beyond the schema: the session token is stored automatically in client memory, telling the agent that state persists across later calls. It omits failure behavior (bad credentials), token lifetime, and whether concurrent logins invalidate the session.

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 action and target, followed by the session-storage note. No filler, though no structure is given for multi-step auth.

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-optional-parameter login tool with no output schema, the definition covers who/where/how and where the token goes. It stops short of error conditions and session lifetime, which an agent invoking it in a multi-step itinerary would benefit from.

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 both parameters already document that they are optional when set in .env, so the description adds no syntax or 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?

States a specific verb and a concrete target: authenticating to elearning.itg.ac.id with NIM/Username and Password. That clearly separates it from the data-retrieval siblings (dashboard, tugas, jadwal), though it never names them or describes the relationship 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?

The purpose implies this must run before the elearning_* data tools, but the description never says so or states whether re-login is needed after token expiry. Usage is inferred from the tool name rather than guided.

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 a genuinely non-obvious behavior: the automatic black-frame bypass sent to foto_siswa when the task is in the webcam-required state. However it omits whether the submission is final/irreversible, what happens on failure, and any auth/session prerequisites that 'menyelesaikan pengumpulan' implies.

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 core action first and the conditional bypass behavior after, with no filler. It is compact for a mutation tool with a conditional side effect.

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 3-parameter mutation tool with no annotations and no output schema, the description covers the main action and the unusual bypass path, but leaves the agent without knowledge of return values, failure modes, or whether the submission can be retried.

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 tugas_id, file_path, and bypass_photo are already well documented, including the default and the status-2 trigger condition. The description adds no parameter-level detail 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 and resource ('Mengunggah berkas jawaban tugas mahasiswa ke sistem') and adds the distinguishing twist that it also finalizes submission, which separates it from elearning_submit_tugas_link. It never names that sibling explicitly, so the differentiation is inferred from the word 'berkas' 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?

There is no explicit when-to-use guidance and no reference to any alternative. An agent must infer from the name alone that this is for file uploads while elearning_submit_tugas_link is for URL/link submissions, and nothing tells it which conditions require which.

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, and it does disclose one important side effect: submission automatically marks the collection status as complete. It does not say whether resubmission is allowed, whether the link is validated, or whether the deadline blocks submission.

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 sentence containing verb, resource, example values, and the automatic-completion side effect, with no filler. It is front-loaded on the action, though the parenthetical example list is slightly long.

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 mutation tool with full schema coverage and no output schema, the definition covers purpose, expected input form, and the one significant side effect. What is missing is failure behavior (invalid links, closed deadlines) and its relation to the file-submission 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 coverage is 100%, so the baseline is 3, and the description adds useful semantics by clarifying what values 'link' should contain (Drive/GitHub/YouTube URLs) and that 'tugas_id' comes from the assignment list. The mapping to 'item.id' is stated in the schema rather than the description, so added value is modest.

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 and resource ('Mengunggah tautan jawaban tugas mahasiswa') and gives concrete examples of link types (Google Drive, GitHub, YouTube). It does not explicitly differentiate itself from the sibling 'elearning_submit_tugas', which likely submits a file rather than a link, so an agent must infer the split.

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 purpose statement – use this when the student's answer is a URL rather than an uploaded file – but there is no explicit when-to-use/when-not statement and no mention of prerequisites such as being logged in or the assignment still being open. The alternative 'elearning_submit_tugas' is never named.

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