campus-unr-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation2/5
Several tools overlap significantly: get_grades_report and get_course_grades both return course grades per user with nearly identical outputs, and list_groups vs list_group_members and list_activities vs get_course_contents provide redundant views. This creates selection ambiguity for an agent.
Naming Consistency4/5
Most tools follow a verb_noun pattern with snake_case, but the choice of verb is inconsistent (get_ vs list_ for similar read operations). This is a minor deviation from an otherwise predictable scheme.
Tool Count4/5
At 20 tools, the server is on the higher end but each tool covers a distinct Moodle feature (forums, quizzes, grades, activities, users). The count is appropriate for a campus integration.
Completeness4/5
The read side is comprehensive, covering courses, categories, contents, users, groups, forums, assignments, quizzes, and grades. The write side is more limited but includes the key actions (posting, grading, messaging, calendar events), covering most common workflows.
Average 4.1/5 across 20 of 20 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 8 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It does mention the return format ('JSON array of assignments with submission and grade counts'), which is helpful, but it omits details about read-only safety, required permissions, pagination, sorting, or potential errors.
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 concise and well-structured: a one-sentence summary, followed by an Args section and a Returns line. Every sentence earns its place with no redundant filler, 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?
Given the simple context (one required integer parameter, output schema present), the description is reasonably complete. It states the return type and contents, and the output schema covers detailed field structure. The main gap is lack of usage guidance, but that is addressed in the usage_guidelines dimension.
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 0% description coverage for the single parameter, and the description adds only 'The Moodle course ID' to the property name 'course_id'. This provides minimal context (identifying the platform) but does not elaborate on how to obtain the ID or any format/validation constraints, only partially compensating for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'List assignments' with the additional scope of 'submission stats', making the core purpose specific. It does not explicitly differentiate from sibling tools like get_assignment_submissions or list_activities, but the verb+resource+extra detail is sufficient for basic understanding.
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 get_assignment_submissions or list_activities. It only gives a parameter definition and return type, with no mention of prerequisites, typical 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the return format (JSON array with id, name, cmid, discussion count) and that it lists forums per course, but does not explicitly state read-only behavior, permissions, or edge cases like hidden forums.
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 concise and well-structured: a one-line summary, then Args and Returns sections. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool, the description covers what it does, the parameter, and the return shape. However, it lacks sibling differentiation or caveats, which would make it fully 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 a single course_id integer with 0% description coverage, so the description's 'The Moodle course ID' is the only semantic explanation. It clarifies the domain but provides no format, range, or example.
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 'List forums in a course with discussion counts' – a specific verb, resource, and scope that distinguishes it from sibling tools like list_forum_discussions (which lists discussions within a forum) and create_forum_discussion.
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 doesn't mention any exclusions or compare to sibling tools like list_forum_discussions or create_forum_discussion. The only usage context is implied by the purpose itself.
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?
With no annotations, the description carries full burden. It indicates a read-only 'list' operation and specifies the return format ('JSON array of submissions with status, dates, and content'). It does not disclose permissions, edge cases, or any side effects, but for a simple read tool the basic transparency 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 compact and well-structured: a one-sentence purpose, an Args section with the necessary clarification, and a Returns summary. Every element 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 single-parameter list tool with an existing output schema, the description covers the operation, the critical parameter distinction, and the return summary. It lacks guidance on when to use it, but is otherwise sufficiently complete for the tool's simplicity.
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 schema only provides type and title for assignment_id, but the description adds a crucial semantic clarification: 'The assignment instance ID (not course module ID).' This prevents a likely misuse and fully compensates for the 0% schema description coverage.
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 ('List') and resource ('submissions for a specific assignment'), making it distinct from siblings like list_assignments or get_grades_report based on the meaning of 'submissions'. However, it does not explicitly differentiate from alternative tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as get_grades_report or save_assignment_grade. It only states the tool's function without exclusions or contextual triggers.
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?
With no annotations, the description must carry the full burden of disclosing behavioral traits. It only mentions the return format (which is likely covered by the output schema) and does not disclose whether the operation requires specific permissions, how errors are handled, or any rate-limit implications. The non-destructive nature is implied but not stated.
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 crisp, well-organized, and front-loaded with a one-sentence summary. It then breaks down arguments and return values in a structured way without excess verbiage.
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 read-only list operation, the description covers the essential invocation details: what it lists, what parameters mean, and what the output shape is. It lacks usage guidance and permission context, but given the simple nature and presence of an output schema, it is sufficiently complete for correct invocation.
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?
Schema description coverage is 0%, but the description fully compensates by explaining course_id as 'The Moodle course ID' and role with examples and default behavior ('Empty = all'). It adds practical meaning beyond the raw schema, including a list of common role values.
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 'List users enrolled in a course with their roles', using a specific verb and resource. It distinguishes the tool from siblings like list_group_members (group-specific) and get_grades_report (grade-specific) by focusing on enrolled users and role information.
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 such as list_group_members or get_course_grades. The description only states what it does, not under what circumstances it should be chosen, and lacks any exclusions or context about alternative 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?
With no annotations, the description carries the burden. It discloses the return format ('JSON with grade items and grades per user') and the optional behavior of user_id (0 or omitted = all users). It does not mention permissions, limitations, or potential errors, but for a read-only 'Get' tool, the information provided is adequate though not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-sentence purpose, an Args list, and a Returns clause. Every sentence provides necessary information without unnecessary detail or repetition.
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 is complete for a simple read-only report tool: it covers purpose, parameters, and return format. It lacks notes on edge cases or authorization, but given the tool's low complexity and presence of an output schema, the description is sufficient for an agent to invoke it correctly.
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 schema has no descriptions, so the tool description fully compensates. It clearly explains course_id as 'The Moodle course ID' and user_id as 'Optional user ID to get grades for one student only. 0 or omitted = all enrolled users.' This adds crucial meaning beyond the schema's bare type/default information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get grade report for a course (all users or a specific user).' The verb 'Get' and resource 'grade report' are specific. However, it does not explicitly differentiate from the sibling tool get_course_grades, which may have similar functionality, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by defining the scope (all users or a specific user) and the optional user_id behavior. However, it provides no explicit guidance on when to use this tool versus alternatives like get_course_grades, and it does not mention exclusions or prerequisites.
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?
With no annotations, the description carries the burden. It explicitly discloses the return format (JSON array with subject, author, message, reply count, dates) and notes that message content is included. However, it does not mention any permissions, rate limits, or state that it is read-only, though 'List' implies a read operation.
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 and well-structured with a clear statement, an Args section, and a Returns section. Every sentence adds value; there is no redundant text 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 an output schema, the description provides sufficient context: it explains the parameter and describes the return payload. It does not mention pagination or potential size limits, but these are not critical for a basic listing operation.
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 only provides parameter name and type with 0% coverage. The description adds meaning by explaining what forum_id represents and directs users to list_forums to get it. This compensates well for the schema's lack of detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it lists discussions in a forum, including message content. The verb 'List' and resource 'discussions in a forum' are specific, and it distinguishes from sibling list_forums by targeting discussions within a forum rather than the forums themselves.
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?
Provides a useful prerequisite by referencing list_forums to obtain the forum_id, but does not explicitly explain when to use this tool over alternatives like create_forum_discussion or reply_forum_post. The usage context is implied but not formally contrasted 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?
With no annotations, the description carries the burden of behavioral disclosure. It adds context about the return scope ('every enrolled student') and format ('JSON array'), which is helpful, but it does not disclose potential size/performance implications, prerequisites (e.g., course enrollment visibility), or error behavior. 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 appropriately concise and front-loaded with the main purpose. It uses a clear Args/Returns structure without unnecessary verbosity. Every sentence adds value, and the format is easy to scan.
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 (one parameter) and the presence of an output schema, the description covers the essentials: purpose, parameter semantics, and return type. However, it does not explicitly differentiate itself from sibling get_grades_report, nor does it mention any caveats about large result sets or permissions, leaving slight ambiguity about when this tool is preferred.
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 single parameter course_id is documented in the description as 'The Moodle course ID', adding semantic meaning beyond the schema's bare integer type. Since schema description coverage is 0%, the description fully compensates for the single parameter, making it clear what the agent must provide.
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 ('Get') and specific resource ('all grade items for a course'), and further clarifies scope by listing examples ('quizzes, assignments, etc.') and describing the return data. This distinguishes it from similar sibling tools like get_grades_report or get_assignment_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 usage context is implied: it is the tool to call when you need all grade items/student grades for a course. However, it does not explicitly mention when not to use it or provide alternatives, leaving the agent to infer based on the tool name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It explicitly states the return format as JSON with listed fields, and implies a safe read-only operation through the verb 'Get' and the returned data. It also reveals that it returns details about the current user, which inherently implies authentication requirements.
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 a clear verb-object structure and a separate line listing the return fields. Every word earns its place; there is no filler or redundant information.
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, no-parameter, read-only tool with an output schema, the description provides all necessary information: what it retrieves and what the response contains. The output schema covers detailed field structure, so the description need not elaborate further.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema has no properties to document. The baseline of 4 applies, and the description confirms no inputs are needed by focusing entirely on the output.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves site information and current user details, using the verb 'Get' and a specific resource. This directly distinguishes it from sibling tools that handle grades, 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?
There is no guidance on when to use this tool versus alternatives, nor any conditions or prerequisites. It only states what the tool does without situational context, leaving the agent to infer when it might be appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the grouping behavior and the return format ('JSON object mapping activity type -> list of activities'). However, with no annotations, it does not cover error behavior, permissions, or handling of edge cases (e.g., invalid course_id), leaving some behavioral aspects undisclosed.
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 concise and well-structured. The purpose is front-loaded in the first sentence, and the Args/Returns sections are clearly separated. Every sentence adds value without unnecessary detail.
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 read-only listing tool with a single parameter and an existing output schema, the description adequately covers input, output, and grouping behavior. It is complete enough 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 input schema provides no description for course_id, only type and title. The description adds 'The Moodle course ID', clarifying the meaning and thus compensating for the 0% schema coverage. For a single parameter, this is sufficient.
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 ('List') and the resource ('all activities in a course'), and further specifies the grouping by type. This differentiates it from sibling tools like list_forums or list_assignments, which target specific activity types.
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 when to use this tool (when you want all activities for a course), but it does not explicitly mention alternatives or provide exclusions. Sibling tools exist for specific activity types, but no direct guidance is offered on choosing between them.
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?
With no annotations provided, the description carries the full burden. It discloses the return format (JSON array with id, name, description) but does not explicitly state that it is a read-only operation, mention permission requirements, or describe error handling for invalid course IDs.
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 concise, well-structured with Args and Returns sections, and immediately states the tool's purpose. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter listing tool, the description is largely complete. It explains the return format even though an output schema exists. It could benefit from mentioning authentication requirements or error scenarios, but these are not critical for basic use.
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 schema has no parameter descriptions (0% coverage), but the 'Args' section fully explains course_id as 'The Moodle course ID.' This adds meaningful context beyond the bare integer type.
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 groups in a course, using a specific verb and resource. It distinguishes itself from sibling tools like list_group_members by focusing on groups rather than members.
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 (to get the list of groups for a course) but does not explicitly state when to prefer this over alternatives like list_group_members or get_course_contents. No exclusions or prerequisites 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?
No annotations are provided, so the description must carry the full burden. It discloses the return format (JSON array of sections/modules) and implies read-only behavior via 'Get', but does not mention error conditions, permissions, or pagination. This is a moderate gap given no 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 concise and well-structured, with the main purpose in the first sentence and clear Arg/Returns sections. Every sentence earns its place with no 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?
The tool is simple (one parameter, output schema exists), and the description adequately covers purpose and return structure. However, it omits details about potential errors or access restrictions, and it does not differentiate itself from the sibling list_activities tool. Given the simplicity, this is acceptable but not fully 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 has only one parameter with no description coverage (0%). The description compensates by explaining 'course_id: The Moodle course ID', adding semantic meaning beyond the schema's type and title. It does not include examples or edge cases, but fully explains the 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 uses a specific verb ('Get') and resource ('all sections and activities/resources in a course'), clearly distinguishing it from sibling tools like get_grades_report or list_assignments. The scope is explicit 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 context is clearly stated: use this to retrieve a course's full content structure. However, it does not explicitly mention alternatives or when not to use it (e.g., if only grades are needed), so it lacks explicit 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?
With no annotations provided, the description carries the burden of behavioral disclosure. It indicates a read-only operation by saying 'List', and it describes the return format (JSON array with specific fields). However, it does not mention any authentication requirements, pagination, sorting, or potential errors. The description is adequate but not rich in behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the purpose, followed by a concise return value listing. Every sentence earns its place, and there is 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 simple tool with zero parameters and a clear output schema, the description provides sufficient information about what it does and what it returns. It does not mention edge cases (e.g., empty list, inactive courses), but given the simplicity, this is not a significant gap. It is complete for its intended use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter information required. The schema coverage is 100% trivially. The baseline for zero parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 courses where the current user is enrolled, using a specific verb ('List') and a specific resource ('courses'). It distinguishes from sibling tools like list_categories (categories) and get_course_contents (contents of a single course) by the scope of 'where the current user is enrolled'.
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 the tool: when the current user wants to see their enrolled courses. It does not explicitly name alternatives or mention when not to use it, but the context is unambiguous. 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full behavioral transparency. It specifies the return format (JSON array of groups with name, member count, and members) and the required argument. However, it doesn't disclose any authorization requirements, error behaviors, or potential limitations (e.g., whether it returns all groups or only visible ones), leaving some behavioral 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 concise and well-structured: it states the purpose in one line, lists the argument with its meaning, and clearly specifies the return format. Every sentence earns its place and there is 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 simple listing tool with one parameter and an output schema, the description covers the essential aspects: what it does, what input it needs, and what it returns. It could mention edge cases or usage caveats, but overall it is sufficiently complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines course_id as an integer with no description, and schema coverage is 0%. The description compensates by stating 'course_id: The Moodle course ID,' adding valuable semantic context. For a single parameter, this is sufficient to clarify its meaning, though it doesn't elaborate on format or constraints.
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 opens with a specific verb and resource: 'List groups (comisiones) with their member lists.' It clearly differentiates from sibling tools like list_groups by emphasizing the inclusion of member lists, and it names the required input (course_id) and the returned structure.
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 clearly implies when to use this tool: when you need groups and their member details for a specific Moodle course. Though it doesn't explicitly mention alternatives or exclusion cases, the scope is clear enough from the wording and the context of 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?
No annotations are provided, so the description carries the full burden. It discloses the return format (JSON array with state, score, timestamps) and the user_id filter behavior ('0 = current user only'). While it does not explicitly state that the operation is read-only, the verb 'List' strongly implies non-mutating behavior, and no hidden side effects are indicated.
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 well-structured with an opening sentence and an Args/Returns format. Every line serves a purpose, with 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?
For a simple two-parameter tool with a stated return array, the description covers the essential aspects: purpose, parameters, and output. It could benefit from noting potential permissions or pagination, but given the low complexity and the presence of an output schema, the description 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 description coverage is 0%, so the description must compensate. It explains quiz_id as 'the quiz instance ID' and user_id with the meaningful detail that 0 means current user, adding valuable semantics beyond the bare schema property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List attempts for a quiz' with a specific verb and resource, and the addendum '(parcial/examen)' provides useful context. This clearly distinguishes it from sibling tools like get_assignment_submissions and get_grades_report, which target different entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing quiz attempts but does not explicitly state when to use it versus alternatives or mention exclusions. The parameter and return details make the intended use inferable, but there is no direct guidance on choosing this tool over similar siblings.
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?
No annotations exist, so the description must disclose behavior. It does this well by explaining the dry_run mode ('By default runs in dry_run mode. Set dry_run=False to actually create') and the return value ('Returns: JSON with validated status and eventid if created'). It does not mention auth or error side effects, but the most critical behavioral trait is covered.
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 concise and well-structured: a one-line purpose, a critical dry_run note, a neatly formatted Args list, and a Returns line. Every section serves a clear function, with no fluff or repetition.
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 6-param mutation tool with no annotations, the description covers parameter semantics, the dry-run safety mechanism, and the return behavior. It lacks explicit error handling or prerequisite details, and does not position the tool relative to sibling tools, but overall it is reasonably complete for an AI agent to use correctly.
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?
With 0% schema description coverage, the description's Args section fully compensates. It explains all six parameters, gives a concrete ISO datetime example for timestart, and notes defaults for eventtype and dry_run. This adds substantial meaning beyond the raw 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 opens with 'Create a calendar event', a specific verb+resource that clearly states the action. It even includes examples ('fecha de examen, entrega, etc.') and is distinct from sibling tools which focus on reads/lists and other domains like forums or 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 clearly implies this tool is for creating calendar events, and the dry_run default with 'Set dry_run=False to actually create' conveys a validation-first workflow. However, it does not explicitly state when to use this tool versus alternatives or mention any exclusions, so guidance is implicit rather than fully 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?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. It reveals the safety default of dry-run, specifies the validation behavior, and describes the return format ('JSON with validated status and confirmation'). This goes beyond the schema (which only shows default values) and gives the agent a clear expectation of the tool's side effects. It does not mention permissions or overwrite behavior, but given the dry-run safeguard, the disclosed traits are relevant and reasonably complete.
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 well-structured and efficiently sized. It opens with a one-line purpose, follows with a note on the dry-run behavior, enumerates parameters in a clear list, and ends with the return type. Every sentence earns its place, and the format is easy for an LLM to parse. No redundant or filler content is present.
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 has 5 parameters with no schema descriptions and no annotations, yet the description provides a clear purpose, parameter semantics, and usage workflow. It also mentions the output format, which is slightly redundant given the output schema exists but is not harmful. The description is adequate for a save operation, though it could enhance completeness by noting error cases or whether it overwrites existing grades. Overall, it is complete enough for the tool's complexity.
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?
Schema description coverage is 0%, so the description must compensate, and it does comprehensively. It defines all five parameters with meaningful details: assignment_id (instance ID), user_id (student ID), grade (numeric 0-10), feedback (optional text), and dry_run (validate without saving). This adds critical semantics not present in the raw schema, such as the valid grade range and the meaning of the dry_run flag.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Save a grade for a student's assignment (TP).' This is a specific verb+resource combination that immediately distinguishes it from sibling read-only tools like list_assignments or get_grades_report. The action is unambiguous and matches the tool name without being tautological.
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 explains the dry-run workflow ('By default runs in dry_run mode. Set dry_run=False to actually save'), which gives useful usage context. However, it does not explicitly mention when to choose this tool over alternatives or when not to use it. Alternatives are not named, so 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?
With no annotations, the description carries the burden of disclosure. It clearly states the return format (JSON array with id, name, parent, depth, course count) and adds semantic context about category hierarchy. It doesn't cover ordering, pagination, or error/authentication behavior, but for a parameterless list tool this is reasonably transparent.
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, front-loaded with the action, and includes only essential context and return details. Every sentence earns its place: purpose, background, and output format.
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 tool's simplicity (no params, simple list output) and the presence of an output schema, the description is complete. It explains what categories are, what is returned, and is fully sufficient for an agent to select and invoke this 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 tool has zero parameters, so schema coverage is vacuously 100%. Per the rubric, baseline for 0 parameters is 4. The description adds no parameter-specific info, but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists course categories, specifying the Moodle-specific meaning of categories as hierarchical organizers by faculty, degree, year, or period. This verb+resource combination uniquely distinguishes it from sibling list tools like list_courses, list_groups, etc.
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 useful context on what categories are and how they relate to courses, which implies when to use this tool (when you need the category hierarchy). However, it doesn't explicitly state when not to use it or mention alternative tools for related tasks, so it falls just 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?
With no annotations provided, the description carries the full burden. It discloses the dry_run safety behavior, that it validates without posting, and that it returns a JSON with a validated status and postid when posted. It lacks details on auth, error cases, or side effects, but the most critical behavioral traits are covered.
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 and well-structured: a one-sentence purpose, a clear note on dry_run, an Args list, and a Returns line. No wasted words; 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 4-parameter tool, the description covers purpose, parameters, dry_run behavior, and return value. It is missing potential error handling or permission notes, but the core usage is complete. Given the tool's low complexity and the presence of an output schema, this is sufficient.
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?
Schema description coverage is 0%, so the description must explain all parameters. It does: post_id is 'the ID of the post being replied to (parent)', subject and message are self-explanatory, and dry_run is described as 'If True (default), validate without posting.' This adds meaning beyond the bare schema titles and fully compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Reply to an existing forum post.' This clearly distinguishes it from siblings like create_forum_discussion (creation) and list_forum_discussions (listing). It also specifies the action's scope ('existing') with no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states the dry_run default and how to switch to actual posting ('Set dry_run=False to actually post'). This gives clear context on when to use the tool in validation vs. live mode. However, it does not explicitly name alternatives or say when not to use this tool (e.g., for new discussions), though that is implied by 'existing.'
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?
With no annotations, the description carries full burden. It transparently discloses the dry-run default, the side-effect when dry_run=False, and the return shape (validated status and msgid). It does not mention authentication, rate limits, or failure modes, but for a simple messaging tool 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 well-structured: a one-sentence purpose, a key safety note, a labeled Arg list, and a Returns line. Every sentence earns its place; 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?
For a simple messaging tool with an output schema, the description covers purpose, parameters, safety mode, and return behavior. It lacks explicit error-case context but is otherwise complete for the tool's complexity.
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?
Schema description coverage is 0%, so the description must compensate. It provides clear, meaningful descriptions for all three parameters: user_id, message, and dry_run, exactly matching the schema and adding semantic clarity about validation behavior.
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 opens with 'Send an instant message to a user', a specific verb and resource that immediately clarifies the tool's function. No sibling tool has similar messaging purpose, so it is inherently distinguished.
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 clearly states the default dry_run behavior and instructs to set dry_run=False to actually send, providing practical usage guidance. However, it does not explicitly compare to alternatives or state when not to use it, though no alternatives exist.
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 discloses the default dry_run mode, explains that it validates permissions only, and instructs setting dry_run=False to actually post. It also mentions the return format (validated status, discussionid if posted) and that HTML is allowed in the message, providing rich behavioral context beyond the bare create action.
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 well-structured with a brief summary, a clear note about dry_run, and a compact Args list. Every sentence serves a purpose and there is no fluff, making it both informative and concise.
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 create operation with 4 parameters and no annotations, this description covers the essential context: what the tool does, how to use it, the default dry-run behavior, and what is returned. It is complete enough for an agent to select and invoke the tool correctly without needing additional documentation.
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?
Although the input schema has no descriptions, the tool description fills this gap completely by explaining each parameter: forum_id, subject, message, and dry_run. It adds valuable guidance like 'use list_forums to get it' and 'HTML allowed', going far beyond the schema's minimal titles.
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 'Create a new discussion (tema) in a forum' with a specific verb and resource. It distinguishes from siblings like reply_forum_post and list_forum_discussions by explicitly targeting new discussion 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?
It provides clear context for when to use this tool (creating a new discussion) and even directs users to list_forums for obtaining forum_id. However, it does not explicitly mention that reply_forum_post should be used for replies, so it lacks explicit exclusions.
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:

[![campus-unr-mcp MCP server](https://glama.ai/mcp/servers/jpmanson/campus-unr-mcp/badges/card.svg)](https://glama.ai/mcp/servers/jpmanson/campus-unr-mcp)

Score Badge

Copy to your README.md:

[![campus-unr-mcp MCP server](https://glama.ai/mcp/servers/jpmanson/campus-unr-mcp/badges/score.svg)](https://glama.ai/mcp/servers/jpmanson/campus-unr-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/jpmanson/campus-unr-mcp'

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