unsw-mcp

by r1ckyIn

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
The platform prefixes (ed_, moodle_, gradescope_, unsw_) clearly separate tool clusters, and within each cluster the verbs denote distinct actions. Minor potential confusion exists between tools like ed_thread_action vs ed_edit_thread and moodle_list_announcements vs moodle_list_forums, but descriptions clarify these boundaries.
Naming Consistency4/5
Most tools follow a consistent verb_noun pattern with lowercase snake_case and platform prefixes. However, ed_thread_action breaks the verb-first convention (it is noun_action), and a few tools like moodle_get_upcoming use an adjective as the object. Overall the pattern is strong, just imperfect.
Tool Count2/5
With 40 tools, this server is far above the 25+ threshold that indicates an excessive count. Although each platform's tools seem justified, the sheer number burdens an agent with selection overhead and makes the server feel bloated rather than focused.
Completeness4/5
The server provides comprehensive coverage for the UNSW student domain: Ed threads, lessons, resources, and workspaces; Moodle courses, forums, assignments, grades, and calendar; Gradescope course/assignment lookup; and course outlines. Minor gaps exist (e.g., no Ed thread deletion, no Gradescope grade viewing), but core student workflows are well covered.
Average 4.1/5 across 40 of 40 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit 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 and idempotentHint, so safety is covered. The description adds no additional behavioral context such as pagination, ordering, or the meaning of 'notifications', providing no value 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and to the point, with no filler words. However, it is so minimal that it borders on under-specification, though for a simple getter it is 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?
Given no output schema and a single optional parameter, the description should explain what the tool returns and how 'limit' affects results. It does not, leaving the agent with an incomplete picture.
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 input schema has a single optional 'limit' parameter with 0% schema description coverage. The description does not mention 'limit', leaving the agent to infer its purpose from the name alone; this fails to compensate for the missing schema description.
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 clear verb '取' (get) and a specific resource '站内通知' (site notifications), making its function apparent. However, it does not explicitly distinguish from sibling tools like moodle_list_announcements, though the name itself clarifies the domain.
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 over alternatives. No mention of prerequisites, use cases, or exclusions.
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 description adds no behavioral context beyond the annotations (readOnlyHint, idempotentHint, destructiveHint). It does not disclose return format, data scope, or any limitations. Since annotations already cover safety, the description's lack of additional context lowers its value to minimal.
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 key action. It wastes no words, but it is so minimal that it borders on under-specification. Still, for the simplicity of the tool, it earns a high score.
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 is adequate for a simple read-only tool but lacks any detail about return values or structure. With no output schema, the description should clarify what the 'overview' contains, but it only says 'total grades for all courses'. This leaves some ambiguity, making it a minimum viable description.
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 baseline is 4 per the scoring rules. The description adds scope context ('all courses') but no parameter details are needed. The empty schema is fully covered.
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 returns an overview of total grades for all courses, which is a specific read operation. It distinguishes from sibling tools like moodle_get_grades by emphasizing 'all courses' and 'total grades' rather than per-course details. However, it lacks an explicit verb like 'get' or 'list', making it slightly less direct.
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 that this is for a high-level summary or that more detailed grade information is available via moodle_get_grades. There is no usage context or 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 indicate readOnlyHint=false and destructiveHint=false, so this is a non-destructive write operation. The description adds the behavioral note '发出即上线' (goes live immediately upon posting), which is useful context about publication timing. However, it does not disclose permissions, reversibility, or other side effects, so the contribution 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the purpose and a note on immediacy. It is free of filler, well-structured, and every phrase earns its place.
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 4 parameters, no output schema, and sparse annotations, the description is too thin. It does not mention prerequisites such as obtaining a valid comment_id from ed_get_thread, explain the optional flags, or describe the tool's response. For a mutation tool, this is incomplete 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 50% (content and comment_id have descriptions, is_private and is_anonymous do not). The description itself does not mention any parameters or add meaning beyond the schema, nor does it compensate for the undocumented optional fields. This leaves the agent guessing at the semantics of is_private and is_anonymous.
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 action: '回复 Ed 上已有的评论' (reply to an existing comment on Ed). It uses a specific verb ('reply') and resource ('existing comment'), which inherently distinguishes it from siblings like ed_post_comment (posting a new comment) and ed_post_thread (posting a new thread).
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 when one wants to reply to an existing Ed comment, but it does not explicitly state when to use this tool versus alternatives. The phrase '已有的评论' hints at needing an existing comment_id, but no exclusions or alternative tool names are 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 readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds filter and sort context, but this largely mirrors the schema enums rather than exposing new behavioral traits like pagination handling or default return behavior.
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 that communicates the core purpose and key options without any waste. Every word adds value.
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?
The description captures the primary functionality (listing threads with filtering and sorting) and is complemented by a rich schema with detailed parameter descriptions and safe-read annotations. It omits pagination and response_format, but these are documented in the schema, making the description sufficient for basic understanding.
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?
The description adds natural-language meaning to filter_type (unread/unanswered/starred) and sort (new/old/top/hot), which lack schema descriptions. However, it does not explain limit, offset, category, or response_format, which are already covered by the schema. Overall, it partially compensates for schema gaps but is not exhaustive.
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 this lists discussion threads (讨论列表) for an Ed course, and mentions the available filters and sort options. This distinguishes it from sibling tools like ed_get_thread (single thread) and ed_search_threads (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 such as ed_search_threads or ed_get_thread. It simply states capabilities without contextual positioning or 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 and destructiveHint=false, so the tool is known to be safe and read-only. The description adds scope information (own + faculty/staff public instances), but it does not disclose other behavioral traits like return format, pagination, or access restrictions. 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 clause that packs all essential information: the resource type (workspaces), the parent context (Ed course), and the scope (own + shared). There is no fluff or redundancy.
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?
Given the simple list operation, the combination of schema (full parameter descriptions), annotations (read-only, non-destructive), and description (resource scope) is mostly complete. The main gap is that no output schema exists and the description doesn't specify the exact fields returned for each workspace, but the tool name and description make the basic return type clear.
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?
The input schema covers 100% of the parameters with detailed descriptions: course_id explains how to obtain it (from ed_list_courses) and response_format has an enum with default. The tool description itself adds no additional parameter semantics, so baseline 3 is appropriate.
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 provides the workspaces (cloud IDE instances) for an Ed course, including the user's own and faculty/staff shared public instances. This is specific about the resource type and scope, and distinguishes it from sibling tools like ed_list_courses (courses) and ed_create_workspace (create).
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 does not mention that this is the read-only listing operation, nor does it reference ed_create_workspace for creation or ed_delete_workspace for deletion. Sibling tools are present but not mentioned.
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 agent knows it is a safe read operation. The description adds no further behavioral details such as result format, pagination behavior, or search scope limitations. It is consistent with the annotations but provides minimal extra transparency.
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, short sentence that directly states the tool's purpose without any redundant information. It is front-loaded and every word earns its place, making it 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 description is too terse for a tool with 4 parameters and no output schema. It does not explain what the search returns (e.g., a list of thread titles, full thread content), how response_format affects the output, or any search behavior limitations. The schema covers parameter details but leaves the return value and usage context unspecified, making the description incomplete for an agent.
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?
The schema provides descriptions for query, course_id, and response_format (75% coverage), leaving only limit undocumented. The description itself adds no parameter-specific context beyond the general 'by keyword' reference to query. Since the schema carries most of the semantic weight, a score of 3 is appropriate.
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: 'search discussions by keyword in an Ed course.' It uses a specific verb (search) and resource (discussions), which distinguishes it from siblings like ed_list_threads (listing all threads) and ed_get_thread (retrieving a single thread).
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 use case (keyword-based search) but does not explicitly mention when to prefer this over alternative tools like ed_list_threads or provide exclusions. There is no guidance on when not to use it, leaving usage boundaries unclear.
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 useful context about XML-to-text conversion, but it also unconditionally states 'includes all slides' despite the schema allowing include_slide_content=false, which is a behavioral nuance not disclosed. This is not a contradiction with annotations, but it is an incomplete 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?
The description is a single, focused sentence that front-loads the core purpose and adds a valuable detail about XML conversion. Every word earns its place, with no filler or redundancy.
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?
Given the read-only annotations and a relatively simple schema, the description plus schema covers the essential functionality well. However, the lack of an output schema and the unmentioned include_slide_content toggle leave some ambiguity about the exact return structure. Overall, it is sufficiently complete for an agent to select and invoke the tool correctly in most 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 description adds no parameter-specific meaning beyond what the schema already provides. With schema coverage at 67%, the include_slide_content parameter is left entirely undocumented in both the schema and description. The response_format description is also minimal ('Output format'), and the description does not clarify the effect of these parameters on the returned content.
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 returns the complete content of a single Ed lesson, including all slides with XML automatically converted to text. This distinguishes it from sibling tools like ed_list_lessons (which lists lessons) and ed_get_thread (which gets a thread). The verb 'get' is implied and 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 use when a user needs full lesson content, but does not explicitly state when to use this over alternatives like ed_list_lessons. It also doesn't mention that lesson IDs can be obtained from ed_list_lessons (though the schema does), nor does it exclude any contexts. The usage context is clear but not fully elaborated.
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 show readOnlyHint=true and destructiveHint=false, so the safety profile is already known. The description adds the scope of the return data (all answers and comments), which is useful. It does not disclose other behaviors like pagination or presence of deleted items, but given strong annotation coverage, the extra context 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the purpose without redundancy. It is front-loaded with the key information and contains no filler. Perfectly sized for the tool's simplicity.
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 2 params and no output schema, the description sufficiently conveys what the tool returns (complete discussion with all answers and comments). It leverages the schema for parameter details and annotations for safety. It could mention the response_format parameter or potential limits, but it is complete enough for this low-complexity tool.
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 description coverage is 100% for both parameters. thread_id's meaning ('Ed thread ID') and response_format's enum/default are fully documented in the schema. The description adds no additional parameter semantics beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the complete content of a single Ed discussion, including all answers and comments. It uses a specific resource (single Ed thread) and implies the 'get' action, distinguishing it from siblings like ed_list_threads or ed_search_threads.
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 tool is for when you need the full content of one Ed thread. However, there is no explicit guidance on when not to use it or alternatives (e.g., using ed_list_threads for just titles). The description does not mention exclusions 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, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds no behavioral context beyond the purpose itself, such as whether events are course-specific, user-specific, or include all calendars. It does not contradict annotations, but also adds little 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.
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 key constraint. It is well-structured and front-loaded with zero waste.
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 two-parameter read-only tool, the description is minimally adequate but lacks important contextual details such as the scope of events (e.g., all courses, user-specific, site-wide) or the return format. Since there is no output schema, such details would be valuable for complete understanding.
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 only parameter information in the description is 'month 是 1-12', which merely repeats the schema's min/max constraints. The description does not explain the semantics of 'year' or what constitutes a calendar event, failing to compensate for the lack of 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 action ('取' = get), the resource ('日历事件' = calendar events), and the scope ('某月' = specific month). This specific phrasing distinguishes it from related tools like moodle_get_upcoming, which targets upcoming events rather than a chosen month.
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 you need calendar events for a given month. However, it does not explicitly mention alternatives or exclusions, such as when to prefer moodle_get_upcoming or how to handle different date ranges. The context is clear but lacks direct 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, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds output content details but does not disclose additional behavioral traits like pagination or auth requirements. With strong annotation coverage, the description provides modest 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence in Chinese that conveys the tool's essence without wasted words. It efficiently states what the tool returns.
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?
With one parameter, rich annotations, and no output schema, the description adequately communicates the return content (scores, ranges, feedback). It is minimal but sufficient for the simplicity of the tool, though it could be slightly more explicit about the exact structure.
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 description coverage is 100%: the input schema already documents courseId as a Moodle course ID obtained from moodle_list_courses. The tool description itself adds no extra parameter semantics, so the baseline of 3 applies.
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 retrieves a course's detailed grade table, listing each grade item's score, range, and feedback. The Chinese term '明细' (detailed) distinguishes it from the sibling tool moodle_get_overview_grades, which implies summary-level data.
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 purpose implicitly suggests it is for per-item grade details, and the sibling moodle_get_overview_grades likely serves summary needs. However, there is no explicit when-to-use vs. alternatives or exclusions, leaving usage guidance only implied.
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 safe read-only nature is covered. The description adds valuable context about the return shape (overdue flag and action.name), which goes 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?
Two concise sentences, front-loaded with the tool's purpose and including only essential return-field details. No filler or redundant information.
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?
Given the single parameter and lack of output schema, the description adequately communicates what is returned (combined todo/near/overdue, overdue flag, action name). It could mention ordering or whether items include links, but for a simple list tool the information is sufficient.
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 description coverage is 100% and the parameter description clarifies the forward/backward time window for daysAhead. The tool description itself does not add parameter semantics beyond what the schema provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns upcoming to-dos, near-deadline items, and overdue items combined. It is distinct from siblings like moodle_get_calendar or moodle_list_assignments by focusing on actionable upcoming tasks, but it does not explicitly name the resource (e.g., 'assignments' or 'submissions').
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 checking upcoming deadlines/tasks, but it does not provide explicit guidance on when to use it instead of moodle_get_calendar or moodle_list_assignments. No alternatives or exclusions are mentioned.
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, so the safety profile is covered. The description adds useful context by explaining the classification values (inprogress means current semester), but it does not disclose return format, pagination, or other behavioral details. 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?
The description is a single concise sentence with a parenthetical for the parameter values. It is front-loaded with the main action and resource, and every word earns its place with no redundancy.
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 one optional parameter and no output schema, the description is largely complete. It specifies the resource and the filtering options. It could be slightly more explicit about what '选修的课程' includes (e.g., only enrolled courses), but overall it adequately covers the tool's behavior.
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 has one parameter with enum values but no descriptions. The description explicitly explains each enum value (inprogress, past, future, all), adding meaning beyond the schema and compensating for the 0% schema description coverage. This is clear and helpful for a single parameter.
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 ('list') and resource ('elective courses'), and the classification parameter further specifies the scope (inprogress/past/future/all). It distinguishes itself from other Moodle list tools by focusing specifically on courses rather than forums, assignments, etc.
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 like moodle_get_course_contents or ed_list_courses. The usage is only implied through the action 'list', but no explicit context or exclusion criteria are mentioned.
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 state this is not read-only and not destructive. The description adds the effect of marking as resolved and the ownership prerequisite, which is useful. However, it does not disclose whether the action is reversible, any permission requirements beyond ownership, or what happens if the answer is already accepted. The added value beyond annotations 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, direct, front-loaded with the action, no superfluous words. It conveys what, where, and the outcome efficiently.
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 state-changing tool with two parameters and no output schema, the description covers the action, the ownership condition, and the effect. It lacks details like reversibility or side effects, but these are not critical given the tool's simplicity.
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 100%, with both parameters having clear descriptions (thread_id must be your own thread, comment_id is the answer comment to accept). The tool description adds no additional parameter semantics, so the baseline of 3 applies.
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?
Description states 'accept an answer on your own question thread, mark as resolved' with a specific verb and resource, clearly distinguishing it from sibling tools like ed_post_comment or ed_reply_to_comment. The ownership constraint ('your own') 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 description implies the usage context: when you have a question thread and want to accept an answer. It also includes an important condition ('on your own thread'). It does not explicitly name alternatives or exclusions, but the context is clear enough for an AI to understand when to invoke 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 mark the tool as read-only and non-destructive. The description adds the behavioral intent of token validation, providing context beyond annotations. It doesn't describe return format or rate limits, but with annotation coverage, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence that immediately conveys the tool's purpose and usage. No unnecessary words, and the key information is front-loaded.
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 purpose and context. It could mention what fields are returned, but the tool name and description are sufficient for selection and invocation.
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?
The single parameter 'response_format' is fully described in the schema with enum values and a default. The description adds no parameter-specific information, but schema coverage is 100%, so the agent can rely on the 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 explicitly states the tool retrieves current Ed user information, a specific resource distinct from all sibling tools. It also gives a use case (confirming token validity), making the purpose clear and differentiated.
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 specifies the primary use case: confirming token validity. It implies this is the tool to call when you need to verify authentication, though it doesn't explicitly name alternatives or exclusions. Given the unique scope of user info among siblings, the context 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 declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds behavioral context about the output structure (grouped by category, includes file type and size), which is useful beyond the annotations and consistent with them. It 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 is front-loaded with the main purpose ('Resources page'). Every word adds value, with no unnecessary elaboration.
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?
Given the tool has no output schema, the description provides enough context about the return content (grouped by category, file type and size) and the resource types. However, it does not mention response_format or pagination, but the schema covers response_format. For a simple list tool with good annotations, this is nearly complete, though it could have explicitly referenced the sibling download tool for clarity.
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 description coverage is 100%, so the parameters (course_id, response_format) are already fully described in the schema. The description does not add extra meaning to the parameters beyond what is in the schema, so the baseline score of 3 is appropriate.
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 resources (讲义、链接、文件) for an Ed course, with grouping and metadata. It specifies a distinct resource type ('Resources page') and implies a read/list operation, distinguishing it from siblings like ed_download_resource and ed_list_lessons.
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 gives a clear context (listing resources for an Ed course) but does not explicitly state when to use this tool over alternatives, nor mention the sibling ed_download_resource for downloading. No exclusions or alternative guidance is provided, so usage 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 the tool as read-only, idempotent, and non-destructive. The description adds meaningful behavioral context by listing the specific data categories returned, which is not present in the annotations. It does not disclose additional traits like authentication or rate limits, but the safety envelope is fully covered by 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, front-loaded sentence that conveys the tool's purpose and output in a concise manner. There is no filler or redundancy.
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 tool with one parameter and no output schema, the description offers a solid overview of the returned data. It could be more explicit about the need for cmid, but that is covered by the schema. The listed fields provide sufficient context for an agent to understand the tool's function.
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?
The schema provides 100% coverage for the only parameter cmid with a clear description ('course module id'). The tool description does not add any further parameter explanation, so the baseline score of 3 applies.
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 specifies the tool's function: it returns a status table for a single assignment, enumerating the contained data (submission status, grading status, remaining time, submitted files, comments). This distinguishes it from sibling tools like moodle_list_assignments (list overview) and moodle_get_grades (grades).
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 used to inspect the detailed status of one assignment, but it provides no explicit guidance on when to use it versus alternatives or when not to use it. The need for a cmid is implied but not stated as a usage prerequisite beyond the schema.
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. The description adds behavioral context by stating that the output includes cmid and module type, is organized by week, lists all activities and resources, and that external links (external=true) cannot have their content retrieved. This goes beyond the annotation safety profile and gives practical usage caveats.
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 two sentences, front-loaded with the core purpose, and includes a useful caveat in the second sentence. There is no fluff or redundancy; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one parameter, no output schema, and strong annotations, the description sufficiently explains what the tool returns (weekly structure, all activities/resources, cmid, module type) and its limitation (external links). It lacks details on exact output formatting or error handling, but for a read-only list tool, this is adequate and nearly complete.
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?
The input schema has 100% description coverage for courseId, explaining it is a Moodle course id obtained from moodle_list_courses. The tool description does not add further parameter semantics beyond what the schema already provides, so the baseline score of 3 is appropriate.
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: '一门课的完整结构：按周次列出全部活动和资源，带 cmid 和模块类型' (complete course structure, listing all activities and resources by week, with cmid and module type). This is a specific verb+resource description that distinguishes it from siblings like moodle_list_courses (which lists courses) and moodle_get_assignment (which gets a single 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 provides a prerequisite for the courseId parameter ('从 moodle_list_courses 拿'), which is a usage guideline. It also mentions a limitation (external links cannot be fetched). However, it does not explicitly state when to use this tool versus alternatives, nor does it give exclusions or alternative tool names.
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=false and destructiveHint=false, so the safety profile is known. The description adds minimal behavioral context, such as the meaning of workspace_type, but does not describe side effects, prerequisites, or post-creation behavior. This meets the baseline with annotations present.
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 action and then clarifies the key parameter. No extraneous words; the list of workspace_type values is necessary detail rather than fluff.
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 create tool with no output schema, the description covers the essential purpose and parameter options. It does not mention potential delay or prerequisites, but the schema provides course_id acquisition guidance. Overall, it is sufficiently complete given the tool's simplicity.
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?
Schema coverage is low (33%), but the description compensates by explaining workspace_type as '环境镜像' and listing all valid values (general/c/cpp/python/java/nodejs/jupyter/rstudio). course_id is already described in the schema; title's purpose is self-evident. This adds meaningful guidance beyond the 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 action ('新建 workspace') and resource ('Ed 课程里的云 IDE'), using a specific verb and context. It distinguishes from sibling tools like ed_update_workspace and ed_delete_workspace by focusing on creation.
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 for when to use this tool (creating a new workspace in an Ed course) and clarifies the workspace_type parameter's valid choices. It does not explicitly mention alternatives or when not to use it, but the context is sufficient for selection.
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 provide minimal safety context (readOnlyHint=false, destructiveHint=false), so the description adds value by mentioning a 50MB size limit and the link-type resource caveat. However, it does not disclose behaviors like file overwriting, network failure handling, or the exact local save behavior beyond the schema default, leaving some gaps.
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 two sentences, front-loaded with the action, and includes only essential details. Every sentence contributes value: what it does, where to get the resource_id, a constraint, and a size limit. No redundant information.
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 relatively simple tool with two parameters and no output schema, the description covers the key context: purpose, parameter source, default path, and a size limit. It does not explain the return value, but that is less critical in the absence of an output schema. The description is adequate for an agent to invoke the tool correctly in most scenarios.
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 50% schema coverage, the description adds meaning by explicitly stating that resource_id comes from ed_list_resources and clarifying the default save path behavior (current directory + resource name and extension). This goes beyond the schema and helps the agent understand parameter provenance and defaulting.
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 downloads Ed course resource files to a local destination, with a specific verb and resource. It also distinguishes from siblings by noting the source of resource_id and the limitation for link-type resources, making it unambiguous.
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 on when to use the tool: when needing to download a file resource, with resource_id sourced from ed_list_resources. It also notes that link-type resources have no file to download, which serves as an exclusion criterion. It does not explicitly mention alternatives, but the platform-specific naming and instructions are sufficient.
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 this as read-only and non-destructive. The description adds value by explaining the return structure (grouped by module, with slide count, deadline, status), which is useful behavioral context beyond the 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?
One concise sentence conveys the purpose, grouping, and key output fields with no wasted words. It is front-loaded and easily scannable.
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?
The tool is simple (two params, no output schema), and the description adequately captures what the tool returns. It could mention ordering or pagination, but for a list-lessons operation, the current detail is sufficient.
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 description coverage is 100%, so both parameters (course_id and response_format) are fully documented in the schema. The description does not add significant parameter-level meaning beyond what the schema already provides, so baseline 3 is appropriate.
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 ('list') and resource ('lessons'), and adds meaningful details about grouping and included fields (slide count, due time, status). This distinguishes it from the singular ed_get_lesson sibling.
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 usage for retrieving a lesson list for an Ed course, which is clear from the context. However, it does not explicitly name alternatives or exclusions, though the sibling ed_get_lesson naturally covers single-lesson needs.
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 that the comment goes live immediately upon posting ('发出即上线'), which is a behavioral trait beyond the annotations. It also explains the routing to the Answers section. The annotations (readOnlyHint=false, destructiveHint=false) are not contradicted, and the description adds value beyond the structured data.
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 two sentences with no wasted words. The first sentence states the action and resource, the second clarifies the key parameter and the immediate-publishing behavior. Every sentence 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 write tool with no output schema, the description covers the core action, parameter guidance for the main choice, and a key behavioral note (immediate publishing). Optional flags like is_private and is_anonymous are not explained, but their boolean names make them reasonably self-explanatory, so the description is sufficiently complete for the complexity.
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?
With only 40% schema description coverage, the description must compensate for undocumented parameters. It adds crucial meaning to comment_type by explaining the difference between 'answer' and 'comment', but it does not explain is_private or is_anonymous, leaving some gaps. The core differentiating parameter is well-covered.
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 posts a comment or answer on an Ed post, using the specific verb 'post' and resource 'Ed post'. It distinguishes between comment types and implies differentiation from siblings like ed_reply_to_comment and ed_post_thread by specifying 'under an Ed post'.
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 on when to use 'answer' vs 'comment' based on whether the post is a question. However, it doesn't explicitly name alternative tools or state exclusions, so it stops short of full when-not-to-use guidance.
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 list of returned fields (name, submission status, score, release/due times), which gives context about the output but does not disclose additional behaviors like pagination or ordering. With annotations in place, this meets the baseline but adds limited extra transparency.
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 ('一门 Gradescope 课的作业表') and then lists the returned fields and the source for course_id. Every clause adds value with no waste.
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 one parameter and good annotations, the description conveys the main purpose, the output fields, and the parameter source. It does not mention potential edge cases like empty lists or pagination, but these are not critical for this tool's simplicity. Overall it is sufficiently complete.
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?
Schema coverage is 100% with a description for course_id (Gradescope course id as numeric string). The description adds the critical instruction that course_id comes from gradescope_list_courses, which goes beyond the schema and helps the agent correctly obtain the parameter. This lifts it above the baseline.
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 assignments for a Gradescope course, specifying the returned fields (name, submission status, score, release/due times). It distinguishes itself from siblings like moodle_list_assignments and gradescope_list_courses by naming the Gradescope context and the resource type.
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 that course_id should be obtained from gradescope_list_courses, providing a clear prerequisite for using the tool. It does not explicitly mention alternatives or when not to use it, but the instruction on sourcing the parameter is valuable usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false, but the description adds critical context: permanent deletion, irreversibility, inclusion of all files inside, and the ownership restriction. This goes beyond the structured annotations and gives the agent a full understanding of the operation's impact.
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?
Two concise sentences deliver the core message first (permanent, irreversible, includes files) and then the scope limitation. No wasted words, exceptionally front-loaded.
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 single-parameter delete tool with annotations, the description covers the essential context: destructive, permanent, irreversible, scope, and associated data. It lacks explicit return-value details, but there's no output schema and such details are not critical for a delete 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?
The description does not mention the workspace_id parameter or clarify its role beyond the schema's basic name/type/length. With 0% schema description coverage, the description fails to compensate for the lack of parameter-level context, though the parameter name is somewhat self-explanatory.
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 action: permanently deleting the user's own Ed workspace, including all files, with an explicit scope limitation ('只删自己建的'). This distinguishes it from sibling tools like ed_list_workspaces, ed_create_workspace, and ed_update_workspace.
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: only delete workspaces the user created. It implies when to use (for user's own workspaces) but does not explicitly mention alternatives or exclusions beyond the ownership constraint. The destructive nature is implicit but well-stated.
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 that it returns course name, code, and Ed course ID, and that it lists only courses the user is enrolled in, 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 states the purpose, return fields, and filter options without any redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no required parameters and a well-covered schema. The description provides the essential purpose, output fields, and filter criteria, making it complete for an agent to select and invoke correctly.
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?
The schema provides 100% coverage with descriptions for all three parameters (year, session, response_format). The description merely repeats that year/session filters are possible, adding no extra meaning beyond the 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 lists all enrolled courses on Ed and returns the course name, code, and Ed course ID. It distinguishes from sibling tools like moodle_list_courses by explicitly naming the Ed platform.
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 that this is for Ed courses and that year/session filtering is available. However, it does not explicitly state when to prefer this tool over alternatives such as moodle_list_courses or gradescope_list_courses, so no exclusions are given.
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 annotations already mark the tool as read-only and non-destructive. The description adds useful behavioral context by revealing that discussion rows contain URLs with 'd=' parameters, from which discussion IDs can be extracted, and that this ID is the input to another tool. This goes beyond the structured 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 two short sentences, front-loading the purpose and adding only a useful tip about extracting discussionid. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple one-parameter tool with read-only annotations, the description is complete: it states the resource (forum discussions), the follow-up action (pass id to another tool), and relies on the schema for parameter details. It is sufficient for an agent to select and invoke correctly.
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?
The input schema has full description coverage for the single parameter cmid, explaining it as the course module id from the activity link. The tool description does not add additional parameter semantics, so the baseline of 3 applies.
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 it returns a list of discussions in a forum ('一个论坛里的讨论列表'). It also distinguishes from siblings by referencing discussionid and directing to moodle_get_discussion_posts for post content, 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 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 tool to get a list of forum discussions. It also gives a usage guideline by telling the agent to extract discussionid from the URL and pass it to moodle_get_discussion_posts to view content, effectively differentiating it from the post-content sibling.
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, covering the safety profile. The description adds valuable behavioral context: it automatically finds the Announcements forum and then retrieves the discussion list, which clarifies the internal process beyond what annotations provide.
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 core purpose ('a course's announcements') and then efficiently explains the mechanism. Every word earns its place—no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter, clear annotations, and no output schema, the description is complete: it explains what the tool does, how it works (auto-finds the Announcements forum), and what it returns (discussion list). No additional context is needed for effective use.
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?
The schema has 100% description coverage for the sole parameter courseId, explicitly stating it is the Moodle course id obtained from moodle_list_courses. The tool description does not add further parameter semantics, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 announcements for a course, explaining that announcements are the forum named 'Announcements' and it automatically finds that forum and fetches its discussion list. This specific verb+resource combination distinguishes it from sibling tools like moodle_list_forums and moodle_get_forum_discussions.
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 that this tool is the dedicated way to get course announcements without manually locating the Announcements forum. It implies usage for announcements but does not explicitly name alternatives or exclusions, so it falls short of a 5.
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 the operation as read-only and idempotent, so the description does not need to repeat that. It adds valuable behavioral insight about the URL field (f= vs cmid), which is a potential pitfall, and notes the data source for cmid. This goes beyond the annotations and helps the agent avoid misuse.
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 two sentences long, front-loaded with purpose, and every sentence adds value. It states the outcome, then provides a critical caveat and cross-reference to related tools without any fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/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 parameter and read-only annotations, the description is complete. It states what is returned (forum list with unread counts and subscription status), and includes necessary context about URL field semantics and how to obtain cmid for related operations. No output schema exists, but the description provides enough information for correct invocation.
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?
The input schema fully documents the single parameter courseId with a clear description ('Moodle 课程 id，从 moodle_list_courses 拿'). The tool description does not add parameter-specific details, so it meets the baseline for full 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 tool lists forums for a course, including unread counts and subscription status. It distinguishes itself from sibling tools like moodle_get_forum_discussions by explicitly clarifying the relationship between the forum instance id and cmid.
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 practical guidance: it warns that the f= parameter in the URL is not a cmid and directs users to moodle_get_course_contents for the cmid needed by moodle_get_forum_discussions. This gives clear context for when to use this tool and how to correctly interact with 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?
The key behavioral trait '只改给出的字段，其余保留' (only change the given fields, keep the rest) is disclosed, which is valuable partial-update semantics not provided by annotations. Permission requirements are also mentioned. Annotations (readOnlyHint: false, destructiveHint: false) align with the edit operation, and the description adds meaningful context beyond those hints, though it doesn't cover error cases or return values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that conveys the main purpose, permission condition, and update behavior without any unnecessary words or repetition. Every clause serves a purpose, making it highly efficient.
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?
Given the tool's simplicity (5 flat params, no nested objects) and existing annotations, the description covers the essential aspects: what it edits, who can use it, and the partial-update behavior. However, there is no output schema, and the description does not mention the response format or error handling, which is a slight gap for a mutation tool. Overall, it is adequately complete for an agent to invoke correctly.
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 has only 40% description coverage (content and thread_id described). The description compensates by stating that only provided fields are changed, implying all non-required params are optional and that the tool performs a partial update. This adds meaning beyond the schema's sparse descriptions, though individual field meanings for title, category, and subcategory are left to the agent's 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 clearly states '编辑已有的 Ed 帖子' (edit existing Ed posts), identifying the specific action and resource. It differentiates from creation tools like ed_post_thread by specifying '已有的' (existing) and from other siblings by focusing on editing. The scope is clear and unambiguous.
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 on when to use the tool: it is for editing your own posts or requires faculty permission for others. This gives a clear condition for use, but it does not explicitly mention alternatives or exclusions like 'use ed_thread_action for non-content actions.' It implies usage but not a direct 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description reveals that only specified fields are modified while others are retained, and that it operates only on the caller's workspace. This non-destructive partial-update behavior is valuable context not present in 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 brief and front-loaded, using a single sentence with two clauses. Every word adds value, covering the action, scope, and key behavioral rule without redundancy.
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 update tool with no output schema and minimal annotations, the description covers the essential aspects: what it does, the ownership restriction, and partial update semantics. It might lack details about error handling or return values, but these are not critical given the tool's simplicity.
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 schema description coverage at only 25%, the description compensates by indicating that 'title' is for renaming and 'is_public'/'public_write' are for sharing settings. It also clarifies that parameters are optional and only those provided will be changed, which aids parameter understanding beyond the 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 modifies one's own Ed workspace, covering renaming or sharing settings. This specific verb-resource combination distinguishes it from sibling tools like ed_create_workspace and ed_delete_workspace.
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 update your own workspace's name or sharing settings. It also gives an important usage guideline that only provided fields are changed, implying partial updates, and restricts to 'your own' workspace. It doesn't explicitly name alternatives but the context is sufficient.
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. The description adds useful behavioral context by revealing the return includes hierarchical structure ('完整楼层树') and specific fields (author, attachments, word count), going 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?
Two short sentences with no filler. The first sentence states what the tool does and returns; the second gives the prerequisite source for the parameter. Every clause 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?
With one required parameter and no output schema, the description adequately describes return content (complete thread tree with author, attachments, word count) and parameter acquisition. It doesn't list every possible response field or pagination, but the simple scope does not demand it.
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 provides only a numeric discussionid with 0% description coverage. The description compensates by telling the agent the parameter should come from moodle_get_forum_discussions, giving its semantic origin and making the parameter unambiguous.
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?
Description uses a specific verb '取' (get) and clearly identifies the resource as the complete thread tree of a forum discussion, including author, attachments, and word count. This distinguishes it from sibling moodle_get_forum_discussions which lists discussions.
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?
Explicitly states that discussionid comes from moodle_get_forum_discussions, establishing a clear prerequisite and workflow. It does not enumerate exclusions or alternatives, but the guidance is sufficient for this simple retrieval tool.
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 annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds context beyond this by specifying the returned fields (week, name, deadline, submission status, score) and the 'one page' scope, indicating a consolidated view. No contradictions.
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, well-structured sentence that front-loads the core purpose ('一门课的全部作业总表') and then enumerates the key fields. Every word earns its place, with no redundancy or fluff.
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 one parameter and strong annotations, the description is complete enough. It lists the output fields, making the return structure predictable without requiring an output schema. It doesn't mention pagination or ordering, but the 'one page' hint implies completeness. Minor gaps prevent a 5, but it's well-suited to the tool's simplicity.
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 has 100% coverage with a single courseId parameter. The description adds value by explaining its origin ('from moodle_list_courses'), which helps the agent source the correct ID. This goes beyond the schema's type-only definition, justifying a score above the baseline.
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 it lists all assignments for a course with key fields (week, name, deadline, submission status, score), distinguishing it from sibling tools like moodle_get_assignment (singular) and moodle_get_grades (grades-only). The verb 'list' and resource 'assignments' are specific and unambiguous.
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 its usage for getting a comprehensive assignment overview in one page. It does not explicitly name alternatives or exclusions, but the context is clear that this is the go-to tool for a full assignment listing. Without explicit alternatives, it falls short of a 5 but earns a 4 due to clear implied context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond the annotations: it explicitly states the tool is public and requires no login, and it explains that the same course in different semesters or campuses results in different outlines, which informs the agent about potential multiple results and data model nuances.
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 three concise sentences, front-loaded with the main action and resource. Each sentence adds distinct information: functionality, data model nuance, and access requirements. No redundancy or unnecessary detail.
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?
The description covers the essential aspects: what it does, what it returns (semester versions and coids), access condition, and data model nuance. It does not mention the optional 'year' or 'limit' parameters, but given no output schema and simple parameter set, the description is sufficiently complete for an agent to invoke the tool correctly.
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 description coverage is 67%, with course_code and year described. The tool description reinforces that the search is by course_code but does not add information about the 'year' or 'limit' parameters. Since the schema already covers most semantics, the description is adequate but not compensatory for the missing 'limit' explanation.
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 action: search UNSW official course outlines by course code. It distinguishes from the sibling tool 'unsw_fetch_course_outline' by emphasizing the search/find functionality and returning semester versions with coids, which implies a lookup step before fetching a specific outline.
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: use this tool to find course outlines by course code. It implies that the returned coid can be used to fetch details, likely via the sibling tool 'unsw_fetch_course_outline', but it does not explicitly state when not to use this tool or name alternatives.
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 known. The description enriches this by specifying that results are grouped by semester, that course IDs are included, and that environment variables are required — useful operational 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, front-loaded sentence that efficiently conveys scope (all Gradescope courses), grouping (by semester), purpose (course IDs for assignments), and prerequisites (env vars). No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/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 list operation, the description covers the essential aspects: what it does, how results are organized, why the course IDs matter, and what setup is needed. No output schema exists, so no return-value details are required, and nothing else seems missing.
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 zero parameters in the input schema, so the description correctly omits parameter details. The baseline of 4 applies because there is no parameter semantics to add.
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 identifies the tool as listing all Gradescope courses, grouped by semester, with course IDs. It explicitly references the sibling tool gradescope_list_assignments for using those IDs, distinguishing it from other platform course listers like moodle_list_courses or ed_list_courses.
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 states the tool's purpose (providing course IDs for gradescope_list_assignments) and prerequisites (GRADESCOPE_EMAIL/GRADESCOPE_PASSWORD env vars), giving clear context for when to use it. It does not explicitly exclude alternatives, but the platform name 'Gradescope' disambiguates from sibling tools on other platforms.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, but the description adds crucial behavioral details: no recycle bin (permanent deletion), deleting first post deletes the whole discussion, and the editing window with explicit error behavior. This goes well beyond the annotations and fully discloses consequences and failure modes.
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 two sentences, highly scannable with bold warnings. Every clause carries essential information: what is deleted, permanence, cascade deletion of first posts, and time restrictions. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the destructive nature of the tool and the absence of an output schema, the description covers all critical aspects: action, scope, side effects, constraints, and error behavior. An agent can fully assess the impact before invoking the tool, making it contextually complete.
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?
The schema has 100% coverage: the postid parameter is described as 'the post id to delete, obtained from moodle_get_discussion_posts.' The tool description itself does not add parameter-specific detail, but the schema already provides sufficient semantics, so the baseline 3 applies.
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 and resource: deleting one's own Moodle forum post or reply. It distinguishes from siblings by specifying self-only scope and the special consequence of deleting a first post (deletes entire discussion), leaving no ambiguity about what the 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use it (for deleting your own posts/replies) and explicit constraints: only within the editing window (usually 30 minutes), and deletion is permanent. However, it does not name alternative tools (e.g., moodle_post_forum_discussion) for non-delete actions, so it lacks explicit when-not guidance, but the context is sufficiently 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?
The description adds the behavioral fact that '回复立即全班可见' (the reply is immediately visible to the whole class) and explains the subject default mechanism, both of which go beyond the annotations. Annotations already indicate a non-read-only, non-idempotent, non-destructive operation, and the description complements this without 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?
The description is compact, with the core purpose stated first, a key parameter hint embedded, and an important visibility warning highlighted in bold. Every sentence contributes useful information without redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation tool with fully described parameters and no output schema, the description covers all essential aspects: what it does, how to obtain the required postid, the optional subject behavior, and the side effect of immediate class-wide visibility. It is sufficiently complete for an agent to select and invoke the tool correctly.
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 already provides 100% parameter coverage with descriptions for postid, message, and subject. The description enhances understanding by telling the user to source postid from moodle_get_discussion_posts and clarifying that subject defaults to 'Re: original title', adding value beyond the schema's raw property 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 uses the specific verb+resource construction '回复 Moodle 论坛里的某个帖子' (reply to a Moodle forum post), clearly stating the tool's action. This distinguishes it from sibling tools like moodle_post_forum_discussion (new thread) and moodle_delete_forum_post (removal). The scope 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a direct usage hint: postid is obtained from moodle_get_discussion_posts, implying a prerequisite call. It clearly implies this tool is for replying to an existing post rather than creating a new discussion, though it does not explicitly name alternatives like moodle_post_forum_discussion. The subject-default behavior also provides practical guidance for invocation.
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 readOnly, idempotent, and non-destructive. The description adds behavioral context beyond that: if only course_code is given, it will search first and pick the first of multiple semester versions. It also clarifies the scope of the returned outline content, but does not cover edge cases or error handling.
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?
Two dense sentences with the main action front-loaded ('取一门课的完整官方大纲'), followed by a useful bullet-like enumeration of contents. Every phrase earns its place, including the emphasized AI-usage note for each assignment.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with no output schema, the description sufficiently enumerates the key components of an outline and explains both invocation modes (coid vs course_code). This gives the agent enough context to set expectations and select the correct parameters.
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?
Schema coverage is 100%, so baseline is 3. The description enriches semantics by explaining the either/or relationship between coid and course_code ('和 coid 二选一') and the search fallback when only course_code is provided, which is not fully explicit in the schema alone.
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 '取一门课的完整官方大纲' and enumerates the specific contents (assessments, learning objectives, weekly schedule, academic integrity). It distinguishes itself from the sibling unsw_find_course_outline by being the full-outline retrieval tool, while referencing coid from that 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?
Provides clear parameter-selection guidance: '给 coid 直接取；只给课程代码的话会先搜一次' tells the agent when to supply coid vs course_code and the fallback behavior. However, it does not explicitly name or compare against the sibling unsw_find_course_outline, so it lacks an explicit when-not/alternatives statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
注解只表明非只读、非破坏性，描述额外披露了 markdown 自动转 XML、发出即上线无草稿、is_private 时仅教职工和本人可见，这些是注解无法覆盖的关键行为。
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?
两句话涵盖核心动作、格式转换、发布特性、隐私设置，信息密度高，无冗余。
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?
对创建帖子的核心行为交代清楚，包括格式转换、发布状态、隐私范围。但未说明成功后的返回内容或可能的错误，在无输出 schema 的情况下略显不足。
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?
描述为 content（自动转 XML）和 is_private（可见范围）提供了额外说明，但 subcategory、thread_type、is_anonymous 等参数无额外解释。schema 覆盖率为 50%，描述部分补偿了缺失。
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?
描述明确说'在 Ed 课程论坛发新帖'，具体动词+资源+平台，清楚区别于 ed_post_comment、ed_edit_thread 等兄弟工具。
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?
描述暗示这是创建新帖的工具，并补充了发布即生效、无草稿等特性。虽然没有显式说明何时不用（如编辑已有帖子），但结合兄弟工具名称，上下文足够清晰。
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 read-only, idempotent, and non-destructive. The description adds valuable behavioral detail by stating that the returned content is decoded as text ('返回内容按文本解码') and that only Moodle internal URLs are accepted. This goes beyond the annotation-provided 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 extremely concise, consisting of two sentences. The first states the primary purpose, and the second delivers key parameter and behavior instructions without any filler. It is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and strong annotations, the description covers all necessary aspects: the exact URL format, the source of the URL, and the output decoding behavior. It provides enough context for the agent to use the tool correctly, even without an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only lists a required 'url' with format uri, but the description enriches this meaning by specifying that the URL must be a full link starting with 'pluginfile.php' and should be taken from other tool returns. This is essential additional guidance for correctly constructing the parameter, fully compensating for the lack of schema parameter 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 tool downloads files from Moodle, with a specific verb ('下载') and resource ('Moodle 上的文件'). It further distinguishes itself by requiring the URL to start with 'pluginfile.php' and be a Moodle internal address, which differentiates it from similar download tools like ed_download_resource.
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 usage context: use the URL returned by other tools (从其他工具的返回里拿), and only accept Moodle internal addresses. It doesn't explicitly mention alternatives, but the specificity about pluginfile.php and Moodle-only addresses effectively guides the agent on when 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false, and the description adds valuable role-based permission context beyond that. It does not contradict annotations and gives insight into authorization requirements, though it does not detail potential side effects beyond the action semantics.
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 conveys both purpose and role constraints without unnecessary words. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple toggle tool with two parameters and no output schema, the description plus schema fully covers what the tool does, the available actions, and role restrictions. It is complete enough for an agent to select and invoke correctly.
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 covers thread_id with a description, but action only has an enum. The description compensates by explaining the role-based meaning of the action values, adding semantic context beyond the schema. It does not further explain thread_id but the schema already does.
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 toggles Ed thread status ('切换 Ed 帖子状态') and lists the specific actions (star, unstar, pin, unpin, lock, unlock, endorse, unendorse). It distinguishes from sibling tools like ed_get_thread and ed_post_thread by specifying the action verb and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly separates which actions are available to students (star/unstar) versus those requiring staff role (pin/unpin/lock/unlock/endorse/unendorse). This provides clear role-based usage guidance, helping the agent determine when the tool is appropriate and what permissions are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only signal a non-read-only operation. The description adds critical non-obvious behaviors: the post is immediately visible to the entire class, there is no draft or recall, and permission-restricted forums cause an error. This significantly exceeds 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 two concise sentences. The first defines the action, the second delivers crucial warnings. No redundant information or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 3-parameter write tool with no output schema, this description covers purpose, parameter sourcing, visibility, irreversibility, and an error condition. It leaves no meaningful gaps for an agent to misuse the tool.
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 input schema already describes all 3 parameters at 100% coverage. The description adds valuable meaning by specifying that cmid must come from moodle_get_course_contents and be a forum activity's course module id, which enriches the schema for the agent.
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: '发一个新讨论帖' (post a new discussion topic) in a Moodle forum. It explicitly distinguishes itself from siblings like moodle_reply_forum_post and moodle_delete_forum_post by focusing on creating a new discussion thread.
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?
It gives practical guidance on sourcing cmid from moodle_get_course_contents for forum activities and warns that read-only forums will error. It does not explicitly name alternative tools or state 'when not to use', but the context is clear enough for correct selection.
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:

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

Score Badge

Copy to your README.md:

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

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/r1ckyIn/unsw-mcp'

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