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

Discloses key behaviors: uses fresh data (ignores cache), updates baseline unless save=false. With no annotations, description fully covers behavioral context. Could mention side-effect of baseline update more prominently.

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 concise sentences front-load the action and provide essential usage guidance. Every sentence contributes value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and one parameter, the description sufficiently defines behavior and return content. Lacks structured output details, but the description is adequate for an agent to form expectations.

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 description repeats the schema's description for the 'save' parameter without adding new meaning. 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 clearly states the tool compares current academic status with last review and returns specific changes (new tasks, grades, delivery status, dates). It distinguishes from siblings by focusing on change detection rather than single-purpose retrieval.

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?

Explicitly recommends the tool for answering 'Is there anything new?' and periodic checking. Provides clear context, though does not explicitly mention when to avoid it or alternatives.

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 discloses that it requires prior captured data and alerts if data is missing. It implies read-only behavior, though it does not explicitly state side effects or permissions.

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 core functionality, then use case and prerequisite. Every sentence adds value without redundancy.

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?

Covers essential aspects: purpose, prerequisite, and usefulness. Lacks details on output format or error handling, but sufficient for a zero-parameter comparison tool.

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?

No parameters exist, and schema coverage is 100%. The description adds no parameter details, which is acceptable given zero params; baseline 4 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 clearly states it compares weighted averages from SISACAD and Moodle course by course, distinguishing from the capture tool (dutic_get_sisacad_grades) by explicitly requiring prior capture.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

It explains when to use (detect sync issues) and a prerequisite (prior capture with dutic sisacad), but does not explicitly mention when not to use or compare to alternatives like dutic_get_grades.

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 provided, so the description carries full burden. It lacks behavioral details such as whether files are overwritten, authentication requirements, error handling, or side effects. Only states action and URL types.

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 concise sentences with no wasted words. The main action and key detail on URL types are front-loaded.

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 straightforward tool with 2 required parameters and no output schema, the description is adequate but incomplete. It does not mention the tool's output (e.g., success message or file path), nor error cases or permissions.

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 description adds meaning for the 'url' parameter by specifying acceptable URL types (module view URL or pluginfile.php URL), which the schema only describes as URI. The 'destPath' parameter remains minimally described ('local destination path'). Schema coverage is 50%, so description partially compensates.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool downloads a file from the virtual classroom to a local path, specifying acceptable URL types. Distinguishes from siblings like dutic_read_resource (inline reading) and dutic_fetch_page (page fetching).

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?

Provides context on when to use (to download files) and acceptable URL formats, but does not explicitly exclude alternatives or mention when not to use. Siblings are distinct enough.

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 full burden. It discloses that it downloads pages with the active session, returns content, and is restricted to the host. It implies read-only behavior but does not mention potential rate limits or what happens if the session is expired. Still, it provides adequate transparency 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?

The description is concise yet packed with information: main action, examples, format details, and usage guidance. Every sentence adds value without fluff. It is well-structured with front-loaded purpose.

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?

No output schema exists, so the description should hint at return format. It mentions formats and that it returns content, but does not detail the structure of the returned data. However, given the simple fetch nature and the format enum providing clues, it is mostly complete. Could mention error handling or session state requirements.

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 33% (only 'url' has description). The description compensates by explaining the 'format' parameter options ('text', 'html', 'links') and their intended use. 'maxChars' is mentioned only by schema default without elaboration, but the overall parameter meaning is clear enough for usage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool downloads any page from the virtual classroom using the active session and returns its content. It lists specific use cases (profiles, courses, forums) and distinguishes itself from sibling tools by stating it is for exploring things other tools don't cover.

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?

Explicitly tells the agent to use this tool when the user wants to investigate something not covered by other tools or to discover IDs. It also notes the restriction to the host domain, providing clear context for when to use vs alternatives.

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 provided, so description carries the burden. It details behavior: returns most recent access across courses, shared flag logic, and limits to real courses. Safe read operation implied.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is verbose with many field details and usage examples. Front-loaded with purpose, but could be more concise (e.g., separate return details).

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?

Despite no output schema, the description comprehensively lists return fields and use cases. Sufficient for an agent to understand what the tool provides.

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% with a minimal description of 'query'. The tool description adds nuance about partial name/email but does not significantly expand on parameter meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool searches for a person by name or email across all user's courses, with specific return fields. It distinguishes from siblings like list_participants by searching across 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?

Explicitly lists example queries ('¿quién es X?') but does not mention when not to use or alternatives, though the context is clear from sibling tool names.

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. It discloses key behavioral details: returns specific fields (dateConflict, datesInDescription), and instructs on handling date discrepancies. It does not mention authentication or side effects, but the tool appears read-only and the description is transparent about its output.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, with four sentences that are front-loaded with the main purpose and key details. Every sentence adds value: listing contents, highlighting important fields, providing usage guidance. No redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple input schema (one parameter) and no annotations, the description is highly complete. It covers all necessary aspects: what the tool does, what it returns, special fields handling, and when to use it. It also references a sibling tool for reading attachments, providing a complete context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, providing a brief description for the single parameter 'cmid'. The tool description adds context by connecting cmid to assignment identity but does not elaborate on format or usage beyond the schema. This meets the baseline for high coverage.

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 explicitly states that the tool returns all assignment details: instructions, attachments, dates, submission status, grade, and grader. It uses a specific verb ('devuelve') and resource ('tarea'), and distinguishes itself from sibling tools like dutic_read_resource.

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 clear usage context: 'Úsalo cuando el usuario pregunte qué pide una tarea o cuándo se entrega.' It also instructs to alert the user if dateConflict is true. It does not explicitly state when not to use it, but the guidance is sufficient.

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?

Without annotations, the description must carry the full behavioral burden, but it only describes what is returned. It does not disclose whether it is read-only, requires authentication, or any other behavioral traits. The agent gets no information about side effects or constraints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, clear sentence that effectively communicates the tool's purpose. While it could include more structured details, it achieves conciseness without wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the absence of an output schema and only one parameter, the description is too sparse. It does not explain the structure of the returned data (e.g., nested sections, fields per module), leaving significant uncertainty for the agent.

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 description does not mention any parameters. With 0% schema description coverage, the agent must rely solely on the schema, which only provides type and min value for courseId. No additional meaning or format hints are given.

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?

Clearly states it returns sections and modules (tasks, resources, forums) of a course, using a specific verb and resource. It distinguishes well from sibling tools like dutic_get_course_tasks (which only returns tasks) and dutic_list_course_materials (which may have different scope).

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?

Provides no guidance on when to use this tool versus alternatives. No mentions of use cases, prerequisites, or exclusions, leaving the agent to infer optimal usage from context 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?

No annotations exist, so the description bears full responsibility for behavioral disclosure. It reveals that hidden tasks are included (hidden=true), which is a useful behavioral trait. However, it does not specify whether the operation is read-only, requires authentication, or has any side effects. The lack of a readOnlyHint or destructiveHint means the agent must assume unknown risk.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no unnecessary words. It conveys the core purpose and key behavioral detail (hidden tasks) efficiently. While it could benefit from a bit more structure (e.g., a brief note on input format), it remains appropriately concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has only one parameter, no output schema, and no annotations, the description is somewhat complete for a simple list operation. It explains what tasks are retrieved (including hidden ones). However, it omits information about output format, potential pagination, or whether the list is ordered. This is adequate for a minimal tool but leaves some gaps.

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% – the schema has no descriptions for its sole parameter 'courseId'. The description mentions 'de un curso concreto' but does not explain what the courseId represents (e.g., 'the numeric course ID from the course list'). With zero schema documentation, the description should fully compensate, but it does not, leaving the parameter semantics unclear.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Lista' (lists) and the resource 'tareas de un curso' (tasks of a course), with the added detail of including hidden tasks. This is specific and distinguishes from siblings like 'dutic_list_tasks' which likely has broader scope. However, it does not explicitly compare to siblings, so it is strong but not perfect.

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 guidance is provided on when to use this tool versus alternatives such as 'dutic_list_tasks' or 'dutic_get_assignment_detail'. There are no use cases, exclusions, or prerequisities mentioned, leaving the agent to infer context from the name 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?

The description discloses the tool's approach: combining contacts, roles, and the grader's name—including a note that the grader method 'usually works in this classroom' (indicating a heuristic). With no annotations provided, the description carries the full burden and gives meaningful insight into the algorithm and its reliability.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences long, front-loaded with the primary purpose, and contains no filler. Every sentence earns its place: the first states what it does, the second tells when to use it.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the low complexity (single parameter, no output schema), the description adequately covers the tool's algorithm and usage. It could optionally describe the expected return format (e.g., list of teacher names) to be fully complete, but the current content is sufficient for 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?

The single parameter 'courseId' is self-explanatory from its name, but the description does not add any additional semantic information (e.g., format, source, validation). Since schema description coverage is 0%, the description should compensate, but it does not elaborate beyond what the parameter name implies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool identifies teachers of a course by combining multiple data sources (contacts, roles, grader). It uses a specific verb+resource ('identifica docentes del curso') and distinguishes itself from siblings like 'dutic_list_participants' or 'dutic_get_grades' which serve different purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description explicitly says 'Úsalo cuando el usuario pregunte quién es su profesor de un curso' (use it when the user asks who their teacher is), providing clear usage context. It does not mention when not to use it or alternatives, but the unique purpose implies it's the correct tool for that query.

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, description carries full burden. It discloses functional behavior (two modes) but omits authentication, error handling, or side effects. Adequate for a read tool but not comprehensive.

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?

Description is concise: two functional sentences plus a usage sentence. No unnecessary words, front-loaded with key info.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one optional param, no output schema), the description sufficiently explains both invocation patterns and return content. Minor gap: no mention of error cases.

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% with a parameter description that mirrors the tool description. No additional meaning beyond what schema provides. Baseline score 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 clearly states it returns user grades and distinguishes two modes based on courseId presence. However, it does not explicitly differentiate from sibling tools like 'dutic_get_sisacad_grades'.

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?

Includes explicit usage guidance: 'Úsalo cuando el usuario pregunte por sus notas, promedio, o cómo va en un curso.' But lacks when-not-to-use or alternatives.

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 must cover behavioral traits. It mentions batch capability and auto-course lookup, but does not state whether the operation is read-only, safe, or if any destructive side effects exist. It is adequate but could be more explicit.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single paragraph that is front-loaded with the most important information (profile fields, auto-course, batch). It is concise with no redundant text, though it could be slightly more structured with bullet points for clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description covers the key return fields and the auto-course behavior. It is mostly complete for a profile retrieval tool, though it lacks details on error handling or authentication requirements.

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 description adds meaning beyond the schema: it explains the batch use for userId arrays with a max of 50, and clarifies that courseId is optional with an automatic fallback. This compensates for the schema's 50% description coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool gets a user profile by userId, including specific fields like name, email, role, time zone, and courses. It distinguishes from siblings by specifying details not covered in other tools like 'dutic_find_person' or 'dutic_list_participants'.

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 explains the automatic course discovery feature when courseId is omitted, which guides usage. However, it does not explicitly mention when not to use this tool or compare it to alternatives like 'dutic_find_person'.

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 fully bears the burden of transparency. It states that the tool only reads pre-saved data, does not open browsers, and does not access third-party data. It also describes the return structure (course items with grades, weight, absence, and weighted average), providing full behavioral insight.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, consisting of three sentences. The first sentence states the main purpose, the second explains the behavior and return elements, and the third provides usage guidance for empty data. Every sentence adds value, and the description is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (no parameters, no output schema), the description is complete. It covers purpose, the underlying system, behavioral traits, return structure, and fallback instructions. No additional information is needed for an agent to use this tool 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?

The tool has zero parameters (schema coverage 100%), so the baseline is 4. The description adds meaning by detailing the returned data structure (parcial, nota, peso, ausente, weightedAverageSoFar), which compensates for the lack of parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool returns official partial grades from SISACAD, differentiating it from sibling tools like dutic_get_grades. It specifies that it reads data already captured by 'dutic sisacad', which is a separate system requiring CAPTCHA. This provides a specific verb and resource, and distinguishes from other tools.

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 explains that the tool only reads already saved data and does not open a browser or access third-party data. It also instructs the user to run 'dutic sisacad' on the terminal if no data exists. While it doesn't explicitly list alternative tools or conditions when not to use, it gives clear context and a fallback action.

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. It does not explicitly state whether the operation is read-only, requires authentication, or any limits on returned data. The implication of 'lista' suggests a read operation, but behavioral traits are insufficiently disclosed.

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 that is concise and front-loaded. There is no redundant or extraneous information; every part earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and a single parameter, the description minimally conveys that the result includes download URLs. However, it lacks details on result structure (e.g., whether it includes file names, sizes), pagination, or ordering, leaving gaps for an AI agent to infer 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?

Schema description coverage is 0%, and the description adds no meaning to the sole parameter 'courseId'. It does not explain its purpose, format, or where to obtain it, leaving the agent to rely solely on the integer type and exclusiveMinimum constraint in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists downloadable files/recursos of a course, including download URLs. It uses a specific verb 'Lista' and resource 'archivos/recursos descargables de un curso', effectively distinguishing it from siblings like dutic_download_file and dutic_list_course_materials.

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 provides no guidance on when to use this tool versus alternatives, nor any conditions or prerequisites. It simply states what it does without context for selection among sibling tools like dutic_download_file or dutic_read_resource.

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. It discloses the tool's behavior: it lists files, expands folders, and returns name, URL, section, and folder. It implies a read-only operation but does not explicitly state that no data is modified. The behavioral transparency is adequate but could be strengthened by confirming it is a read-only, non-destructive action.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured. It front-loads the main action in the first sentence, then lists return fields, and provides usage guidance. Every sentence adds value with no redundant or extraneous information. It is appropriately sized for the tool's complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given there is no output schema, the description appropriately mentions the return fields (nombre, URL, sección, carpeta). The tool has only two parameters and is a simple listing operation. The description could mention potential error cases or pagination, but it is sufficiently complete for typical use. It provides enough context for an agent to understand what the tool offers.

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 50% (only the `section` parameter has a description in the schema). The description adds context for `section' ('Con `section` filtras a una unidad concreta') reinforcing its filtering purpose. For `courseId`, no additional detail is provided beyond the schema's type and constraints. The description adds some value but does not fully compensate for the missing schema description of `courseId`.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: listing all downloadable files of a course, expanding folders into real files (slides, readings, etc.). It identifies the specific verb ('Lista'), resource ('archivos descargables de un curso'), and scope (expanding folders). This distinguishes it from sibling tools like dutic_list_course_files which might not expand folders, and dutic_get_course_contents which is likely structural.

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 provides explicit usage guidance: 'Úsalo para saber qué materiales hay, y por qué unidad, antes de leer o descargar.' It explains when to use the tool (before reading or downloading) and how to filter with the `section` parameter. While it does not explicitly state when not to use it or name alternatives, the context is clear enough for an AI agent to infer appropriate usage.

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 is the sole source of behavioral information. The description is straightforward but minimal; it does not mention any side effects, permissions, or limitations beyond the basic 'lists courses you are enrolled in.' For a simple read-only tool, this is adequate but not comprehensive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, focused sentence that communicates the essential information without any unnecessary words. It is front-loaded with the main action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no parameters, no output schema, and is a straightforward listing operation, the description adequately covers the necessary information. It explains what is returned and the scope (enrolled courses). No additional details are needed.

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 are zero parameters in the input schema, and schema coverage is trivially 100%. The description does not need to add parameter information. The baseline for zero parameters 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 clearly states the action (list), the resource (courses), and the scope (enrolled courses). It also specifies the returned fields: id, name, teachers. This differentiates it from sibling tools like dutic_get_course_contents or dutic_list_tasks.

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 provides no guidance on when to use this tool versus alternatives. It lacks context on when it is appropriate to call this tool, such as prerequisites or cases where other tools should be preferred.

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 present, so the description carries the burden. It discloses pagination handling ('recorriendo la paginación'), the group visibility limitation, and the performance impact of the withEmail option ('más lento'). Missing details on error conditions or idempotency, but adequately covers key behaviors.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences: one longer sentence listing functionality and a clarifying note on groups. Information-dense without fluff, though slightly verbose in the first sentence. Still concise and well-structured for a non-trivial 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?

Given the complexity (pagination, group visibility, optional email) and lack of output schema, the description covers use cases, caveats, and returned fields. It is sufficient for an agent to decide when to invoke and what parameters to use.

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 50% (only withEmail has a description). The description adds meaning: explains that withEmail resolves institutional email and is slower. For courseId, no additional context beyond schema type and range. It partially compensates for the coverage gap but does not add detail for the required parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb (list) and specific resource (participants of a course), with explicit attributes returned (name, role, group, last access, optionally email). It differentiates from sibling tools like dutic_find_person or dutic_get_course_teachers by focusing on all participants with pagination and group context.

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 provides clear context: use it to know who classmates are or determine a person's group. It also warns about separated groups limiting visibility. However, it does not explicitly state when not to use or list alternative tools for specific scenarios.

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 must disclose behavioral traits. It mentions speed differences but does not state whether the operation is read-only, requires authentication, or has any side effects. Crucial safety info is missing.

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?

Three front-loaded sentences concisely state purpose and scope behaviors without wasted words. Efficient and clear.

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?

Despite 3 parameters and no output schema, the description does not explain the return format, pagination, or what fields are included in results. With no annotations to supplement, this is a significant 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 coverage is 67% (detailed and onlyHidden have descriptions). The description adds useful context for the 'scope' parameter but does not elaborate on the other parameters beyond what the schema already says. This meets the baseline for high coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists tasks from the virtual classroom, specifying two scopes ('upcoming' and 'all') and their behaviors. However, it does not explicitly distinguish this tool from siblings like 'dutic_get_course_tasks' or 'dutic_list_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?

Provides guidance on when to use each scope (e.g., 'upcoming' is fast, 'all' includes hidden tasks) but no direction on when to prefer this tool over alternatives or when not to use it.

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 provided; description notes 'sin gastar tokens en el binario' and 'No requiere sesión de Moodle,' which are helpful. It does not disclose error handling, file size limits, or whether the PDF is left unmodified. Score 3 as it adds some but not full context.

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?

Three concise sentences cover the core function, optional output, and authentication context. Every sentence adds value; no fluff. Could be slightly more structured, but effective.

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 conversion tool with no output schema, the description covers the main purpose, input, optional output, and token-saving benefit. It lacks details on return format but maxChars parameter partly addresses output control. Overall adequate.

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% with descriptions. The description adds that outPath optionally saves the result, but this is already in the schema. No additional semantics beyond the schema are provided.

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?

Description clearly states it converts a local PDF to Markdown/text, distinguishing it from sibling tools that deal with grades, courses, files, etc. The verb 'convertir' and the resource 'PDF a Markdown' are specific.

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 mentions 'No requiere sesión de Moodle,' which clarifies when to use (no session needed). It implies use when you have a local PDF and want to save tokens. However, it does not explicitly state when not to use or provide alternatives.

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 full burden for behavioral disclosure. It states the tool downloads files to a local directory and returns saved files with sizes, but does not address key behaviors such as overwrite policy, error handling, authentication requirements, or handling of large courses. Minimal context beyond basic action.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence in Spanish that efficiently communicates the action and output. No unnecessary words or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that the tool has 3 parameters, no output schema, and no annotations, the description is too minimal. It lacks details on recursive downloads, error behavior, file size limits, and progress indication. For a bulk download operation, the description is incomplete for an agent to fully understand the tool's behavior.

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 67% (destDir and section have descriptions, courseId lacks one). The description mentions 'a un directorio local' and 'todos los archivos/recursos' hinting at destDir and courseId, but does not explain destDir path requirements, permissions, or that courseId is required. It adds little value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool downloads all files/resources of a course in bulk to a local directory and returns a list with file sizes. The verb 'descarga en bloque' and resource 'todos los archivos/recursos de un curso' are specific and distinguishable from siblings like dutic_download_file (single file) and dutic_list_course_files (listing only).

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 explicit guidance on when to use this tool versus alternatives is provided. However, the description implies bulk download, and siblings such as dutic_download_file for single files and dutic_list_course_files for listing suggest contrasting use cases. The lack of direct 'when to use' or 'when not to use' statements limits the score.

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 burden. It discloses key behaviors: downloads, returns Markdown, converts PDFs, avoids token spend on binary, warns for unsupported types, and accepts specific URL formats. It lacks mention of authentication or rate limits but is generally transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise—three sentences that front-load the core purpose (download, Markdown, no token waste) and add detail without redundancy. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (2 params, no output schema), the description covers essential aspects: what it does, supported file types, limitations, and URL formats. It could mention the maxChars truncation behavior explicitly, but the parameter description provides that.

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 50% (only maxChars has a description). The description adds value by clarifying the 'url' parameter accepts module view URLs or pluginfile.php paths, which is not in the schema. This context helps the agent understand valid inputs.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool downloads a course resource and returns its content as Markdown, specifying that it converts PDFs automatically and avoids token waste. It distinguishes itself from siblings by mentioning unsupported binaries and suggesting an alternative.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description explicitly advises to use this tool when the user wants analysis, summarization, or extraction from course materials. It also notes limitations for unsupported binaries. However, it does not explicitly contrast with sibling tools like 'dutic_download_file' or 'dutic_pdf_to_markdown', leaving some ambiguity.

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?

Discloses that the refresh relies on Google SSO being alive and that failure requires manual login. No annotations, so description carries full burden; it does so adequately.

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 concise sentences, front-loaded with key action, no redundancy.

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 parameterless tool with no output schema or annotations, the description fully explains purpose, behavior, and error handling.

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?

No parameters exist, and schema coverage is 100%. Description offers no parameter info, but baseline for zero parameters 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 clearly states the tool renews a session without interaction, distinguishing it from sibling tools like dutic_session_status (status check) and dutic_login (interactive login).

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?

Explains when to use ('sin interacción') and provides fallback action if it fails. Does not explicitly state when not to use, but context is clear.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It describes the tool as read-only and specifies the outputs: session validity, semester, and expiration date. While it does not mention side effects or rate limits, for a simple status check this is adequate and does not contradict any annotations (none provided).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with no redundant information. Every word adds value, making it concise and easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no parameters and no output schema, the description fully covers its functionality and expected output. It tells the agent exactly what information the tool returns (session validity, semester, expiration), making it complete for this simple tool.

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 has zero parameters, so the description needs no parameter explanation. Baseline score of 4 applies as per guidelines, as the description adds no parameter semantics beyond what is inherent to a no-parameter tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool indicates session validity, the current semester, and expiration date. It uses a specific verb ('Indica') and identifies distinct resources (session, semester, expiration), distinguishing it from sibling tools that deal with grades, courses, or other data.

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 implies the tool is used to check session status, likely before performing other operations, but it does not explicitly state when to use it or when not to. No alternatives are provided, but the purpose is clear enough for an agent to infer its role as a prerequisite check.

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

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

With no annotations, the description carries full burden. It discloses key behaviors: downloading, converting PDFs, organizing in folders, and returning a manifest. However, it does not mention permissions, overwrite behavior, or handling of non-PDF files.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the main action and is concise (two sentences). Every sentence adds value, with no wasted words.

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 tool of moderate complexity (multi-step, no output schema, no annotations), the description covers the main purpose, usage scenario, and key feature (section filtering). Gaps include error handling and prerequisites, but overall it provides sufficient context.

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 67% (two of three parameters have descriptions). The description does not add extra parameter information beyond the schema, so 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 clearly states the tool downloads all course materials, converts PDFs to Markdown, and returns a manifest. It distinguishes itself from sibling tools like dutic_download_file and dutic_pdf_to_markdown by combining these actions and adding organization by folder.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description explicitly says to use this tool when the user wants to 'preparar/bajar el material para estudiar' and explains the section parameter for partial downloads. It does not list alternatives or exclusions, but the context is clear enough.

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 provided, so description must inform about behavior. It mentions returning profile but omits details like authentication requirements, error cases, or that it is a read-only 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?

Single, concise sentence that front-loads the purpose and output fields. No superfluous words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, description lists three return fields (name, email, id). Missing details on error handling or format, but sufficient for a simple tool.

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?

No parameters; schema coverage is trivially 100%. According to guidelines, 0 parameters warrants baseline 4. No additional semantics needed.

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?

Clearly states the tool returns the user's own profile with specific fields (name, email, id). Distinguishes from siblings like dutic_get_person_profile which likely fetches others' profiles.

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?

Implies usage when the agent needs the current user's profile. Does not explicitly exclude other tools, but contextually clear given the name and sibling list.

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