mcp-usc

by PabloPC05

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.3.0
Disambiguation5/5
Each tool has a clear, specific purpose, often with explicit preview/action pairs that eliminate ambiguity. Even overlapping functions like list_messages vs list_conversations are distinguished by descriptions (one is compatibility-failing, the other avoids writes). The blocked tools are clearly marked as fallbacks to the inspect flow.
Naming Consistency5/5
All tools follow a consistent snake_case verb_noun pattern, e.g., list_courses, get_my_grades, preview_submit_assignment, start_quiz. The preview_ prefix uniformly indicates a non-mutating check, and action tools use clear verbs. No mixing of camelCase or inconsistent styles.
Tool Count3/5
At 75 tools, the count is high and could overwhelm agents, but the scope is a full student-facing Moodle integration covering quizzes, assignments, forums, messaging, calendar, grades, files, and more. The extensive preview/action pairing doubles the count, which is justified by safety requirements. It feels heavy but not unjustified for the domain.
Completeness5/5
The tool surface covers nearly all student workflows: course browsing, grades, completion, assignments (with full submit/remove lifecycle), quizzes (start/save/finish), forums (discussions/replies), calendar events, messaging, notifications, badges, private files, and exam date search. Previews for every mutating action ensure safe execution, and read operations include both list and detail. No obvious dead ends or missing critical operations.
Average 3.1/5 across 75 of 75 tools scored. Lowest: 1.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description does not need to restate those. It adds a warning about a possible timeout ('Moodle puede procesar un timeout') and says the tool is 'locked/blocked', which is behavioral context beyond annotations. However, it does not disclose what happens on success or failure, what the output looks like, or any side effects (though readOnly implies none). The added context is minimal and vague, so above 1 but still weak.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one sentence), which could be concise, but it is under-specified rather than concise. It lacks any structural elements like a purpose statement or parameter overview. The single sentence is a directive to use another flow, not a description of this tool. It does not front-load useful information; it front-loads a warning that the tool is blocked.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, and the tool appears to return a summary of a quiz attempt, which is non-trivial. The description provides no information about return values, error conditions, or how this relates to sibling tools like get_quiz_attempt_review or inspect_quiz_attempt. For an agent to decide to call this tool, it would need to know what 'summary' means and what the difference is from 'review' or 'page'. The description is completely inadequate for effective selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the schema provides no descriptions for attempt_id or preflight_data. The description does not mention either parameter, so it adds no meaning beyond the raw schema. With two parameters and zero explanation, this is a critical gap that the description entirely fails to address.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is in Spanish and reads 'Blocked: Moodle may process a timeout; use the confirmed inspect flow.' It does not state what the tool does, what resource it operates on, or any verb indicating functionality. It is a warning/disclaimer rather than a description of purpose, making it impossible for an agent to know what this tool is supposed to do.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes an explicit instruction to use the 'inspect confirmed' flow instead, implying this tool should not be used. However, it gives no positive usage context—no conditions under which this tool is appropriate, no prerequisites, and no comparison to sibling tools like get_quiz_attempt_review or inspect_quiz_attempt beyond a vague alternative. It provides some guidance (do not use) but lacks a real usage scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructiveHint=true, and the description mentions 'Moodle puede procesar el vencimiento y cambiar el intento' (Moodle may process expiration and change the attempt). This hints at mutation, but it is vague and does not explain what exactly is destroyed or changed. The phrase 'Abre la vista confirmada' sounds read-only, creating ambiguity about the side effects. With annotations already flagging destructiveness, the description adds little clarity and could mislead.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but not effective. It lacks structure and does not front-load key information; the ambiguity outweighs the brevity. A good description here would be longer to cover the necessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this tool has no output schema, complex behavior (destructive), and five parameters, the description is severely incomplete. It does not explain return values, side effects, or how to use the parameters. The agent cannot safely invoke this tool based on the description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain the parameters. It fails to mention any of the five parameters (page, summary, attempt_id, preflight_data, confirmation_token) or their purpose. The agent has no help understanding what confirmation_token is for or how to supply it, making correct invocation nearly impossible.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Abre la vista confirmada' is vague; it does not clearly state that this tool inspects a quiz attempt. The name suggests the purpose, but the description does not explicitly say 'inspect' or 'attempt'. It also does not distinguish from sibling tools like get_quiz_attempt_page or preview_inspect_quiz_attempt, leaving the agent to guess what this specific tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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 the many sibling tools for quiz attempts (e.g., get_quiz_attempt_page, get_quiz_attempt_summary, preview_inspect_quiz_attempt). No context is given about prerequisites, scenarios, or alternatives. The agent is left without any direction on selecting this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions a 'write oculto' (hidden write) in Moodle, implying a write side-effect, while annotations declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. This directly contradicts the read-only annotation. Additionally, 'falla cerrado' is not explained (e.g., does it throw an error, return empty?), leaving behavior unclear. The description conflicts with structured metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The text is extremely brief, but this is under-specification rather than conciseness. It does not front-load any useful operational information; one sentence is a vague failure note and the other is a pointer to an alternative. It fails to serve the tool's own documentation purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has four parameters, no output schema, and only annotations that are contradicted, the description is drastically incomplete. It does not explain what the tool returns, how it handles parameters, why it fails, or whether it is safe to use. An agent cannot correctly invoke this tool based on the provided information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description gives no parameter details. With four parameters (limit, offset, favourites, conversation_type), the description fails to explain any semantics beyond their names, leaving the agent without additional context for building correct arguments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not state what the tool does; it only says 'falla cerrado' (fails closed) and suggests using list_messages instead. No verb or resource describes the tool's actual function, so an agent cannot infer that it lists conversations. This is closer to a warning than a purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs the agent to use list_messages instead to avoid a hidden write, providing a clear alternative and a reason. Though it advises against using this tool, it gives direct routing guidance to a sibling, which is helpful for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description contradicts the readOnlyHint annotation by stating 'Moodle may change the attempt when reading,' implying a side effect despite the read-only claim. This is a direct annotation contradiction. It also fails to disclose any other behavioral aspects, such as return format or required authentication context, leaving the tool's behavior opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise in length. However, it prioritizes a warning over functional details, making it more of a placeholder than a well-structured tool description. It is not bloated, but it is incomplete and lacks the front-loaded purpose that effective descriptions should have.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no output schema, and no schema coverage, the description must provide substantial context. Instead, it offers only a dead-end warning and a redirect. The agent has no idea what the tool actually does, how to call it, or what to expect in return, making the description completely inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description carries the full burden of explaining the three parameters (attempt_id, page, preflight_data), but it provides no information about them. There is no mention of what each parameter means, expected formats, or how they interact. The agent cannot infer parameter usage from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not state what the tool does. It only says 'Blocked: Moodle may change the attempt when reading; use the confirmed inspect flow.' This is a warning and redirect, not a definition of purpose. The name hints at retrieving a quiz attempt page, but the description fails to clarify the tool's function and even implies it is unusable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent to avoid this tool and use the 'confirmed inspect flow' instead, providing a clear alternative. While it does not describe conditions under which this tool might still be used, the strong negative guidance is unambiguous and helpful for routing the agent away from a problematic operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds no behavioral details about the tool itself—neither its operation nor its effects. The only extra info is that it is blocked, which is a status, not a behavior. It does not contradict annotations but provides no meaningful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (a single sentence), which could be praised for conciseness, but it omits essential information. The front-loaded 'Blocked' is efficient, but the rest is a redirect. It is under-specified rather than effectively concise, as it fails to describe the tool's purpose or usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no output schema, and no parameter documentation, the description is completely inadequate. It neither explains what the tool does, how it behaves, nor how to call it. The only useful content is the blocking notice and alternative pointer, but that does not make the definition complete for using this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It mentions none of the three parameters (discussion_id, limit, offset) nor any expected values or semantics. The description gives zero assistance in understanding how to populate or use the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only says 'Blocked: Moodle can mark posts; use the confirmed inspect flow.' It never states what the tool actually does (list discussion posts). It is essentially a block notice, not a purpose definition. There is no verb indicating the tool's function, and it fails to distinguish the tool from siblings based on functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent not to use this tool ('Blocked') and directs to the 'confirmed inspect flow,' which maps to sibling tools 'inspect_discussion_posts' and 'preview_inspect_discussion_posts.' This is clear when-not-to-use guidance and points to the correct alternative. However, it doesn't explain under what conditions this tool would be usable, only that it is currently blocked.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false, so the description's 'Retira' (removes) is consistent. The description adds the constraint 'solo las respuestas Choice propias aprobadas' (only your own approved ones), which provides some context, but the meaning of 'approved' and 'recent preview' is ambiguous. It does not explain what happens if the response isn't approved or if the preview is stale, nor does it disclose any side effects beyond removal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no waste, so it is concise. However, it is so brief that it omits crucial context, making it under-specified rather than efficiently structured. The sentence is front-loaded with the action but lacks supporting details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a destructive tool with three required parameters, no output schema, and no parameter documentation, the description is significantly incomplete. It does not explain the confirmation_token requirement, when the tool is valid (e.g., after a preview), what happens if cancellation fails, or any prerequisites. An agent would struggle to use this tool correctly without additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides absolutely no information about the three parameters (course_id, choice_id, confirmation_token). It does not hint at the purpose of confirmation_token (likely a confirmation mechanism) or how the IDs relate to the action. The description fails to compensate for the missing schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific action ('Retira' = remove) on a specific resource ('respuestas Choice propias aprobadas' = your own approved Choice responses), which partially distinguishes it from siblings like submit_choice_response. However, the phrase 'en la vista previa reciente' (in the recent preview) is vague and could confuse an agent about the exact scope. The purpose is clear enough but not fully precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus the sibling 'preview_cancel_choice_response' or other related tools. The description does not mention that this is the action version that should follow a preview, nor does it state any conditions for when cancellation is appropriate. Usage context is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=false, so the base safety profile is known. The description adds slight context by mentioning a confirmation requirement, but it fails to disclose side effects beyond replacement (e.g., what happens if the token is invalid, whether previous text is permanently lost). It adds only marginal value over the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single sentence with no fluff. However, it lacks structure: no parameter descriptions, no conditional information, and no breakdown of the operation. Conciseness is good, but it sacrifices necessary content, making it a bare minimum rather than a well-structured definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a destructive mutation tool with four parameters and no output schema, the description is severely incomplete. It fails to explain the confirmation token mechanism, the purpose of assignment_id versus course_module_id, or the expected behavior of the operation. An agent cannot correctly and safely invoke this tool based on the provided information alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden of explaining the parameters. It only implicitly touches on 'online_text' ('texto online') and leaves assignment_id, course_module_id, and confirmation_token completely unexplained. This is a critical gap for a tool with three required parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('replaces the online text') with a clear resource and qualifier ('exact content previously confirmed'). It implicitly distinguishes itself from the sibling preview_save_online_submission by being the actual save operation, though it doesn't name that sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not mention when to use this tool versus its preview counterpart, nor any prerequisites like obtaining a confirmation token. An agent gets zero direction on the correct invocation context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true and destructiveHint=false already cover the state-changing aspect, and the description restates this ('no la ejecuta ni cambia estado'), adding minimal value. It mentions 'permitida' (permitted) implying a permission check, but offers no further details on auth needs, rate limits, or other behavioral traits. No contradiction, but the description adds little beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no filler, and the core behavior is front-loaded. It is concise and well-structured, though it sacrifices necessary detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a generic tool with two undocumented parameters and no output schema, the description is severely incomplete. It doesn't explain how to specify the action, what arguments look like, what the preview returns, or how it differs from the many specific preview_* siblings. An agent could not correctly invoke this tool based solely on the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining the 'function' and 'arguments' parameters. It does not mention either at all, leaving the agent with no indication of what to pass. This is a critical gap for a tool with variable arguments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool previews a student action and does not execute or change state, providing a verb and resource. However, it doesn't clarify what 'student action' means specifically or how this generic tool relates to the many sibling preview_* tools like preview_submit_assignment. It also omits mention of the function parameter that selects the action, leaving ambiguity about its scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 generic preview vs the specific preview_* tools or execute_student_action. The description only states behavior, not selection criteria or alternatives, so an agent cannot decide when to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare write and destructive behavior, so the description must add context beyond that. It fails to mention the required confirmation_token workflow, what 'aprobada' means, or any side effects like irreversibility. The description adds little beyond the annotations, leaving the agent without crucial behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, succinct sentence that front-loads the action and key constraints. It wastes no words, but it omits critical information due to its brevity, so it doesn't earn a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a write operation with 6 parameters and no output schema, the description is severely inadequate. It doesn't cover the preview-confirmation flow, the meaning of 'approved', the significance of the destructive hint, or any prerequisites. An agent cannot safely and correctly invoke this tool based on the description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain parameters. It only hints at 'forum' and 'audiencia' (forum_id and group_id) but says nothing about course_id, subject, message, or especially confirmation_token. The token's purpose is completely unexplained, leaving the agent guessing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Publica' - publishes) and resource ('discusión' - discussion) for a specific forum and audience. It distinguishes itself from siblings like preview_create_forum_discussion by focusing on the actual publishing step, and from reply_forum_post by targeting new discussions. However, it doesn't explicitly name alternatives, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The mention of 'sin adjuntos' (without attachments) and 'aprobada' (approved) hints at conditions, but the description doesn't tell the agent to use preview_create_forum_discussion first to obtain a confirmation token, nor does it explain when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive. The description adds the key constraint that only whitelisted read functions are allowed, which is useful context. However, it does not explain what happens if a non-whitelisted function is requested or describe any error behavior, so it's a modest addition.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the action verb 'Ejecuta'. It has no fluff or redundant wording, though its brevity comes at the cost of information density.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with generic parameters, no output schema, and no enum constraints, the description is severely under-specified. It does not explain how to identify whitelisted functions, what arguments are expected, or what the response looks like. Given the availability of many specific sibling tools, more context is needed to justify its use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about the 'function' parameter (valid values, format) or the generic 'arguments' object. The description does not compensate for the schema's lack of detail, leaving the agent without guidance on how to construct valid calls.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool executes a Moodle function from a read whitelist, which is a specific verb+resource and does distinguish it from the many specific sibling tools (it's a generic wrapper). However, it does not clarify what functions are in the whitelist or how the agent can discover them, leaving the purpose somewhat vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it is for read-only operations (lecturas) but gives no guidance on when to use this generic tool versus the many specific sibling getter/inspection tools. No exclusions, conditions, or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the key side effect: Moodle may mark posts as read and record tracking. This aligns with the destructiveHint and readOnlyHint annotations, adding value beyond the annotations by specifying what the mutation entails. It does not explicitly address idempotency, but the side-effect disclosure is useful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and technically concise, but it is under-specified and not front-loaded with critical details (e.g., side effects, parameter meaning). It is not poorly structured, but brevity here sacrifices clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has side effects, two required parameters, no output schema, and a preview sibling, the description is woefully incomplete. It omits necessary detail about the confirmation token, side-effect conditions, and alternative tools, leaving the agent unable to safely or correctly invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate; it does not. The purpose of the required confirmation_token is entirely unexplained, and neither discussion_id nor the optional limit and offset are given additional meaning. The agent is left to guess parameter semantics from names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it reads confirmed posts, but 'confirmados' is vague and does not clearly distinguish this from the sibling tool list_discussion_posts. The name 'inspect' and the mention of side effects suggest a more thorough operation, but the description does not explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like list_discussion_posts or preview_inspect_discussion_posts. The existence of a preview sibling is not mentioned, and there is no context about prerequisites or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds that it does not publish or send notifications, and that it resolves permissions and audience, which is useful context beyond the annotations. However, it does not explain what 'resolve' entails or what the output looks like, so the added value is modest.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise and front-loaded with the key non-publication behavior. However, its brevity contributes to vagueness, so while it is well-structured in terms of length, it sacrifices clarity for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters and no output schema, this description is too sparse. It omits return value semantics, parameter details, and a concrete description of what the tool does during the 'resolve' step. An agent cannot confidently call this tool correctly based on the provided information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about the parameters. It does not explain what course_id, forum_id, subject, message, or group_id are for, leaving the agent to infer from the schema names alone. The description fails to compensate for the absence of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the vague verb 'Resuelve' (resolves/settles) without clearly stating that this is a preview/validation step for creating a forum discussion. It only contrasts with publishing behavior, but does not explicitly say what the tool does beyond checking permissions and audience. The name suggests preview, but the description does not confirm that role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies usage for non-publishing checks by stating it does not publish or send notifications, which differentiates it from create_forum_discussion. However, it does not explicitly mention the alternative or state when to prefer this over the actual create tool, leaving the agent to infer the decision.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the mutation nature is clear. The description adds the behavioral trait 'puede activar inmediatamente un temporizador' (may immediately activate a timer), which is useful and not in the annotations. However, it doesn't disclose other consequences, such as whether the attempt can be retaken or what happens if a timer already exists. Given the annotations cover the safety profile, the added timer context justifies a 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, so it is concise with no fluff. However, it is under-specified for a tool with 5 parameters and a destructive action, so the brevity is not appropriate. It could include more details while still being concise. It is not overly verbose, but it doesn't earn its place by providing useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters, no output schema, and a destructive action, the description is extremely incomplete. It provides no explanation of required inputs (confirmation_token), optional flags (force_new), or what 'previsualizado' means in practice. It lacks usage context and potential side effects beyond the timer. An agent cannot reliably invoke this tool correctly based on this description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about any of the 5 parameters (quiz_id, force_new, preflight_data, course_module_id, confirmation_token). With low schema coverage, the description must compensate but doesn't even mention confirmation_token as a required security token or explain the role of force_new. This is a critical deficiency.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: 'Inicia el intento previsualizado' (starts the previewed attempt), which clearly identifies the verb and resource (the quiz attempt). It distinguishes from related tools like preview_start_quiz by mentioning 'previsualizado' (previewed), but it doesn't explicitly name alternatives. The purpose is clear enough from the name and description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as preview_start_quiz or when not to use it. It lacks any mention of prerequisites (e.g., needing a previewed attempt) or conditions for using force_new or confirmation_token. This is a significant gap for an action that triggers a destructive change.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint: true and idempotentHint: false, which cover the finality of the action. The description adds little beyond that, only mentioning the draft is 'previously reviewed and confirmed'. It does not disclose side effects, irreversibility beyond what annotations imply, or any additional behavioral context. Since annotations carry most of the burden, the description provides marginal extra value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no waste, but it is under-specified. It earns its place for brevity but sacrifices essential information. Structure is acceptable, but the length is not appropriate for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, 2 required, destructive, no output schema), the description is woefully inadequate. It does not mention the confirmation token requirement, the accept statement, or any consequences of submission. An agent cannot reliably use this tool based on the description alone. The presence of preview_submit_assignment as a sibling also suggests a workflow that is not addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameter meaning. It does not. It fails to clarify what confirmation_token represents, what accept_submission_statement does, or how assignment_id and course_module_id are used. This is a serious gap for a tool with 4 parameters, making it impossible for the agent to understand the invocation requirements.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: submitting a previously reviewed and confirmed draft for grading. It clearly identifies the verb and resource (assignment submission) and implicitly distinguishes from preview_submit_assignment by requiring the draft to be 'reviewed and confirmed'. However, it does not explicitly name the alternative, so it's not a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should only be used after reviewing and confirming the draft, but it does not explicitly state to use preview_submit_assignment first or provide any exclusions. It offers no guidance on when not to use this tool or how it relates to other submission-related siblings like save_online_submission.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=false, so the destructive nature is known. The description adds the precondition that the attempt must be the exact one previewed, which is useful context beyond annotations. However, it doesn't clarify the 'normalmente' exception or any other side effects, so it only modestly enhances transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action and irreversibility warning. It contains no filler, but it is so brief that it sacrifices informational content for brevity, so it doesn't earn a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters (including required confirmation_token and attempt_id), no output schema, and zero parameter documentation in the description, an agent would have no idea how to properly invoke the tool. The description fails to cover essential runtime details like the confirmation_token's origin or the role of preflight_data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation of any of the 5 parameters (attempt_id, confirmation_token, time_up, responses, preflight_data). The only hint is 'intento exacto' which might relate to attempt_id, but it's too vague to meaningfully compensate for the total absence of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Finaliza') and a clear resource ('el intento exacto ya previsualizado'), making it obvious that this tool finalizes a quiz attempt. It doesn't explicitly name sibling alternatives, but the reference to 'previsualizado' distinguishes it from start_quiz or save_quiz_answers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'ya previsualizado' implies that a preview step (e.g., preview_finish_quiz) must have occurred, but there is no explicit when-to-use guidance, no mention of alternatives, and no statement of when not to use the tool. The intended usage sequence is only weakly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds no further behavioral context, such as what happens if the user has no attempts, whether it returns a number or an object, or whether it respects any availability conditions. It does not contradict the annotations, but it fails to enrich beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. The purpose is front-loaded. However, it is so terse that it omits important context, but that is a completeness issue rather than a conciseness one. As a pure structural element, it is appropriately brief and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool, the description lacks essential details: it does not specify the return format (e.g., a number, percentage, letter grade), what happens if the user has no attempts, or how quiz_id relates to course resources. With no output schema and only one parameter, the agent cannot reliably predict the tool's output or handle edge cases. The annotations cover safety but not functional completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter (quiz_id) with no description, and the schema description coverage is 0%. The description does not explain quiz_id beyond implying it refers to a quiz; it does not state that it is the Moodle quiz instance ID, how to obtain it, or any validation rules. Since the description is the sole source of parameter meaning, this is critically deficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Consulta' – consult) and the resource ('la mejor calificación propia ... para un cuestionario' – the user's best grade for a quiz). This distinguishes it from quiz attempt review/summary tools, which focus on attempts rather than a single aggregated grade. However, it could be more explicit about the exact semantics (e.g., highest across all attempts) and does not contrast with sibling tools, so it's clear but not fully differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 does not mention any prerequisites, such as needing a quiz ID from list_quizzes, or exclusions like not using it when you need attempt-level details. The agent is left to infer the use case from the purpose alone, which is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe, repeatable read. The description adds the behavioral detail that the tool 'crea referencias locales seguras', implying it may set up local caching or pointers—a useful nuance not present in annotations. However, it does not elaborate on what these references are, whether there are side effects, or any rate limits, so value beyond annotations is modest.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that front-loads the primary purpose (listing downloadable files) before mentioning the secondary behavior (creating local references). There is no fluff or redundant phrasing. However, the extreme brevity sacrifices necessary details, though that is more a completeness issue than a conciseness one.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with four parameters, no output schema, and no parameter descriptions, the description is severely incomplete. It fails to explain pagination, section filtering, the return format, or what 'safe local references' actually look like. An agent trying to call this tool correctly with non-default parameters would have no guidance, making it inadequate for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description is the only source for parameter meaning, but it mentions none of the parameters (course_id, limit, offset, section_id). It does not explain that limit/offset are pagination controls, that section_id filters by section, or that course_id is required. The description adds no parameter semantics beyond the schema, leaving the agent to guess parameter purposes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Lista') and a clear resource ('archivos descargables' of a course), and it adds the extra behavior of creating safe local references for reading. This distinguishes it from sibling tools like list_course_contents (which likely lists all content) and read_course_resource (which likely reads a single resource). However, 'safe local references' is a bit vague, leaving some ambiguity about the exact output nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as read_course_resource or list_course_contents. It does not mention that this tool should be used first to obtain resources before reading them, nor does it explain any filtering or pagination conditions. The agent is left to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states 'sin modificar su estado' (without modifying its state), which aligns with the annotations (readOnlyHint=true, destructiveHint=false). It adds the 'own attempts' scoping, which is useful context beyond the annotations. However, it does not disclose other behavioral traits such as pagination, sorting, or whether preview attempts are included by default. Given the annotations already cover read-only behavior, the description adds moderate value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence in Spanish, which is efficient and front-loaded with the action ('Lista') and resource. However, it lacks detail that could make it more informative without being verbose. It is appropriately compact, but given the parameter gap, more explicit guidance might be warranted without becoming overly long.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters, 1 required, and no output schema. The description only covers the high-level purpose without addressing how to use parameters, what the return value looks like, or any constraints. For a list tool, an agent would need to know about pagination, filtering, and what fields are returned. The description is incomplete and forces reliance on the schema, which is also sparse (0% coverage).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about the parameters. It does not explain that quiz_id is required, what valid values 'status' accepts (e.g., 'all', 'finished', 'inprogress'), or the meaning of include_previews. The agent must infer parameter semantics entirely from the schema, which has no descriptions. This is a critical gap because the tool has 4 parameters including a required one.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Lista' – lists) and a clear resource ('los intentos propios de un cuestionario' – own attempts of a quiz). It distinguishes itself by specifying 'propios' (own), which differentiates from other attempt-related tools like get_quiz_attempt_review that may inspect other users' attempts. However, it does not mention what information the list contains (e.g., attempt IDs, scores, timestamps), leaving slight ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as get_quiz_attempt_summary or inspect_quiz_attempt. It does not specify when 'status' filter is useful, when include_previews matters, or how it relates to other attempt tools. There is no mention of exclusions or scenarios where another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the explicit statement that it does not create or modify, which is consistent but not substantial additional context. It does not describe what the preview returns or any validation behavior, but the existing annotations lower the burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core purpose and side-effect free nature. It is appropriately sized with no wasted words, though it could have been expanded with parameter explanations without becoming verbose. For conciseness alone, it scores well.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool lacks an output schema, so the description should explain what the preview returns. It does not. Additionally, with no parameter semantics provided, the description is incomplete for an agent to correctly invoke the tool with appropriate argument values. Given the tool's simplicity, the description could have been more complete but leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, meaning the input schema provides no descriptive text for any of the five parameters. The description gives no explanation of what 'name', 'timestart', 'repeats', 'duration', or 'description' mean in this context. With zero parameter documentation from both schema and description, the agent is left to infer semantics from the parameter names alone, which is inadequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Previsualiza un evento personal') and explicitly clarifies it does not create or modify anything in Moodle. This distinguishes it from the actual creation tool, though it does not explicitly reference sibling tools like 'create_personal_calendar_event' or 'preview_delete_personal_calendar_event' by name. The purpose is clear and not a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 its siblings. The description only says what it does and that it has no side effects, but does not advise an agent to use it before creating an event or mention any alternatives. The sibling naming pattern suggests a dry-run, but this is not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description's download-and-extract framing is consistent with a read operation, so there is no annotation contradiction. The description adds modest context by naming the supported file formats (PDF, Office, text). However, it does not disclose truncation behavior implied by max_bytes/max_chars/max_pdf_pages, what happens on extraction failure, or the shape of the returned text — with annotations covering the safety profile, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no filler or repetition, earning strong conciseness marks. The minor structural flaw is that the vague phrase 'una referencia reciente' consumes space without adding clarity — it muddies the sentence instead of front-loading the precise object of the action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, no output schema, and 0% schema description coverage, this description is not complete enough. It omits what resource_token refers to, the meaning of 'recent reference', the behavior of the three limit parameters, and what the tool returns (presumably extracted text). An agent has to guess at these, which is a meaningful gap for a moderately complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden of explaining the 4 parameters, and it only partially does. The mention of 'PDF, Office o texto' loosely hints at why max_pdf_pages exists, but resource_token is never explained as a course resource identifier, and the limit mechanics of max_bytes/max_chars/max_pdf_pages (truncation thresholds) are undocumented in both schema and description. The compensation is insufficient for zero-coverage input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a concrete action — download a resource via HTTP and extract text from PDF, Office, or text formats — which conveys the core function. However, 'una referencia reciente' (a recent reference) is vague and never clarifies what a course resource is, and the description makes no attempt to distinguish itself from closely related siblings like list_course_resources and list_course_contents. The verb+resource is recognizable but the phrasing is ambiguous enough to land below a 4.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 the many sibling tools (especially list_course_resources, which an agent must decide against). No when-to-use, when-not-to-use, or alternative-routing information is provided. An agent must infer from the name alone that this is the tool for actually fetching resource content, which is risky.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the description's 'replaces' aligns with those. The description adds useful context beyond annotations: it specifies that the replacement is of the *exact* set of files previously confirmed, which clarifies that the operation overwrites the entire submission file set rather than incrementally updating. It also hints at a needed confirmation step (confirmation_token). However, it doesn't detail consequences like whether old files are permanently lost, or whether the operation is reversible, so it partially leverages the annotation coverage but doesn't fully expand on behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence in Spanish, which is efficient and easy to parse. It is front-loaded with the main action and object. There is no fluff or redundancy, and it fits the expected pattern for a tool description. Slightly higher would require providing more structure (like separating purpose from usage), but for what it is, it's well-shaped.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has three required parameters, a destructive action, and no output schema, so the description carries a heavy burden. It only states the high-level action and the 'exact set' constraint, but it omits critical details: what constitutes a valid file path, how the confirmation_token is obtained or validated, whether there are constraints on assignment_id, and what the response indicates (success, errors, etc.). The presence of a preview tool (preview_replace_submission_files) suggests a workflow, but this description doesn't connect to it. For an agent to call this correctly, far more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description must compensate by explaining the parameters. It does not: file_paths, assignment_id, and confirmation_token are never mentioned or elaborated. The phrase 'previously confirmed' loosely alludes to the confirmation_token, but it doesn't name it or explain how to obtain it. The description adds zero value for parameter understanding, leaving the agent reliant on parameter names alone for semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Sube y reemplaza' – uploads and replaces) and the resource ('el conjunto de archivos exacto previamente confirmado' – the exact set of files previously confirmed). It distinguishes from siblings like preview_replace_submission_files (which previews) and delete_submission_files (which deletes) by focusing on replacement, and the 'previously confirmed' qualifier adds specificity. However, it doesn't explicitly name alternative tools or edge cases, so it's not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 does not mention prerequisites, such as obtaining a confirmation_token from a prior step, nor does it reference the preview tool (preview_replace_submission_files) as a recommended precursor. Without any context on when this is the right choice (e.g., 'after previewing with preview_replace_submission_files'), an agent has to infer usage from the name and schema. This is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds that it searches official USC pages/PDFs and preserves URL/page, which is useful behavioral context beyond the annotations. However, it does not disclose how results are returned, pagination, or any rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no filler. It is concise and front-loaded with the core action. However, it sacrifices necessary detail for brevity, so it is not penalized for verbosity, only for under-specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, and the description does not explain what the tool returns (e.g., list of results, snippets, URLs). It mentions 'conserva URL/página' but not the structure of the output. It also lacks parameter usage context, making it incomplete for a search tool with three parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about the three parameters (query, source_urls, max_documents). It does not explain what 'query' should contain, how to specify source_urls, or what max_documents controls. With zero parameter guidance, an agent cannot reliably construct a correct call.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('busca' – searches) and resource ('evidencias de fechas en páginas/PDF oficiales USC' – date evidence in official USC pages/PDFs), and mentions it preserves URL/page. It clearly distinguishes from siblings like list_exam_sources by indicating it searches within content, not just lists sources. However, it does not explicitly say 'exam dates' but the name implies it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not mention list_exam_sources or any other sibling, nor does it state prerequisites (e.g., should source_urls be populated from list_exam_sources first). Usage context is only implied by the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry destructiveHint=true and readOnlyHint=false, so the destructive nature is known. The description adds minimal behavioral context by mentioning 'approved' and 'recent preview', which hints at the confirmation token but does not explain the publish action's side effects or requirements. No contradiction, but limited additional value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It front-loads the main action, but its brevity comes at the cost of omitting essential details, making it under-specified rather than optimally sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive action with 7 parameters, no output schema, and no annotation coverage beyond hints, the description is grossly incomplete. It fails to mention the confirmation token, subject, group_id, or any return behavior, leaving the agent with insufficient information to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for missing parameter meanings. It only hints at the preview process, which relates to confirmation_token, but does not explain any of the 7 parameters, including required ones like message, forum_id, or parent_post_id. This is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('posts') and resource ('public reply' to a forum post), and mentions the requirement of a recent preview, which aligns with the sibling preview_reply_forum_post. However, it does not explicitly differentiate from the preview tool or other forum actions like create_forum_discussion, so it's clear but not fully distinguishable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies usage after a preview ('through a recent preview') but does not explicitly state when to use it versus the preview tool or any alternatives. It lacks explicit conditions or exclusions, leaving the agent to infer the correct workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the constraint that only options 'approved in the preview' are stored, which gives useful context about validation. However, it does not disclose the destructive nature (destructiveHint=true) explicitly, nor explain the confirmation_token requirement or potential overwriting of existing submissions. Annotations cover the safety profile, but the description adds only a minimal extra behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise and front-loaded with the main verb. However, it is so minimal that it lacks structure or elaboration; it doesn't break down key constraints or provide context beyond the core idea. It is appropriately short but sacrifices informative value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive, four-parameter tool with no output schema and zero parameter descriptions, this description is severely incomplete. An agent cannot understand what confirmation_token is for, what the required fields mean, or what happens upon submission. The description provides only a fragment that leaves most operational details unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation of any of the four parameters (course_id, choice_id, option_texts, confirmation_token). The phrase 'exact Choice options' vaguely maps to option_texts but doesn't clarify its structure or the roles of the other parameters. Since the schema offers no descriptions, the description fails to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('stores' / 'Guarda') and a resource ('exact Choice options'), giving a clear sense of what the tool does. It distinguishes itself from preview_submit_choice_response by mentioning 'approved in the preview', implying this is the actual submission step. However, it doesn't explicitly name the sibling or define what 'Choice' refers to, so differentiation is indirect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that the tool should be used only after a preview and only with exact options that were approved, providing some context for when to call it. But it does not explicitly state when to use this tool versus preview_submit_choice_response or cancel_choice_response, nor does it give exclusions or alternatives. The guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which cover the safety profile. The description adds the useful behavioral note about never using teacher privileges, which goes slightly beyond the annotations, but does not describe other traits like output format or side effects. Given the annotations carry most of the burden, this is adequate but not exceptional.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no waste. It front-loads the core behavior and adds the privilege constraint, making it easy to read and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is a simple read-only check and annotations provide safety context, the description lacks parameter semantics, usage guidance, and any mention of what the result represents. For an agent to call it correctly, it needs to know what parameters to pass and how to interpret the response, which are absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not mention either parameter (assignment_id or course_module_id). The schema only provides type information and a title, so the description must compensate but fails to explain what the parameters mean or how they relate to the check.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'checks whether the student can continue editing', which is a specific verb and resource. It also adds a key distinction by noting it never uses teacher privileges. While it doesn't explicitly name sibling tools, the purpose is unambiguous and easy to map to the tool's name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 get_submission_status or preview_submit_assignment. The description does not provide context about typical scenarios or exclusions, leaving the agent to infer when this check is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, readOnlyHint=false, so the destructive nature is known. The description adds that it deletes 'exactos' (exact) events or series, implying precision and no tolerance for mismatches, and that they must have been 'aprobados' (approved) in preview. This adds some behavioral nuance beyond the annotations, but does not clarify the role of the confirmation_token or the irreversibility of the action beyond what the destructive hint implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, and the key qualifier (exact, approved in preview) is placed upfront. It is concise and front-loaded. However, it is so brief that it sacrifices useful detail, so it earns a 4 rather than 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool requiring a confirmation_token, the description is incomplete. It does not explain the confirmation flow, the meaning of 'series' versus 'single' events, or what happens if the token is invalid. There is no output schema, and the description does not compensate for the lack of parameter documentation. The context provided is minimal, leaving an agent uncertain about prerequisites and behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must explain the parameters. It does not mention event_id, scope, or confirmation_token explicitly. The only indirect reference is 'serie' which could relate to the 'scope' parameter (default 'single'), but this is not made clear. The description entirely fails to clarify the meaning or purpose of the required confirmation_token, leaving the agent without essential parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'Borra' (deletes) and the resource 'evento personal o serie' (personal event or series), with the qualifier 'exactos aprobados en la vista previa' (exact ones approved in the preview). This clearly differentiates it from other delete tools and indicates it is the execution step after a preview. However, 'serie' is not explicitly defined, and the tool's purpose could be slightly more explicit about the requirement for a confirmation token.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'aprobados en la vista previa' implies that this tool should be used only after a preview step (e.g., preview_delete_personal_calendar_event) has been completed, but it does not explicitly state 'use after preview' or mention alternatives. It gives contextual guidance that this is the final delete after approval, but it lacks explicit when-not-to-use or comparison with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds no further behavioral context beyond confirming it reads announcements; it does not mention pagination, rate limits, or result structure. Since annotations cover the main traits, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that directly states the tool's purpose without redundancy. It is efficient and front-loaded, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal and does not explain how the optional parameters affect behavior (e.g., what 'recent' means, how course_ids filters). Since the schema lacks descriptions and the output schema is present but not described, the description is incomplete for an agent to call the tool correctly with meaningful arguments.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the tool description provides no explanation of the three parameters (limit, course_ids, since_days). The description fails entirely to compensate for the lack of schema descriptions, leaving agents without any clue about parameter meaning or usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Lee' / reads) and resource ('avisos recientes de los foros de novedades/anuncios de las materias'), making the tool's purpose understandable. It is specific to announcements from course news forums, which distinguishes it from broader tools like list_notifications or list_forums, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 related tools (e.g., list_notifications, list_forum_discussions). There is no mention of context, prerequisites, or conditions that would warrant using this tool over others, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds that it does not query the discussion nor change its reading, which reinforces the read-only nature and clarifies that even the read is not performed. This is some additional behavior context beyond annotations, though it does not explain what preview actually returns or how it behaves internally.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core action ('Previsualiza abrir posts') and immediately clarifies the lack of side effects. It avoids fluff and is efficient, though it could be slightly more informative without hurting conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and 0% parameter documentation, the description is too thin. It does not explain what the preview returns (e.g., whether it simulates a response), nor does it describe the meaning of limit/offset/discussion_id. For a tool with three parameters and no structured metadata, this leaves the agent without essential information to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the schema provides no descriptions for the parameters (discussion_id, limit, offset). The tool description offers no explanation of what these parameters mean or how they should be used. This is a critical gap—the agent is left without any guidance on how to fill the arguments correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as a preview of opening posts and clearly states it does not query the discussion or alter its reading. This distinguishes it from the sibling tool inspect_discussion_posts through the 'preview' prefix and the negative clause, giving a specific enough purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a preview use-case (use before an actual inspection) but does not explicitly state when to use this tool instead of inspect_discussion_posts, nor does it mention any alternatives or exclusions. The 'preview' phrasing hints at the appropriate context without being explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false, so the description does not need to repeat safety. It adds context about the specific scope (entire editable submission) and that the deletion is destructive, which is helpful. However, it does not describe what the preview returns or any limitations. No contradiction with annotations exists, but the description adds limited behavioral detail beyond the annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no extraneous words. It is front-loaded with the core action and scope, and it avoids repetition. It is appropriately sized for its minimal content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters, no output schema, and 0% schema description coverage, the description should explain the parameters and what the preview shows. It does neither. The tool complexity is moderate (a preview action), but the description is too sparse to allow an agent to invoke it correctly without external knowledge. It leaves critical gaps in usage and expected outputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation of the two parameters (assignment_id and course_module_id). With no schema documentation and no description guidance, the agent has no understanding of what these parameters mean or how to fill them. The description completely fails to compensate for the lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('previsualiza' / preview) and the resource ('eliminación destructiva de toda una entrega editable' / destructive deletion of an entire editable submission). It identifies the scope as the entire submission, which distinguishes it from file-level operations like preview_delete_submission_files, though it does not explicitly name sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 (e.g., remove_submission, preview_delete_submission_files). It does not state prerequisites, whether it should precede an actual deletion, or any exclusions. The 'preview' nature implies it is a dry-run, but this is not explicitly articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the description doesn't need to repeat that. It adds context that deletion is conditional on Moodle version and permissions, which is useful. However, it doesn't explain failure behavior or impacts beyond deleting, so the added value is moderate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence, front-loaded with the action. No fluff or repetition. It earns full marks for brevity, though it lacks structured breakdowns.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with 3 parameters (2 required) and no output schema, the description is insufficient. It doesn't mention the confirmation_token's purpose, how to obtain it, or what happens on failure. An agent would need to rely on other tools (like preview_remove_submission) without any guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain parameters. It doesn't mention confirmation_token at all and only implies assignment_id as the target. No explanation of course_module_id's role. This is a significant gap for a tool with two required parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Elimina una entrega completa') and resource (a submission), making the purpose clear. It also adds a condition (version and permissions). However, it doesn't explicitly distinguish from sibling deletion tools like delete_submission_files, so it's not a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives. The condition mentioned (version and permissions) is about whether the deletion can happen, not about tool selection. There is no mention of prerequisites (like needing a confirmation_token from a preview) or when to avoid this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false. The description adds that it saves without finishing the attempt, which clarifies it is not a final submission. Beyond that, it does not mention side effects like overwriting previous answers, the purpose of confirmation_token, or any irreversible consequences. With annotations covering the safety profile, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler words, and the core action is front-loaded. It is appropriately short, though it could be slightly more informative without becoming verbose, so it earns a 4 rather than a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutation tool with destructiveHint=true, a confirmation_token, and nested objects, yet the description provides no information about the confirmation token's role, the structure of responses, or the effect of page/preflight_data. Given the complexity and absence of an output schema, the description is insufficient for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description gives no information about any of the five parameters (attempt_id, responses, confirmation_token, page, preflight_data). Since the schema itself lacks descriptions, the description must compensate, but it fails entirely, leaving the agent to guess parameter meanings and formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('save') and resource ('the exact already-previewed answers') with the qualifier 'without finishing the attempt,' which distinguishes it from finish_quiz. However, it does not explicitly name the sibling preview_save_quiz_answers or differentiate from it beyond context, so it misses the explicit distinctness 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after previewing answers and before finishing, but gives no explicit guidance on when to use this tool versus alternatives like preview_save_quiz_answers or finish_quiz. It lacks direct 'use when' or 'instead of' phrasing, so it offers only implied context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds context about the data source (Timeline) and item types, but it does not disclose any additional behavioral traits such as pagination, filtering behavior, or the meaning of the 'days' default. Given the annotation coverage, this is adequate but not exceptional.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the verb and resource efficiently. It is concise and easy to parse. However, it is so short that it forgoes necessary parameter details, which slightly detracts from its utility, but the structure itself is clean and direct.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with four parameters and zero schema documentation, the description is incomplete. It lacks any explanation of parameter semantics, output format, or special behaviors. While an output schema exists, the description does not reference it or provide hints about what the response will look like. An agent would struggle to call this tool correctly without opening the schema and inferring parameter meaning.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameters. However, it does not mention 'days', 'limit', 'course_ids', or 'include_overdue' at all. An agent relying on the description alone would have no idea what these parameters control. This is a critical gap for a tool with four parameters and no schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Lista' = List) and resource (pending tasks, quizzes, and actions from the Moodle Timeline). It differentiates from siblings like 'list_upcoming_events' and 'get_work_item' by specifying the scope (Timeline, pending items) and item types. An agent can grasp the core function immediately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. With many sibling tools such as 'list_upcoming_events', 'get_work_item', and 'list_assignments', the description offers no conditions or exclusions to help an agent select this tool. The word 'pendientes' implies a usage context, but it does not clarify how it differs from similar listing tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety and idempotency profile. The description adds no additional behavioral context beyond labeling events as 'actionable' (which is more about purpose than behavior). It doesn't mention filtering rules, ordering, or any side effects, but given the annotations are comprehensive, a 3 is appropriate—it adds minimal value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no fluff. It is front-loaded with the main verbs and object. While it is very minimal, it achieves conciseness without wasted words. It could potentially be more structured but remains acceptable in length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description fails to explain the meaning of 'actionable' events, the role of the parameters, or how the tool behaves. For an agent to use it correctly, it needs to understand what distinguishes these events from others and how days, limit, and course_ids influence results. The description only gives a high-level purpose, leaving the tool inadequately specified for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the schema only provides types and defaults without explanations. The description does not mention or explain any of the three parameters (days, limit, course_ids). Agents have no semantic understanding of what these parameters control or how to use them, making this a critical gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Lista próximos eventos accionables del calendario del Campus' clearly specifies the action (list), the resource (upcoming events from the Campus calendar), and a qualifier (actionable) that differentiates it from the sibling list_calendar_events. It is a specific verb+resource statement, not a tautology, and provides distinct meaning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. There is no mention of list_calendar_events or any condition that would select this tool, such as needing only actionable events. Agents are left to infer usage from the name and context, which is insufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the statement 'no guarda ninguna respuesta' is redundant. However, the description adds the behavioral detail that it resolves visible texts to options, which is not captured anywhere else. It does not contradict annotations, and it provides a little extra context, but the overall behavioral disclosure is thin for a tool with no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one sentence) and gets to the point quickly, which is good for conciseness. However, it omits crucial details like the relationship between parameters and the output behavior, so it feels under-specified rather than appropriately concise. It is not verbose, but it lacks substance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three required parameters and no output schema, the description is incomplete. It does not describe the return value, the exact effect of the resolution (e.g., does it return a mapped choice ID?), or any error conditions. The agent has to infer too much about how to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description carries the full burden for parameter clarity. It only hints that option_texts likely contains the visible texts to resolve, but it does not explain the roles of course_id or choice_id, nor the exact format expected for option_texts. This is insufficient for an agent to confidently construct a valid call.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action: it resolves visible texts into Choice options, and explicitly notes it does not save any response. This distinguishes it from the sibling submit_choice_response, which would actually save. The verb 'resuelve' is specific enough to convey the core function, though a bit terse about the exact mapping behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is a preview operation by saying it does not save, but it never explicitly tells the agent when to use this tool versus alternatives like submit_choice_response or preview_cancel_choice_response. There is no mention of 'use this to preview before submitting' or any routing guidance. It's left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is known. The description adds that the action is 'exacta aprobada' (exact approved), which conveys that it executes a vetted action. This is useful context beyond the annotations, but it doesn't mention that a token is mandatory or that execution is irreversible. It doesn't contradict annotations, but it doesn't fully disclose the irreversible nature either.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core purpose efficiently. It is not overlong and uses the available space well, though it sacrifices important detail. It is concise and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a destructive tool with a confirmation_token parameter and no output schema. The description doesn't explain the required relationship with preview_student_action, the necessity of the token, or what happens after execution. For a destructive tool, this is a significant gap. An agent would not know that the token must come from a recent preview or that the action cannot be undone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the descriptions for function, arguments, and confirmation_token are empty. The description provides no explanation of what these parameters represent, only implying the token is for confirmation. With zero schema coverage, the description fails to compensate, leaving the agent without clear meaning for any parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Ejecuta' = Executes) and a specific resource type ('la acción Moodle exacta aprobada mediante una previsualización reciente'), which distinguishes it from listing or reading tools. It clearly implies it is the execution counterpart to the preview tools, though it doesn't explicitly name the sibling, so it's not a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'mediante una previsualización reciente' implies the tool should be used after a preview, and the sibling list includes many preview_* tools, so the usage context is apparent. However, it doesn't explicitly state that a confirmation token from the preview is required, nor does it provide exclusions or alternatives. The guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint: true, but the description adds a valuable specific behavior: 'sin marcar actividades como completadas' (without marking activities as completed). This prevents misinterpretation that the tool might update completion status, adding context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, efficient sentence front-loads the purpose and the critical non-mutating trait. Every word earns its place; there is no verbiage or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should clarify what the tool returns (e.g., completion percentage, list of completed activities). It does not. Given the tool's simplicity, some return context and limitations are still expected for an agent to use it correctly, especially among many overlapping siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter documentation. It does not mention course_id at all. Although the parameter name and type (integer) are self-explanatory, the description adds no additional semantic value, leaving the parameter entirely undocumented in prose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb (consulta) and resource (own progress and completion), adding a key differentiator: it does not mark activities as completed. This distinguishes it from mutation tools. However, it does not specify the exact nature of the returned data (e.g., percentages, lists), so it is slightly vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus alternatives like get_my_grades or list_pending_work. The only hint is that it does not mark activities, which implicitly suggests using a different tool for such actions, but this is not stated as a clear alternative or exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds a small behavioral detail (it includes all visible events, not only timeline actions) but does not discuss limitations, authentication, rate limits, or response format. With annotations present, this yields a decent but not deep transparency level.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that puts the primary purpose upfront. It avoids redundant wording and is appropriately sized, but it could be structured with additional lines for parameter clarity. Still, it is efficient and focused.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and five parameters (two required, three optional), the description omits return-value details, parameter meanings, and any usage notes for the filters. It also lacks differentiation from list_upcoming_events. The provided context is insufficient for an agent to reliably invoke the tool with correct parameter choices.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning no parameter is documented in the schema. The description provides no parameter information at all. While 'intervalo' hints that start and end are time bounds, the optional parameters (course_ids, include_site_events, include_user_events) are left entirely unexplained, and the description does not compensate for the missing schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: 'Lee todos los eventos visibles de un intervalo' (lists all visible events in an interval), which is a clear verb+resource. The phrase 'no solo acciones del Timeline' clarifies it includes more than timeline actions, implying a broader scope. However, it does not explicitly name sibling tools like list_upcoming_events, so differentiation is only implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly suggests this is appropriate for retrieving all events in a range beyond just timeline actions, but it does not explicitly state when to use this tool versus alternatives, nor does it provide any exclusions or conditions. Without naming sibling tools, the agent must infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description's statement that it doesn't send or delete is redundant. However, it adds that it also lists members, which is additional context beyond the annotations. No other behavioral details like pagination or rate limits are disclosed, but given strong annotation coverage, this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the core action and a key safety property. No filler or redundant phrasing, so it is highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters with 0% schema coverage and no output schema. The description is too brief to cover pagination controls (limit, offset, newest), time filtering (time_from), or the semantics of 'visible members.' An agent needs more context to correctly configure the call, especially since only conversation_id is required. The tool is more complex than the description acknowledges.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description provides no explanation of any of the 5 parameters (limit, newest, offset, time_from, conversation_id). The parameter names are not self-explanatory, and without description guidance, an agent must rely on schema titles alone, which are minimal. The description fails to compensate for the lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads messages and visible members from a conversation, and explicitly notes it does not send or delete anything. This distinguishes it from sibling tools like list_messages and list_conversations, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives such as list_messages or list_conversations. It implies read-only usage but lacks a clear directive like 'use this when you have a conversation_id' or 'for global messages use list_messages instead.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the 'visible' qualifier, which hints at permission filtering, but does not explain what determines visibility or whether results are subject to pagination. Since annotations cover the major behavioral risks, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence that directly states the function with no filler. It is appropriately front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only listing tool with annotations covering safety, the description is adequate but incomplete. It does not describe the return format (e.g., list of forum objects), how visibility is determined, or pagination behavior. Without an output schema, the agent has no idea what data will come back, which is a significant gap for a list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning. However, it only indirectly references course_ids via 'materias seleccionadas' and entirely omits limit and offset. The schema itself provides default values but no semantic explanation. This falls short of the required compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is clear about the action (list) and the resource (forums), with a specific qualifier of 'visible' and 'selected subjects'. It conveys the core purpose without being a tautology. However, it does not name or contrast against sibling tools like list_forum_discussions or list_announcements, so an agent might not immediately know when to choose this over those.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives, nor any exclusions or prerequisites. The phrase 'de las materias seleccionadas' implies the course_ids parameter is needed, but it is not explicit about filtering logic or typical use cases. This leaves the agent to infer context from the schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, which covers safety. The description adds value by enumerating the exact content retrieved (draft, files, text, feedback, permissions), which is useful behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately conveys the tool's purpose and scope. No wasted words, and the key output elements are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with rich safety annotations, the description adequately summarizes what is returned. However, it lacks parameter explanations and usage guidance, making it incomplete for an agent who needs to know how to specify the submission. The absence of an output schema also leaves return format unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter explanations. The description does not mention parameters at all, leaving assignment_id and course_module_id completely unexplained. This is a major gap for a tool with two parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (query) and the resource (submission's draft, files, text, feedback, permissions). It is specific about the data returned. However, it does not differentiate from sibling tools like get_work_item or get_private_files_info, though the focus on submission status is arguably unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, nor any conditions or prerequisites. The description only states functionality, leaving the agent to infer when to call it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds the conditional behavior of providing a REST token to show enabled APIs, which is useful context beyond the annotations. It does not describe return format or error handling, so it's adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point. It is front-loaded with the main action and includes a conditional clause. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has three optional parameters, but the description does not explain their semantics or how they affect the output. There is no output schema, so the description should describe the return structure, but it only implies a list of capabilities with enabled status. This leaves significant gaps for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the three parameters (access, category, available_only). The parameter names alone provide minimal meaning, but the tool cannot be correctly invoked without knowing what these inputs do. The description fails to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: it catalogs permitted student APIs and, with a REST token, indicates which are enabled. This distinguishes it from sibling tools that list specific resources (courses, grades, etc.) by focusing on capabilities rather than individual items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a condition ('with REST token') that triggers additional behavior, which serves as a usage prerequisite. However, it does not explicitly compare against alternatives or state when not to use it. The absence of clear exclusions limits the guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal read-only and non-destructive behavior. The description adds a tool-specific behavioral guarantee beyond the annotations: the quiz attempt timer is not processed, which is meaningful context for a quiz-related tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler; the most important scoping fact is front-loaded. It is efficient and easy to parse, though it is too short to cover the remaining operational details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, no parameter documentation in the description, and no explanation of return values or optional parameter usage. The description says what the tool avoids but not what it returns or how preflight_data should be populated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the four parameters. Names like attempt_id are somewhat inferable, but page, summary, and especially preflight_data remain ambiguous without any explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('previsualizar') and resource ('un intento'), and the added contrast 'no lo abre ni procesa su temporizador' makes it clear this is a preview action rather than a real open. It does not explicitly distinguish it from closely related siblings such as inspect_quiz_attempt or preview_start_quiz.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The preview framing and the explicit statement that it does not open or process the timer imply it is meant as a dry-run check before acting. However, no sibling tool is named and no explicit condition such as 'use this instead of X when...' is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, readOnlyHint=false, idempotentHint=false, so the description doesn't need to restate the mutating nature. The description adds the requirement of a recent preview token, which is useful behavioral context. However, it doesn't explain failure modes, token validity, or side effects beyond the creation, but given annotations cover safety, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core purpose. It avoids unnecessary details while conveying the essential intent, though it could be slightly more informative without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters, zero schema coverage, no output schema, and destructive implications, the description is incomplete. It doesn't instruct the agent on the full workflow (e.g., calling the preview first), nor does it explain what the confirmation token is, how to obtain it, or what happens on success/failure. The description alone leaves an agent underprepared.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for explaining parameters. It only hints at 'confirmation_token' through 'confirmed via preview' but gives no guidance on 'name', 'timestart', 'repeats', 'duration', or 'description'. This is insufficient for a 6-parameter tool with no schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('create') on a specific resource ('personal calendar event') and adds the key qualifier 'confirmed via a recent preview,' which distinguishes it from the preview sibling. It is clear and not a tautology, though it doesn't explicitly name the sibling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'confirmed through a recent preview' clearly implies that the tool should be used after calling preview_create_personal_calendar_event to obtain a confirmation token. This provides a usage context, though it doesn't explicitly state when not to use it or mention alternatives beyond the implicit preview prerequisite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds a small behavioral detail—that outputs include deadlines and delivery types—which is useful but does not disclose other traits like ordering or pagination. Given the annotations carry most of the burden, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the primary action and resource. It adds the detail about included fields without unnecessary fluff. Every word earns its place, earning a top score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional parameter and no output schema. The description adequately conveys the main purpose and output content, but it omits guidance on how to use the course_ids filter, which is essential for full usage. This gap reduces completeness, so a score of 3 is warranted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one optional parameter, course_ids, with a default of null, and schema description coverage is 0%. The description does not explain the purpose or effect of this parameter, so the agent must rely on the parameter name alone. Since the description fails to compensate for the low schema coverage, it falls short of the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Lista tareas configuradas en Moodle' (lists assignments configured in Moodle). It specifies the resource (assignments) and adds detail about what is included (deadlines and delivery types). This distinguishes it from sibling list tools like list_quizzes or list_courses by name and resource, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating what the tool does, but it provides no explicit guidance on when to use this tool versus alternatives. It does not mention exclusions or conditions for selecting this over list_pending_work or list_upcoming_events. The context is clear, but the absence of explicit direction makes it average.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is disclosed. The description adds the specific scope (replacement of online text) and reinforces that it never modifies the submission, which is consistent with the annotation. However, it does not disclose what the preview actually returns or any other behavioral details, such as whether it validates input or checks permissions. Since annotations cover the safety profile, the description adds minimal extra context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence in Spanish: 'Previsualiza el reemplazo del texto online; nunca modifica la entrega.' It is front-loaded with the core action and includes the key side-effect disclaimer. Zero waste, no redundancies.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters (0% schema coverage) and no output schema, the description is insufficient. It does not explain what the preview reveals, what the agent should do with the response, or what the parameters mean. The readOnlyHint annotation provides safety context, but functional completeness is lacking; the agent is left guessing about course_module_id's relevance and the nature of the preview result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does not mention any of the parameters (assignment_id, online_text, course_module_id) or their roles. The phrase 'reemplazo del texto online' only loosely relates to online_text but does not explain what it means or how it interacts with assignment_id or course_module_id. No parameter meanings are added beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: it previews the replacement of online text and explicitly notes it never modifies the submission. The verb 'previsualiza' (previews) and resource 'reemplazo del texto online' (replacement of online text) are specific, and the mention of 'nunca modifica la entrega' distinguishes it from the sibling save_online_submission.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly name the alternative or state when to use this tool vs. save_online_submission. The phrase 'nunca modifica la entrega' implies that if modification is intended, another tool should be used, but this is not made explicit. No direct guidance on when to choose this tool over its siblings is provided, though the preview/action pattern among siblings offers implied context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description doesn't need to repeat safety. It does add the behavioral detail that it 'previews exact fields and values,' which hints at the output type. But it does not disclose other aspects like error handling, required permissions, or the relationship to the attempt state beyond the annotation-covered safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that delivers the core message without redundancy. It is front-loaded with the action and immediately clarifies the non-destructive nature. Every word earns its place, making it appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with four parameters, nested objects, and no output schema, the description is far too sparse. It omits guidance on how parameters interact, what the preview output actually contains, and any usage constraints beyond not saving. An agent would struggle to correctly form parameters like responses or preflight_data without additional documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description mentions no parameter names, types, or meanings. With four parameters including nested objects (responses and preflight_data), the description provides zero semantic help, failing to compensate for the schema's lack of natural-language explanations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('preview') and resource ('exact fields and values' of quiz answers) and explicitly distinguishes it from a saving action with 'never saves answers in the attempt.' This aligns with the sibling save_quiz_answers tool and makes the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'never saves answers' implies safe, non-committal use: call it when you want to inspect what would be saved without making changes. However, it does not explicitly reference the alternate save_quiz_answers tool or state conditions for choosing this over the real save, leaving usage guidance implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the description does not need to repeat safety behavior. It adds useful context about visibility ('cualquier foro visible') and scope (not just announcements), which aligns with annotations and adds value beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose and key differentiator. It is appropriately concise, though it omits parameter guidance (which is penalized elsewhere).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no parameter descriptions, so the description must compensate by explaining return values and parameter semantics. It provides neither, leaving the agent unaware of the response format or the meaning of page/per_page. Even for a simple read-only list, this is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description offers zero explanation of any parameter (forum_id, page, per_page). It neither defines their meaning nor provides usage details, so the agent must rely solely on type information, which is insufficient for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The verb 'list' and resource 'forum discussions' are clear. The description explicitly states it lists discussions from any visible forum and clarifies it is not restricted to announcements, which distinguishes it from sibling tools like list_announcements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'no solo los anuncios' implies this tool is the broader alternative to announcement-specific listing, giving a usage hint. However, it does not explicitly name the alternative tool (list_announcements) or provide a when-to-use/when-not-to-use condition, leaving some inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description's 'nunca lo envía' primarily reinforces that. It adds the concept of 'irreversible finalization' as a warning about what the real operation does, but doesn't describe what the preview returns or any side-effect nuances. With annotations covering safety, this is a moderate addition, earning a 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that front-loads the core purpose and safety guarantee. It is efficient with no fluff, though it could benefit from a bit more detail without becoming verbose. The structure is good for brevity but slightly under-informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, no output schema, and no parameter documentation, the description is far from complete. It fails to explain what the preview shows, what the parameters do, or how to interpret the result. The safety aspect is covered, but operational details are entirely missing, making it inadequate for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides zero explanation of any parameter (attempt_id, time_up, responses, preflight_data). An agent cannot infer what 'responses' or 'preflight_data' mean from the schema alone, and the description offers no help. This is a critical gap for a 4-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('previsualiza' = preview) and resource ('la finalización irreversible de un intento' = irreversible finalization of an attempt), and explicitly contrasts with the actual submission ('nunca lo envía'). This clearly differentiates it from the sibling tool 'finish_quiz', so an agent can tell them apart without inspecting the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'nunca lo envía' provides direct guidance: use this to preview the finalization safely, not to actually submit. While it doesn't explicitly name the alternative 'finish_quiz', the semantic contrast is clear and the sibling list includes it, giving strong contextual cueing. It gives a clear when-to-use signal without naming fallback tools explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description need not repeat that. It adds a useful constraint: the reply must be public and without attachments, and it states the purpose of checking the audience. This provides context beyond the annotations, though it doesn't describe return format or limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single imperative sentence that gets straight to the point: preview a public reply without attachments and check its audience. No filler words, front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and 6 parameters at 0% schema coverage, this description is insufficient. It doesn't explain what the preview returns, what 'audience' means, or how the parameters relate. An agent would need to infer too much from names and context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description carries full responsibility for explaining parameters, but it provides none. It only vaguely references 'a public reply without attachments', leaving course_id, forum_id, parent_post_id, subject, group_id, and message uninterpreted. The parameter names are self-explanatory, but the description adds no semantic detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action (preview) on a specific resource (a public forum reply) and adds a purpose (check its audience). It implicitly distinguishes from the sibling reply_forum_post by signaling a non-mutating preview, though it doesn't name the sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: this is a preview tool, so it should be used before committing to a reply via reply_forum_post. However, it doesn't explicitly state when not to use it or mention alternatives, relying on the prefix convention of sibling preview_* tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds that it does not change specific settings, but this is largely redundant with the read-only annotation. It provides minor additional context about the scope of preferences, but not substantial new behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence that front-loads the action and includes both what it does and what it does not do, with no wasted words. The structure is efficient and easily parses.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool lacks an output schema and the 'name' parameter is unexplained. While the purpose is clear, an agent cannot correctly invoke it without knowing the parameter semantics or expected return format, leaving significant gaps for such a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one optional 'name' parameter with 0% description coverage, and the description does not mention it at all. There is no way for an agent to understand the purpose or effect of the parameter, making this a severe gap that the description fails to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states an explicit verb 'Lee' (reads) and a clear resource 'preferencias propias' (own preferences), and adds negative scope by clarifying it does not change language, notifications, or message settings. This specificity distinguishes it from potential modification tools and siblings like get_my_profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when reading own preferences and explicitly excludes modification of language, notifications, and message settings, which serves as negative usage guidance. It does not name alternative tools, but the context is clear enough for an agent to select this for read-only preferences.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds the qualifier 'visible' to indicate that only visible detail is returned, which is a useful behavioral nuance. However, it does not elaborate on return format, errors, or authentication, so it provides only minimal additional context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence with no redundant words. It front-loads the core purpose and includes the crucial identifier context. Every word earns its place, achieving maximal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-identifier tool with one parameter and no output schema, the description is largely complete. It states what data it returns (visible detail) and what input it needs (Moodle ID). It doesn't specify error handling or not-found behavior, but given the low complexity and the annotations covering safety, this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema for event_id has 0% description coverage, so the description must compensate. It does so by clarifying that event_id is a Moodle identifier, which adds meaning beyond the bare type definition. This is valuable for an agent to correctly interpret the parameter, even though it doesn't specify format or source.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets the visible detail of an event/task by its Moodle identifier. It specifies a verb ('obtiene'), the resource ('detalle visible de un evento/tarea'), and the lookup key (Moodle ID). It is distinct from listing tools, though it doesn't explicitly name a sibling, so it loses a point for not differentiating from similar get-style tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention any exclusions, conditions, or sibling tools. The usage context is merely implied (you use it when you have a Moodle event ID and want details), but no explicit direction is provided, which is insufficient for an agent selecting among many tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe read operation. The description adds a behavioral detail: it only returns 'visible' content, which is extra context beyond the annotations. However, it does not mention pagination behavior, error handling, or what 'visible' precisely means (e.g., if it excludes hidden or draft items).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no redundancy. It is appropriately concise, front-loads the key action, and is easy to parse. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, no output schema, and zero parameter descriptions, the description is too sparse. It fails to explain parameter semantics, return format, or edge cases. The 'visible' filter is mentioned but not defined, and there is no mention of error conditions or pagination behavior. An agent would struggle to call this tool correctly without additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden for parameter explanation. It does not explain course_id, section_id, limit, or offset. An agent cannot infer the semantics of section_id (whether it filters by section) or how limit/offset govern pagination. The description only lists what the tool returns, not how the parameters control that output.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Lista') and the resource ('secciones, actividades, páginas, enlaces y archivos visibles de una materia'). It specifies exactly what content types are returned and includes the scope 'visibles' (visible). This is specific enough to distinguish it from siblings like list_course_resources, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There is no mention of scenarios where it should be preferred over similar listing tools like list_course_resources or list_course_participants. The description lacks exclusions or context that would help an agent decide between this and other content-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds the specific claim that enrollments and favorites are not modified, which gives concrete behavioral context beyond the annotations and is consistent with them (no contradiction).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the primary purpose and then adds a concise exclusion. It is efficient with no waste, meeting the standard for good structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional boolean and an output schema present, the description covers the core function but omits any mention of the include_archived parameter, leaving an agent without guidance on when to set it. The omission creates a notable gap in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description makes no mention of the single parameter 'include_archived', and schema description coverage is 0%. While the parameter name is somewhat self-explanatory, the tool definition itself provides no explanation of its meaning or default behavior, failing to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list) and resource (the user's courses), and explicitly notes it does not modify enrollments or favorites, distinguishing it from mutation tools. It lacks explicit differentiation from other list tools like list_course_contents, but the resource is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for listing the user's courses and reinforces its read-only nature, but it does not name alternatives or provide explicit when-not-to-use guidance relative to sibling list tools such as list_course_participants or list_my_groups. Usage context is clear but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the non-mutating behavior. The description adds that it lists dates, limits, and configuration, which is some context about the return content but not a behavioral trait beyond what annotations provide. It does not contradict annotations, and adds marginal context, so a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant wording. It front-loads the main purpose and adds a key exclusion. There is no filler, but it could be slightly more detailed without losing conciseness, so 4 rather than 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only 1 optional parameter and no output schema, the description is adequate but has gaps. It does not explain how course_ids filters results, what 'visible' means, or what the output structure looks like. While annotations cover safety, the description is not fully complete for an agent to confidently call it without ambiguity, so 3.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 1 parameter (course_ids) with 0% description coverage, and the description does not mention course_ids at all. The parameter is optional and named clearly, but the description provides no guidance on its meaning (e.g., filtering by course, or behavior when null). This fails to compensate for the low schema coverage, so a 2 is given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Lista' = lists) and resource (quizzes), and specifies what is listed (dates, limits, configuration). It also explicitly notes it does not start attempts, which distinguishes it from sibling tools like start_quiz or preview_start_quiz. This meets the 5-level criterion of a specific verb+resource with sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating it lists quizzes and does not start attempts, but it does not explicitly provide when to use this tool versus alternatives, nor does it name specific sibling tools. The distinction is implicit, so this falls short of clear context or explicit exclusions, rating a 3 for implied usage only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description is consistent. It adds specific behavioral context by clarifying that the preview affects files while preserving online text, which goes beyond the annotations' generic safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, succinct sentence that immediately communicates the core action and its effect. No fluff or redundant wording; the key constraint (text preserved) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With two parameters, no output schema, and zero explanation of parameters, the description is incomplete for reliable invocation. An agent cannot determine what assignment_id refers to or what the preview returns. The description covers only the high-level purpose but leaves operational details unresolved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter documentation. It does not mention assignment_id or course_module_id at all, leaving them completely unexplained. An agent would not know the purpose or required format of these parameters from either the schema or the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action (preview deletion), the resource (submission files), and the scope (all files), while clarifying that online text is preserved. It clearly distinguishes from the sibling delete_submission_files, which performs actual deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool instead of others. The 'preview_' prefix and the existence of delete_submission_files imply it as a safe precursor, but no explicit alternative or condition is given. It relies on naming convention rather than direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, but the description goes further by specifying that the quiz and its timer are never activated. This adds concrete behavioral context beyond the read-only flag, making it clear this is a pure preview operation with no side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that immediately conveys the core purpose and constraint. There is no wasted wording, and the key point (never activates) is front-loaded. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool being conceptually simple, it has four parameters with no semantic documentation and no output schema. The description does not explain what the preview returns, what the parameters mean, or any preconditions. The lack of parameter semantics and return value information makes this incomplete for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides zero information about any of the four parameters (quiz_id, force_new, preflight_data, course_module_id). Schema description coverage is 0%, so the description must compensate, but it does not. The agent is left without any meaning for these parameters beyond their names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: it previews the start of an attempt and explicitly guarantees it never activates the quiz or its timer. This is specific, uses a precise verb and resource, and effectively distinguishes it from the sibling start_quiz, which presumably actually starts the quiz.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for previewing rather than executing, which hints at when to use it (before actually starting a quiz). However, it does not explicitly name the alternative start_quiz or provide explicit 'when not to use' guidance. The context is clear but not fully spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds behavioral context beyond this: 'nunca bloquea ni entrega el borrador' (never blocks or delivers the draft) and 'para calificación' (for grading). This clarifies that the operation is non-committal and safe, which is useful for the agent. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the purpose ('Previsualiza el envío para calificación') and immediately communicates the key constraint ('nunca bloquea ni entrega el borrador'). No extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, no parameter descriptions, and the description does not explain what the preview returns, what each parameter does, or when to use this tool among the many preview_* siblings. Given the minimal guidance, the description is incomplete for an agent to correctly call this tool with the right arguments and interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description does not explain any of the three parameters (assignment_id, course_module_id, accept_submission_statement). The description mentions 'envío' but does not clarify the meaning or purpose of these arguments. Since the description carries the sole burden of parameter semantics, this is a major gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Previsualiza' (previews) and specifies the resource 'el envío para calificación' (the submission for grading). It clearly differentiates from the actual submission tool by stating 'nunca bloquea ni entrega el borrador' (never blocks or delivers the draft), making its purpose distinct from siblings like submit_assignment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly name an alternative tool or provide when-to-use/when-not-to-use conditions. It implies preview usage via 'nunca bloquea ni entrega el borrador' but does not direct the agent to use this before submitting via submit_assignment, nor does it mention other preview tools. The guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds specific behavioral context by stating the tool does not mark notifications as read or empty the session queue. This goes beyond the annotations by clarifying exactly what side effects are absent, which is useful for an agent deciding between this and mutating notification tools.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the primary action and includes the important non-side-effect note. Every word earns its place, and it is appropriately brief for a straightforward read-only list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With rich annotations (readOnlyHint, idempotentHint, etc.) and a simple parameter set, the description covers the core behavior. However, the complete absence of parameter semantics and lack of any mention of pagination or response format leave gaps. It is adequate but not fully complete for an agent without prior context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description provides no information about limit, offset, or status parameters. The parameter names are somewhat self-explanatory, but the default status 'unread' suggests filtering without explaining allowed values or pagination behavior. The description entirely fails to compensate for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb-resource action ('Lista notificaciones') and explicitly distinguishes this from mutating operations by noting it does not mark notifications as read or empty the session queue. This differentiates it from sibling tools that might handle notifications with side effects, providing strong purpose clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a use case (viewing notifications without affecting their state) but does not explicitly say when to choose this over alternatives, nor does it mention any exclusions. It gives some contextual signal via the non-mutation note, but no direct comparison to sibling list tools like list_announcements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description's claim 'no cambia nada' aligns with the readOnlyHint=true annotation, adding no new information beyond the annotation. It does add that the preview is about 'todas las respuestas Choice de la cuenta actual', which gives a partial scope but is ambiguous about whether it means all responses in the account or all responses for the given choice_id. Since annotations already cover read-only behavior, the description contributes limited additional context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It conveys the action, scope, and side-effect in a compact form. Every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple preview tool with no output schema, the description covers the essential 'does nothing' aspect but leaves major gaps: it does not explain the parameters, is ambiguous about the scope of 'all Choice responses', and never mentions what the preview returns. Given there is no output schema and 0% parameter coverage, more detail is needed for an agent to call this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain course_id or choice_id at all. It mentions 'respuestas Choice' but never connects the parameters to what they identify. With only 2 simple integer parameters, the description should at least hint at their roles, but it provides no meaning beyond their variable names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Previsualiza' – previews) and a resource ('retirar todas las respuestas Choice' – withdrawing all Choice responses), and explicitly notes it changes nothing. This clearly distinguishes it from the sibling 'cancel_choice_response', which performs the actual cancellation, and from 'preview_submit_choice_response' which previews a different action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The preview prefix and the phrase 'no cambia nada' convey that this tool is for dry-run or inspection. However, it does not explicitly name the alternative (cancel_choice_response) or state when to use the actual cancellation over this preview. The guidance is implied but not explicit enough for a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds that it returns IDs and does not send, which is useful behavioral disclosure. However, it doesn't go beyond this, so a 3 is appropriate given the annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core action and includes a key differentiator. There is no wasted text, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, has an output schema, and annotations cover safety. However, the lack of parameter semantics and explicit usage guidelines means the agent may not know how to construct a valid request. For a minimal tool it's adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation of the parameters 'query' or 'limit'. The agent receives no guidance on what values are expected or how the limit affects results. This is a critical gap for a tool with two parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: searching Moodle messaging recipients and returning IDs. It explicitly says 'doesn't send anything' to distinguish it from send_message, making the purpose unmistakable and distinct from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use this to find recipients for messaging. It implies it is not for sending, but does not explicitly name alternative tools or conditions. However, for a simple search tool, this is sufficient guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds the key behavioral constraint that only participants the user is permitted to see are returned, which is meaningful context beyond the annotations and helps set expectations about result scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler. The core verb and object are clear, and the permission qualifier adds value without extra length. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 no output schema, the description is mostly sufficient: it states purpose and scope. However, it does not mention pagination behavior (beyond the limit/offset in the schema) or any error conditions. Given the low complexity and strong annotation coverage, this is a minor gap, so a 4 is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning. It does not mention course_id, limit, or offset at all. While the parameter names are self-explanatory and defaults are provided, the description offers zero additional guidance, failing to clarify how limit and offset affect results or that course_id is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The verb 'list' plus the resource 'course participants' is specific, and the qualifier 'que Moodle permite ver' (that Moodle allows to see) provides a clear scope. It is distinct from sibling tools like list_courses or list_my_groups, so an agent can tell exactly what this tool returns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives. It only states the action, leaving the agent to infer that it is for retrieving participant lists. No mention of when not to use it, prerequisites, or comparisons with other list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description reinforces this with 'no sube nada'. It adds the behavior of validation ('valida'), which is not in the annotations, providing additional context about what the tool does.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence that is front-loaded with the verb, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too brief for a tool with three parameters and no schema descriptions. It lacks explanation of parameters, potential errors, or the nature of the validation. While the naming and annotations help, the description leaves the agent to guess parameter meanings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description does not explain any of the three parameters. It mentions 'archivos' which loosely maps to file_paths, but gives no guidance on assignment_id or course_module_id. This is a significant gap given the zero coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear purpose: to validate and preview the replacement of files, explicitly noting it does not upload anything. This differentiates it from sibling tools like replace_submission_files and preview_delete_submission_files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it is for previewing before an actual replacement, and the phrase 'no sube nada' distinguishes it from the execution tool. However, it does not explicitly name the alternative or state when exactly to use it versus other preview tools (like preview_delete_submission_files).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false. The description adds extra context: it only applies to 'editable' submissions and requires a confirmation token, which aligns with the annotation. It does not contradict any annotations. It also implies that the operation is not reversible (all files deleted), which is useful beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that leads with the action and resource, then adds the condition. Every word earns its place; there is no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description states the key condition ('editable') and the need for confirmation, but it does not mention how to obtain the confirmation token, what happens to the submission after file deletion, or any side effects. Given there is no output schema and the tool is destructive, an agent would benefit from knowing the token source and the post-deletion state. It is adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain the parameters. It only alludes to confirmation via 'tras confirmación' but does not explicitly describe what assignment_id or confirmation_token mean, or how to obtain the token. There is no mention that confirmation_token is required for safety or that it comes from a preview call. The description fails to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (deletes all files) and the resource (editable submission), and qualifies it with 'tras confirmación' (after confirmation). It differentiates from siblings like remove_submission (which removes the whole submission) and preview_delete_submission_files (which is likely a preview only). The purpose is unambiguous and specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this is the confirmed deletion step (after a preview) but does not explicitly state when to use it versus preview_delete_submission_files or remove_submission. There is no explicit reference to the preview tool or any conditions like 'use this only after previewing'. The guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description adds a key behavioral detail beyond that: it does not register a visit, which is not captured by the annotations. This extra context is valuable for the agent to understand side effects (or lack thereof) and aligns with the idempotent nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core purpose and includes the key behavioral nuance in a compact way. Every word contributes to meaning; there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only two parameters (one required) and no output schema, so complexity is moderate. While the description explains the core function and the no-visit behavior, it omits any explanation of the page parameter's purpose and default behavior (-1), and does not describe the return value structure. Given 0% schema coverage, the description is insufficient for an agent to fully understand how to call the tool correctly across all cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. The description does not explain attempt_id or the page parameter at all. It only describes the overall function. The agent is left to infer that attempt_id identifies the attempt and page might control pagination, but there is no explicit guidance, making this a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Lee' - read) and a specific resource ('la revisión permitida de un intento finalizado' - the allowed review of a finished attempt), plus a distinguishing condition ('sin registrar una visita' - without logging a visit). This clearly differentiates it from sibling quiz tools like get_quiz_attempt_page or get_quiz_attempt_summary, which likely perform different reads.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for finished attempts and respects permissions, giving context about when to use it. However, it does not explicitly name alternatives or state when not to use it, leaving some inference to the agent. It does not mention any exclusions or competing sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the specific detail that the sources are 'oficiales' and 'configurados', which gives context about what will be listed. However, it does not describe the return format or any side effects, which is acceptable for a read-only list tool. Given the annotations, the description adds modest behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no redundant words. It immediately conveys the action and the object, and is appropriately sized for a parameterless tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no params and no output schema, the description is adequate. It tells the agent what it does and what it targets. While it doesn't specify the exact return structure, that is not critical for invoking correctly. The description is complete enough for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so schema coverage is 100% trivially. The description adds no parameter meaning, but with 0 params the baseline is 4. The description correctly implies no arguments are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists official pages/PDFs configured for searching exam dates. It uses a specific verb 'Muestra' and a specific resource, distinguishing it from tools like search_exam_dates that actually perform the search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 does not mention search_exam_dates or any conditions for selecting this tool. The usage is only implied by the description, with no explicit exclusions or context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds context about authentication scope and course scoping but does not disclose return format or pagination. With annotations carrying the safety profile, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, compact sentence that front-loads the action and scope. No wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and sparse parameter info, the description omits expected return structure, potential prerequisites (e.g., enrollment), or filtering behavior. While the tool is simple, an agent may need more guidance on what 'groups' entails and how results are presented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It implies course_id is the subject via 'dentro de una materia', but does not explicitly name the parameter or explain its format. This gives enough inferential clarity but leaves some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Lista' = lists), resource ('grupos' = groups), and scope ('de la cuenta autenticada dentro de una materia' = of the authenticated account within a subject). It is unambiguous and distinct from siblings, none of which list groups.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context (authenticated account, within a subject) that indicates when to use it, but does not explicitly mention alternatives or exclusions. However, no sibling tool performs a similar function, so lack of explicit differentiation is acceptable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, aligning with 'no lo borra'. The description adds value by specifying what is verified (owner and scope), providing behavioral detail beyond the annotation flags.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence with no fluff. It front-loads the purpose and the non-destructive nature. It could benefit from slightly more structure (e.g., listing parameters), but it is appropriately brief for a simple preview tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description omits return value details and parameter semantics. For a preview tool, the agent needs to know what the verification result looks like (e.g., success/failure, reasons) and how to use the scope parameter. Given the lack of output schema and param coverage, this is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain the parameters. It does not mention event_id or scope at all, leaving the agent to guess their roles. The description only references 'propietario y alcance' conceptually but does not map them to the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Verifica propietario y alcance antes de borrar un evento personal' (verifies owner and scope before deleting a personal event) and explicitly clarifies it does not delete ('no lo borra'). This distinguishes it from the sibling 'delete_personal_calendar_event' and other preview tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives context: use this tool before deleting a personal event to verify ownership and scope. It implies the workflow of preview-then-execute, consistent with the sibling naming pattern, but does not explicitly mention alternatives or when not to use it. Still, the usage intent is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnly=false, but the description adds crucial behavioral context: it requires human approval and a one-time token, and it sends the exact message as previewed. This goes beyond the annotations and helps an agent understand the safe execution flow. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the purpose and key constraints. Every word adds value, and there is no redundancy or irrelevant detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides some context (previewed message, human approval, token) but lacks essential workflow details: it does not mention that preview_message should be called first, how to obtain the confirmation token, or what happens on success/failure. Without an output schema, agents are left without enough info to confidently invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description must clarify the parameters but only refers to the token as 'token de un solo uso' without linking it to confirmation_token. It does not explain recipient_user_id or text fields, nor where the token comes from or how it is obtained. The description adds minimal value for parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Envía' = sends), a resource (the message), and adds a precise qualifier ('exacto previsualizado' = exact previewed message), which clearly distinguishes it from the sibling preview_message tool. It also indicates the need for human approval and a one-time token, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a usage constraint: the message must be the exact previewed one, and human approval plus a one-time token are required. However, it does not explicitly state that this should be used after preview_message, nor does it name alternative tools or explicitly say when not to use it. The guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, but the description adds explicit context that it neither creates conversations nor marks messages as read, providing behavioral detail beyond the annotations. This is useful and does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the primary action and side-effect caveat. Every word contributes meaning; no filler or redundant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has six optional parameters, no output schema, and no parameter descriptions, the description is too sparse. It fails to explain pagination (limit/offset), ordering (newest), filtering (read_status), or the meaning of message_type, leaving the agent with insufficient information to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate. It only implies the 'direction' parameter via 'recibidos o enviados' but does not explain limit, offset, newest, read_status, or message_type. With six parameters and no descriptions, the agent lacks crucial guidance on valid values and filtering semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads received or sent messages and explicitly notes it does not create conversations or mark messages as read. This distinguishes it from siblings like list_conversations, list_conversation_messages, and preview_message, giving a specific verb, resource, and scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context that this is a read-only operation with no side effects, which implies when it is appropriate (safe listing). However, it does not explicitly name alternatives or state when to prefer other tools like list_conversation_messages or preview_message, so it lacks direct exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, covering safety and side effects. The description adds the visibility filter ('solo las insignias visibles'), which is useful context beyond annotations. It does not describe pagination, but that is implied by parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core purpose ('Lista únicamente las insignias visibles de la cuenta autenticada') without any filler or redundancy. It is appropriately sized for a simple read operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too sparse for a paginated list operation. It does not explain the meaning or behavior of the three parameters, nor does it describe the return format or any filtering semantics beyond visibility. With no output schema, an agent lacks essential information to call the tool correctly, especially for course_id.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description provides no explanation for page, per_page, or course_id. The agent must guess that page and per_page control pagination and course_id filters by course, but nothing in the description confirms this. Since the description should compensate for the absent schema descriptions, this is a clear gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Lista') and resource ('las insignias visibles de la cuenta autenticada'), and distinguishes this tool from siblings like list_my_grades by focusing on badges for the authenticated account. The scope ('únicamente' / 'only visible') adds precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: it is for retrieving the current user's visible badges. There is no explicit 'when not to use' or mention of alternative tools, but given the tool name and description, the use case is unambiguous. No conflicting tools exist for badges, so a 4 is fair.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and destructiveHint=false, which already indicate a non-destructive operation. The description adds value by specifying that it creates a token and never sends, which is important behavioral context beyond the annotations. It does not contradict the read-only hint because token creation is not a data mutation; the description is consistent and informative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the primary purpose ('Previsualiza un mensaje Moodle') and immediately clarifies the key distinction ('nunca realiza el envío'). It has zero wasted words and is easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two obvious parameters and no output schema, the description covers the core behavior but leaves out important context: what the returned token is for, how it should be used (likely for a later send), and any expiry or validity constraints. Since these details are critical for an agent to use the tool correctly, the description is incomplete, though not severely inadequate for a simple preview operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden of explaining parameters. However, the description does not mention recipient_user_id or text at all. While the parameter names are self-explanatory to a degree, the description fails to clarify their meaning, purpose, or any constraints, leaving the agent to infer from the schema alone. This is a significant gap given zero schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('previsualiza'), the resource ('mensaje Moodle'), and the action ('crea un token'), and explicitly distinguishes it from sending by saying 'nunca realiza el envío'. This differentiates it from the sibling 'send_message' without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: it is a preview that never sends. This implies it should be used before any actual sending, with 'send_message' as the alternative for sending. However, it does not explicitly name the alternative or provide a when-not condition beyond 'nunca realiza el envío', so it falls short of the highest bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, establishing the safety profile. The description adds meaningful context beyond that: it states there is no secret leakage, which is important for a tool handling authentication. This additional behavioral disclosure justifies a score above baseline.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys all essential information without fluff. It front-loads the main purpose and includes the critical constraint about not returning secrets. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, low-complexity tool with no output schema, the description adequately covers what the agent needs: it checks session validity and guarantees no secret disclosure. While it doesn't state the return format, that is a minor gap given the tool's simplicity. The description is practically complete for this use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing to explain in the description beyond what the schema already implies. Per the scoring guidance, a no-parameter tool receives a baseline of 4, and the description does not need to add parameter-level detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: verifying that the Campus local session/token works. It specifies both the action (checking) and the resource (session/token), and explicitly notes it does not return secrets. This distinguishes it from the many sibling tools that perform other actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a usage scenario (checking auth status) but provides no explicit guidance on when to use it versus alternatives, nor any exclusion conditions. For a simple status check, this is acceptable but not thorough; an agent would benefit from knowing it should be called before other authenticated operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, but the description adds a non-obvious behavioral detail: the tool does not register a visit to the grade report. This is meaningful context beyond the structured annotations and helps the agent reason about side-effects. No contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence conveys the core action, the scope, and a critical behavioral note. There is zero redundancy; every word earns its place. The structure is ideal for quick parsing by an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one optional parameter and no output schema, the description covers the essential information: what it does, when the parameter matters, and a side-effect caveat. It does not detail the return format, but given the low complexity and presence of readOnlyHint, this is a minor gap rather than a deficiency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining that the optional course_id toggles between global grades (null) and a specific subject. This provides functional meaning to the parameter that the schema itself lacks, enabling correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool reads the user's own grades (global or per course) with the phrase 'Lee las calificaciones propias globales o de una materia'. It names the verb and resource precisely, and the scope (global vs. subject) differentiates it from related grade tools like get_quiz_best_grade without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description communicates when to use the tool (to read overall or per-course grades) and adds a key behavioral caveat ('no registra visita al informe'). However, it does not explicitly contrast with sibling tools or state when NOT to use it, so an agent must infer alternatives from the broader toolset.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description adds a meaningful behavioral detail—'sin registrar una visita al perfil'—that is not present in annotations, clarifying that this call does not increment profile visit counts. This goes beyond what structured metadata provides, though it could have elaborated on return format or side effects more.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core action and resource, then appends the important behavioral caveat. There is zero waste, and every word contributes to understanding the tool's purpose and side-effect profile.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only tool, the description is fairly complete: it names the resource and the key behavioral guarantee. However, without an output schema, it does not specify what fields constitute the profile, which could leave an agent unsure of the exact response shape. Given the simplicity and common understanding of 'profile', this is a minor gap, so 4 is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and the schema coverage is trivially 100% (empty object). The description adds no parameter documentation because there are none, which is appropriate. Baseline for zero parameters is 4, and the description is consistent with that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Lee' = reads) and resource ('perfil de la cuenta autenticada' = profile of the authenticated account), and adds a precise behavioral nuance ('sin registrar una visita'). This clearly distinguishes it from other read tools like get_my_preferences or get_my_grades by specifying exactly what it fetches and that it does not affect visit tracking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving the authenticated user's profile, which is clear from context. However, it provides no explicit guidance on when to choose this over siblings like get_my_preferences or auth_status, nor does it mention any exclusions or conditions. The usage is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description correctly aligns with them. It adds extra context by stating that it neither creates drafts nor downloads anything, giving more specific behavioral boundaries beyond the generic read-only guarantee.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the primary action and then lists exclusions. Every word earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with no parameters and no output schema, the description covers the essence: what it queries (quotas and counts) and what it avoids. While it does not specify output format, the phrase 'cuotas y recuentos' implies numeric results, which is sufficient for an agent to understand the tool's purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema provides complete coverage (100% vacuous). With no parameters to describe, the baseline of 4 applies, and the description adds no parameter details because none exist. This is appropriate for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('consulta') and resource ('cuotas y recuentos de archivos privados'), and explicitly states what it does not do ('no crea borradores ni descarga nada'). This clearly distinguishes it from any sibling tool that might involve file creation or downloading.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for read-only inspection of private file metadata, and the exclusion of draft creation and downloads hints at when not to use it. However, it does not name alternative tools or provide explicit conditions for choosing this one over others, so guidance is limited to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-usc MCP server](https://glama.ai/mcp/servers/PabloPC05/mcp-usc/badges/card.svg)](https://glama.ai/mcp/servers/PabloPC05/mcp-usc)

Score Badge

Copy to your README.md:

[![mcp-usc MCP server](https://glama.ai/mcp/servers/PabloPC05/mcp-usc/badges/score.svg)](https://glama.ai/mcp/servers/PabloPC05/mcp-usc)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/PabloPC05/mcp-usc'

If you have feedback or need assistance with the MCP directory API, please join our Discord server