Server Quality Checklist

Tool Scores

• download_resourceB
  3.1/5.0
  Behavior2/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 of behavioral disclosure. It states the tool downloads files and supports custom directories, but fails to mention critical behaviors such as authentication requirements (implied by Moodle context), error handling (e.g., invalid URLs), file overwriting risks, or rate limits. This leaves significant gaps for a tool that interacts with external resources.

  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 front-loaded with the core purpose in the first sentence and adds a supporting detail in the second. It avoids redundancy and wastes no words, making it efficient. However, it could be slightly more structured by separating key behaviors, but overall it's appropriately concise for its content.

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

  Completeness2/5

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

  Given the tool's complexity (involving external downloads and file system operations), no annotations, and no output schema, the description is incomplete. It lacks details on authentication, error responses, file naming, or success indicators, which are crucial for safe and effective use. The schema covers parameters well, but behavioral aspects are underspecified.

  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%, with clear documentation for both parameters (resource_url and download_path), including format examples and default behavior. The description adds marginal value by mentioning 'Moodle resource' and 'custom local directory,' which contextualizes the parameters but doesn't provide additional semantic details beyond what the schema already covers.

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

  Purpose4/5

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

  The description clearly states the verb ('Download') and resource ('Moodle resource file(s)'), specifying file types like PPT and PDF. It distinguishes from siblings by focusing on downloading rather than retrieving information (e.g., get_course_content) or opening URLs. However, it doesn't explicitly differentiate from open_URL_with_authorization, which might also involve URL access, leaving slight ambiguity.

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

  Usage Guidelines3/5

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

  The description implies usage for downloading files from Moodle URLs, but provides no explicit guidance on when to use this tool versus alternatives like open_URL_with_authorization for URL access or get_course_content for content retrieval. It mentions saving to a custom directory, which hints at context for file storage, but lacks clear when-not-to-use or prerequisite information.

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

• get_all_coursesB
  3.1/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden but only states the basic operation. It doesn't disclose behavioral traits such as whether this is a read-only operation, potential rate limits, authentication requirements, or what format the courses/URLs are returned in. This leaves significant gaps for a tool that presumably returns 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 a single, efficient sentence that front-loads the core purpose with zero wasted words. Every element ('Get all available courses and URLs from Moodle') directly contributes to understanding the tool's function.

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

  Completeness2/5

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

  Given the tool's complexity (data retrieval with no output schema) and lack of annotations, the description is incomplete. It doesn't explain what 'all available courses' means (e.g., for current user, all in system), how URLs are structured, or the return format, leaving the agent with insufficient context for reliable 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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, earning a baseline score of 4 for not adding unnecessary 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 action ('Get') and resource ('all available courses and URLs from Moodle'), making the purpose immediately understandable. It doesn't differentiate from sibling tools like 'get_course_content' or 'get_class_schedule', which prevents a score of 5.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives like 'get_course_content' or 'get_class_schedule'. The description only states what it does, not when it's appropriate, leaving the agent to infer usage from context.

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

• get_pending_eventsB
  3.1/5.0
  Behavior2/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 behavioral disclosure. It states what the tool does but lacks details on traits like whether it's read-only, requires authentication, has rate limits, or what the output format might be. This is inadequate for a tool with zero annotation coverage.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that front-loads the core purpose with zero wasted words. It's appropriately sized for a simple tool with no parameters, making it easy for an agent to parse quickly.

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

  Completeness2/5

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

  Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what the return values might be (e.g., event details, deadlines), behavioral aspects like authentication needs, or how it differs from sibling tools. For a tool with no structured data support, this leaves significant gaps.

  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 0 parameters, and schema description coverage is 100%, so there's no need for parameter details in the description. The baseline for this scenario is 4, as the description doesn't need to compensate for any parameter gaps, and it correctly implies no inputs are required.

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

  Purpose4/5

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

  The description clearly states the action ('Get') and resource ('upcoming events and deadlines from Moodle calendar'), making the purpose immediately understandable. It doesn't differentiate from sibling tools like 'get_class_schedule' or 'get_course_content', which might also involve calendar data, so it doesn't reach the highest score for sibling distinction.

  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 like 'get_class_schedule' or 'get_course_content', which might overlap in functionality. There's no mention of prerequisites, context, or exclusions, leaving the agent with minimal usage direction.

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

• open_URL_with_authorizationB
  3.2/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries full burden. It discloses that the action opens a browser window and involves Moodle login, but lacks details on behavioral traits like whether it requires specific permissions, handles errors, or has side effects (e.g., session management). For a tool with user interaction and authentication, this is a significant gap in 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, efficient sentence that front-loads the core action ('Open a URL') and includes all necessary context ('authorized browser window', 'after Moodle login', 'show to user'). There is zero waste, and every phrase earns its place by clarifying the tool's purpose and usage.

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

  Completeness2/5

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

  Given the tool's complexity (involving user interaction and authentication), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what happens on success/failure, return values, or potential errors. For a tool that likely has behavioral nuances, more context is needed to be fully helpful to 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?

  Schema description coverage is 100%, with the single parameter 'url' documented in the schema as 'Target URL to open after Moodle login'. The description adds no additional parameter semantics beyond this, as it doesn't elaborate on URL format, constraints, or examples. Baseline 3 is appropriate since the schema handles the parameter documentation adequately.

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

  Purpose4/5

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

  The description clearly states the action ('Open a URL') and the resource ('authorized browser window'), specifying it happens 'after Moodle login' and is 'show[n] to user'. It distinguishes from siblings like download_resource or get_course_content by focusing on browser navigation rather than data retrieval. However, it doesn't explicitly contrast with all siblings (e.g., get_current_time).

  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 context ('after Moodle login', 'show to user'), suggesting this tool is for user-facing navigation post-authentication. It doesn't provide explicit when-not-to-use guidance or name alternatives among siblings. The context is clear but lacks explicit exclusions or comparative guidance with other tools.

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

• get_course_contentA
  3.5/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the prerequisite call but doesn't describe what 'Get all assignments/resources' returns (list format, pagination, error conditions), whether it's read-only or has side effects, or any authentication/rate limit considerations. The description provides minimal behavioral context beyond the basic 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 extremely concise (one sentence) with zero wasted words. It's front-loaded with the core purpose and efficiently includes the prerequisite information. Every element earns its place without redundancy.

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

  Completeness3/5

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

  For a single-parameter read operation with no output schema, the description is minimally adequate. It covers the purpose and prerequisite but lacks details about return format, error handling, or behavioral traits. Given the simplicity of the tool (1 parameter, no annotations), it's borderline viable but leaves significant gaps in understanding the tool's behavior.

  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 schema already documents the single parameter 'course_name' with its exact format requirement. The description adds marginal value by reinforcing the 'exact name' constraint and linking it to 'get_all_courses,' but doesn't provide additional semantic context beyond what's in the schema. Baseline 3 is appropriate when schema does the heavy lifting.

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

  Purpose4/5

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

  The description clearly states the tool's purpose: 'Get all assignments/resources for a course by exact name.' It specifies the verb ('Get'), resource ('assignments/resources'), and scope ('for a course'). However, it doesn't explicitly differentiate from sibling tools like 'download_resource' or 'get_all_courses' beyond the prerequisite call mention.

  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: 'call get_all_courses first' establishes a prerequisite workflow. It implies this tool should be used after retrieving course names from another tool. However, it doesn't explicitly state when NOT to use this tool or name alternatives for similar operations.

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

• get_class_scheduleA
  3.7/5.0
  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 behavioral disclosure. It explains the temporal scope ('this week'), filtering behavior, and optimization guidance about avoiding multiple calls. However, it doesn't mention potential rate limits, authentication requirements, error conditions, or what format the schedule data returns (though no output schema exists).

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

  Conciseness5/5

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

  The description is extremely concise (two sentences) and front-loaded with the core purpose. Every sentence earns its place: the first establishes what the tool does and parameter usage, the second provides important optimization guidance. Zero wasted words.

  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 single-parameter read tool with no annotations and no output schema, the description is adequate but has gaps. It explains the basic functionality and parameter usage well, but doesn't describe the return format, error handling, or what 'this week' means precisely. The optimization guidance is helpful, but more context about the schedule structure would improve completeness.

  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 description coverage is 100%, so the parameter 'date' is already documented in the schema. The description adds some value by clarifying that null returns 'full week' and providing the YYYY-MM-DD format, but doesn't explain what 'full week' means (e.g., Monday-Sunday, current 7-day period) or edge cases. Baseline 3 is appropriate when schema does most of the work.

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

  Purpose4/5

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

  The description clearly states the tool's purpose: 'Get class schedule in this week' specifies the verb (get) and resource (class schedule) with a temporal scope (this week). It distinguishes from siblings like 'get_all_courses' or 'get_pending_events' by focusing specifically on schedule data. However, it doesn't explicitly differentiate from potential schedule-related siblings that might not exist.

  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 guidance: 'pass null for full week, or date (YYYY-MM-DD) to filter' explains when to use each parameter option. 'If you need multiple days, pass null once instead of multiple calls' offers optimization advice, though it doesn't explicitly mention when to use this tool versus alternatives like 'get_pending_events' for event data.

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

• get_current_timeA
  4/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries full burden. It discloses the return format but lacks behavioral details like timezone handling, freshness guarantees, or error conditions. The description is accurate but minimal for behavioral context.

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

  Conciseness5/5

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

  The description is a single, efficient sentence with zero waste. It front-loads the core purpose and includes essential format details, making it optimally concise and well-structured for its 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?

  Given the tool's low complexity (0 parameters, no annotations, no output schema), the description is nearly complete. It covers purpose and output format adequately, though minor gaps in behavioral details prevent a perfect score.

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

  Parameters4/5

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

  With 0 parameters and 100% schema coverage, the baseline is 4. The description appropriately omits parameter details since none exist, focusing instead on the output format, which adds value beyond the empty 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 specific verb ('Get') and resource ('current local datetime'), with precise format details ('YYYY-MM-DD HH:MM:SS'). It distinguishes itself from siblings by focusing solely on time retrieval rather than courses, schedules, or resources.

  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 current datetime is needed, but provides no explicit guidance on when to use this versus alternatives or exclusions. No sibling tools offer similar time functionality, so differentiation isn't critical, but general context is missing.

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