Gradescope MCP Server

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools have distinct purposes targeting specific resources and actions, such as grading, rubric management, or data retrieval. However, some overlap exists between tools like tool_assess_submission_readiness and tool_smart_read_submission, which both assess submissions for grading readiness, potentially causing confusion in tool selection.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern with snake_case, such as tool_apply_grade, tool_get_assignment_details, and tool_update_rubric_item. This predictability makes it easy for agents to understand and navigate the toolset without naming conflicts.
Tool Count2/5
With 33 tools, the count is excessive for a grading-focused server, leading to potential overwhelm and inefficiency. A more streamlined set of 10-20 tools could cover the same domain without redundancy, such as merging similar assessment or retrieval tools.
Completeness5/5
The toolset provides comprehensive coverage of the Gradescope domain, including CRUD operations for grades, rubrics, assignments, and submissions, along with advanced features like answer groups, regrades, and statistics. No significant gaps are apparent for grading workflows.
Average 4/5 across 33 of 33 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 8 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It implies a write operation ('Upload') and includes a 'confirm_write' parameter as a safety measure, but doesn't disclose permissions needed, rate limits, whether uploads are reversible, or what happens on success/failure. For a mutation tool with zero annotation coverage, this is inadequate.
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 efficiently structured with a clear purpose statement followed by a bullet-point-like parameter list. Every sentence serves a purpose, though the parameter explanations could be more detailed. It's appropriately sized for a 5-parameter tool.
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?
Given the tool's complexity (write operation, 5 parameters, no annotations) and the presence of an output schema (which reduces need to describe returns), the description is minimally adequate. It covers the core action and parameters but lacks behavioral context, usage guidelines, and detailed parameter semantics, leaving gaps for the 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 0%, so the schema provides no parameter documentation. The description adds basic semantics by listing parameters with brief explanations (e.g., 'List of absolute file paths to upload'), but doesn't elaborate on formats (e.g., what constitutes a valid course_id) or constraints (e.g., file size limits). It compensates partially but not fully 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 action ('Upload files') and target ('as a submission to a Gradescope assignment'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'tool_get_assignment_submissions' or 'tool_get_student_submission', which are read operations versus this write operation.
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 prerequisites (e.g., needing course/assignment access), exclusions, or comparisons to sibling tools like 'tool_assess_submission_readiness' or 'tool_export_assignment_scores'. The agent must infer usage from the purpose alone.
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?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns specific details (name, dates, status, grade), which adds some behavioral context. However, it lacks information on permissions required, rate limits, error handling, or whether it's a read-only operation (implied by 'Get' but not explicit). For a tool with no annotations, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the purpose, followed by return details and parameter explanations. Every sentence adds value, with no redundant information. However, the structure could be slightly improved by more clearly separating usage guidance from parameter semantics.
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?
Given the tool has an output schema (which likely defines return values), the description doesn't need to explain returns in detail. However, with no annotations and 0% schema coverage for inputs, the description partially compensates with parameter context but lacks behavioral details like auth needs or error cases. For a simple read operation, it's adequate but has clear gaps in completeness.
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 adds meaning by explaining that 'course_id' is a 'Gradescope course ID' and 'assignment_id' is 'found via get_assignments', providing context beyond the schema's generic titles. This clarifies the source and usage of parameters, though it doesn't detail formats or constraints.
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 detailed information about a specific assignment.' It specifies the verb ('Get') and resource ('assignment'), and lists the returned details (name, dates, status, grade). However, it doesn't explicitly differentiate from siblings like 'tool_get_assignments' (which lists assignments) or 'tool_get_assignment_statistics' (which might provide aggregated data), though the focus on 'detailed information' for a 'specific' assignment implies some distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating it returns details for a 'specific assignment' and references 'tool_get_assignments' to find the assignment_id, suggesting a workflow. However, it doesn't explicitly state when to use this tool versus alternatives like 'tool_get_assignment_submissions' or 'tool_get_assignment_outline', nor does it provide exclusions or prerequisites beyond needing IDs.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions access control ('instructor/TA only'), which is useful, but does not disclose other traits such as whether this is a read-only operation, potential rate limits, error conditions, or what the output looks like (though an output schema exists). For a tool with no annotations, this leaves significant gaps in understanding its behavior beyond basic purpose.
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 appropriately sized and front-loaded: the first sentence states the purpose and access restriction, followed by a structured 'Args' section. There is no wasted text, and it efficiently conveys key information in two parts. However, it could be slightly more polished by integrating the args into the flow, but it remains clear and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters, no annotations, but an output schema exists, the description is reasonably complete. It covers the purpose, access control, and parameters, and the output schema will handle return values. However, it lacks details on behavioral aspects like error handling or usage nuances, which could be important for a tool with no annotations. Overall, it's adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes an 'Args' section that lists and briefly describes the two parameters ('course_id' and 'question_id'), adding meaning beyond the input schema, which has 0% description coverage. However, it does not provide detailed semantics like format examples or constraints (e.g., what a valid ID looks like). With low schema coverage, the description compensates partially but not fully, aligning with the baseline expectation.
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 the list of graders assigned to a specific question' with the qualification '(instructor/TA only)'. It specifies the verb ('Get'), resource ('list of graders'), and scope ('assigned to a specific question'). However, it does not explicitly differentiate from sibling tools like 'tool_get_course_roster' or 'tool_get_assignment_details', which might also involve retrieving course-related data, so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by specifying '(instructor/TA only)', indicating it's for authorized users only, but it does not provide explicit guidance on when to use this tool versus alternatives. For example, it doesn't clarify if this is for grading management versus other grader-related tools (though none are listed as siblings). The context is clear but lacks exclusions or named alternatives.
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?
No annotations are provided, so the description carries full burden. It mentions the artifact is cached in /tmp and includes specific components, but doesn't disclose behavioral traits like whether this is a read-only operation, if it requires specific permissions, potential rate limits, or what happens on failure. For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior.
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 appropriately sized and front-loaded, starting with the main purpose and listing included components. The Args section is clear and necessary given low schema coverage. There's minimal waste, though it could be slightly more streamlined by integrating the parameter explanations into the main text.
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?
Given no annotations, 0% schema coverage, and an output schema present (which reduces need to explain return values), the description is moderately complete. It covers the tool's purpose and parameters but lacks details on behavioral aspects like error handling or performance. For a tool with 4 parameters and no annotations, it should provide more context on usage constraints or outcomes.
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 adds meaning by explaining each parameter's purpose: course_id, assignment_id, and question_id are required for identification, while submission_id is optional for providing rubric/page context. This clarifies semantics beyond the schema's basic titles, though it doesn't detail formats or constraints.
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 ('prepare') and the resource ('cached /tmp markdown artifact for grading a question'), specifying it includes prompt, rubric, reference-answer notes, page URLs, crop regions, and confidence gate. It distinguishes from siblings like tool_grade_answer_group or tool_get_question_rubric by focusing on artifact preparation rather than grading or rubric retrieval, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when preparing grading artifacts, such as for auto-grading with a confidence gate, but doesn't explicitly state when to use this tool versus alternatives like tool_prepare_answer_key or tool_get_submission_grading_context. It mentions optional submission_id for rubric/page context, suggesting context for when to include it, but lacks clear exclusions or named sibling comparisons.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool returns a table with specific fields (names, IDs, dates, status, and grades), which adds value beyond the input schema. However, it doesn't cover critical behavioral aspects such as whether this is a read-only operation, potential rate limits, authentication needs, or error handling, leaving significant gaps for a tool with no annotation support.
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 sized and front-loaded: the first sentence states the purpose, the second describes the return format, and the third provides parameter guidance. Every sentence earns its place with no wasted words, making it efficient and well-structured for quick understanding.
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 (one parameter) and the presence of an output schema (which handles return values), the description is mostly complete. It covers purpose, output format, and parameter semantics adequately. However, without annotations, it lacks details on behavioral traits like safety or performance, which slightly reduces completeness for an agent's full understanding.
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 description adds meaningful semantics for the single parameter 'course_id' by explaining it's 'The Gradescope course ID (found via list_courses),' which clarifies its source and context. Since there's only one parameter and schema description coverage is 0%, this compensation is effective, though it doesn't detail format or constraints beyond the schema's basic type.
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 for a specific Gradescope course.' It specifies the verb ('Get') and resource ('assignments'), and distinguishes it from siblings like 'tool_get_assignment_details' by indicating it retrieves all assignments rather than details of a single one. However, it doesn't explicitly contrast with all relevant siblings (e.g., 'tool_get_assignment_submissions'), so it's not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage guidance by mentioning that 'course_id' is 'found via list_courses,' which suggests using 'tool_list_courses' first. It doesn't explicitly state when to use this tool versus alternatives like 'tool_get_assignment_details' or 'tool_get_assignment_submissions,' nor does it provide exclusions or detailed context, so it's adequate but lacks explicit guidelines.
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?
No annotations are provided, so the description carries the full burden. It discloses behavioral traits such as returning a 'crop-first read plan', 'fallback rules', and a 'coarse confidence score', which adds context about outputs. However, it lacks details on permissions, rate limits, or side effects, which are important for a tool that might influence grading decisions.
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 sized and front-loaded: the first sentence states the purpose, followed by details on returns and parameters. Every sentence adds value without redundancy, making it efficient and well-structured.
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 complexity (assessing submission readiness) and the presence of an output schema (which likely covers return values), the description is mostly complete. It explains the purpose, parameters, and key outputs like confidence scores. However, without annotations, it could benefit from more behavioral context, such as error handling or performance implications.
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 0%, so the description must compensate. It lists the four parameters (course_id, assignment_id, question_id, submission_id) and briefly explains they are IDs for Gradescope entities, adding meaning beyond the schema. However, it does not provide format details or examples, leaving some gaps in parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to assess whether an agent should auto-grade a specific submission. It specifies the verb 'assess' and the resource 'submission readiness', distinguishing it from siblings like tool_apply_grade (which applies grades) or tool_get_submission_grading_context (which retrieves context).
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 auto-grading decisions but does not explicitly state when to use this tool versus alternatives. It mentions returns like 'crop-first read plan' and 'coarse confidence score', suggesting it's for pre-grading assessment, but lacks explicit guidance on prerequisites or comparisons to siblings like tool_smart_read_submission or tool_get_next_ungraded.
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 of behavioral disclosure. It adds useful context such as the return format ('assignment-level summary... per-question breakdowns'), highlights specific outputs ('low-scoring questions'), and mentions access requirements. However, it lacks details on rate limits, error handling, or data freshness, which are important for a statistical tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, starting with the core purpose and key outputs, followed by access requirements and parameter explanations. Every sentence adds value, with no redundant information. Minor improvements could include bullet points for clarity, but overall it's efficient and well-structured.
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 moderate complexity, no annotations, and the presence of an output schema (which handles return values), the description is largely complete. It covers purpose, outputs, access needs, and parameter context. However, it could benefit from more behavioral details like performance characteristics or usage limits to fully guide the agent in all scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful semantics beyond the input schema, which has 0% description coverage. It explains that 'course_id' and 'assignment_id' refer to 'Gradescope course ID' and 'assignment ID', respectively, providing context that the schema's generic titles ('Course Id', 'Assignment Id') do not. This compensates well for the low schema coverage, though it doesn't detail format constraints like ID structure.
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 with specific verbs ('Get comprehensive statistics') and resources ('assignment'), and distinguishes it from siblings like 'tool_get_assignment_details' by focusing on statistical analysis rather than general information. However, it doesn't explicitly contrast with all similar siblings like 'tool_export_assignment_scores', which slightly limits differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage context by stating 'Requires instructor/TA access', indicating when authorization is needed. It doesn't explicitly state when to use this tool versus alternatives like 'tool_export_assignment_scores' or 'tool_get_assignment_details', nor does it mention exclusions or prerequisites beyond access, leaving some ambiguity for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses access requirements ('Requires instructor/TA access') and output behavior ('Returns a summary table...'), which is helpful. However, it misses details like rate limits, error handling, or whether the export is destructive (e.g., file generation). The description doesn't contradict annotations, as none exist.
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 sized and front-loaded, starting with the core purpose, followed by output details, access requirements, and parameter explanations in a logical flow. Every sentence adds value without redundancy, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no annotations, but has an output schema), the description is reasonably complete. It covers purpose, output, access needs, and parameter semantics. With an output schema present, it doesn't need to detail return values, though it could mention behavioral aspects like side effects or limitations.
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 adds meaning by explaining that 'course_id' is 'The Gradescope course ID' and 'assignment_id' is 'The assignment ID,' providing context beyond the schema's generic titles. This clarifies the parameters' roles, though it could specify format or constraints.
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 as 'Export per-question scores for an assignment' with specific verb ('Export') and resource ('per-question scores for an assignment'). It distinguishes itself from siblings like 'tool_get_assignment_statistics' by focusing on export functionality, though it doesn't explicitly contrast with all related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context with 'Requires instructor/TA access,' indicating prerequisites. However, it lacks explicit guidance on when to use this tool versus alternatives like 'tool_get_assignment_statistics' or 'tool_get_assignment_submissions,' leaving the agent to infer based on the 'export' focus.
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 carries the full burden. It discloses access requirements ('Requires instructor or TA access') and return format ('Returns a table of extensions with user ID, name, and modified dates'), which adds useful behavioral context. However, it lacks details on rate limits, error handling, or pagination, leaving gaps for a read operation with no annotation support.
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 sized and front-loaded: the first sentence states the purpose, followed by return details and access requirements, with parameter explanations in a clear 'Args' section. Every sentence adds value without redundancy, making it efficient and well-structured.
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 moderate complexity (2 parameters, no annotations, but with an output schema), the description is mostly complete. It covers purpose, access requirements, parameters, and return format. Since an output schema exists, it need not explain return values in detail, but it could benefit from mentioning sibling tool relationships or error cases for full 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 0%, but the description compensates by listing and briefly explaining both parameters ('course_id: The Gradescope course ID' and 'assignment_id: The assignment ID'). This adds meaning beyond the bare schema. However, it does not provide format examples, constraints, or links to other tools, so it meets the baseline for partial compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get all student extensions for a specific assignment.' It specifies the verb ('Get'), resource ('student extensions'), and scope ('for a specific assignment'), making it easy to understand. However, it does not explicitly differentiate from sibling tools like 'tool_set_extension' or 'tool_modify_assignment_dates', 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage: 'Requires instructor or TA access.' This indicates prerequisites and when the tool is applicable. However, it does not explicitly state when to use this tool versus alternatives (e.g., 'tool_set_extension' for modifying extensions or 'tool_get_assignment_details' for general assignment info), so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 does well by stating access requirements ('Requires instructor/TA access') and describing what the dashboard shows. However, it doesn't mention potential limitations like rate limits, whether the data is real-time or cached, error conditions, or response format details. For a tool with no annotations, this leaves some behavioral aspects unclear.
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 perfectly structured and concise: a clear purpose statement, followed by what the dashboard shows, then access requirements, and finally parameter explanations. Every sentence adds value with zero wasted words. It's front-loaded with the core functionality and efficiently covers necessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values), no annotations, and simple parameters, the description is reasonably complete. It covers purpose, usage context, access requirements, and parameter basics. The main gap is lack of behavioral details like rate limits or error handling, but the output schema reduces the need to describe return format. For a read-only progress dashboard tool, this is fairly 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?
Schema description coverage is 0%, so the schema provides no parameter documentation. The description compensates by listing both parameters (course_id and assignment_id) and explaining they are Gradescope IDs. However, it doesn't provide format examples, validation rules, or where to find these IDs. Given the 0% schema coverage, the description adds meaningful but incomplete parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get the grading progress dashboard for an assignment' with specific details about what it shows (grading status, submissions graded, assigned graders, completion percentage). It distinguishes from siblings like tool_get_assignment_statistics or tool_get_assignment_submissions by focusing on grading progress rather than general statistics or raw submissions. However, it doesn't explicitly name alternatives, keeping it at 4 instead 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: when needing grading progress information for an assignment. It specifies access requirements ('Requires instructor/TA access'), which helps determine appropriateness. It doesn't explicitly state when not to use it or name specific alternatives among the many sibling tools, but the context is sufficiently clear for effective usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the key behavioral trait: 'Auto-discovers a submission to extract rubric data,' which explains how it works without a submission ID. However, it doesn't cover other important aspects like authentication requirements, rate limits, error conditions, or what happens if no submission is found. The description adds some value but leaves significant 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 perfectly concise and well-structured. It starts with the core purpose, explains the auto-discovery mechanism, provides usage guidance, and lists parameter meanings—all in four brief sentences with zero wasted words. Every sentence earns its place by adding essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no annotations, but with an output schema), the description is reasonably complete. It covers the purpose, usage context, and parameter meanings. The presence of an output schema means the description doesn't need to explain return values. However, it lacks details on behavioral aspects like error handling or permissions, which would be helpful for full 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?
Schema description coverage is 0%, so the schema provides no parameter documentation. The description adds basic semantics: 'course_id: The Gradescope course ID' and 'question_id: The question ID from outline.' This clarifies what the parameters represent, but it doesn't provide format details, constraints, or examples. Since there are only 2 parameters, this minimal explanation is adequate for a baseline score.
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 rubric items for a question' with the specific constraint 'without needing a submission ID.' It distinguishes itself from sibling tools like 'tool_get_submission_grading_context' or 'tool_get_student_submission' that likely require submission IDs. However, it doesn't explicitly name these alternatives, preventing a perfect score.
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 explicit guidance on when to use this tool: 'Use when you know the question_id from outline but don't have a submission ID yet.' It clearly defines the prerequisite context (having a question_id but lacking a submission ID). It doesn't specify when NOT to use it or name alternative tools, which keeps it from a score of 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the tool downloads files to /tmp for local review, which implies read-only caching behavior. However, it doesn't mention permissions needed, rate limits, file cleanup, or error handling, leaving gaps for a tool that interacts with file systems.
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 front-loaded with the core action, followed by usage context and parameter list. Every sentence adds value without redundancy, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters with 0% schema coverage and no annotations, the description does a good job explaining purpose and usage. The presence of an output schema means return values don't need description. However, it lacks details on error cases or system interactions, which could be important for a file-download tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists all four parameters (course_id, assignment_id, question_id, submission_id) in the Args section, providing basic semantics. However, it doesn't explain what these IDs represent or their formats, which limits understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool downloads specific pages to a local directory for review, with a specific verb ('Download') and resource ('crop page and neighboring pages'). It distinguishes from siblings by focusing on page caching rather than grading or management tasks, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: for scanned exams where prompts are in page images and agents need to inspect adjacent pages before grading. It doesn't explicitly state when not to use it or name specific alternatives among siblings, but the context is well-defined.
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?
No annotations are provided, so the description carries the full burden. It mentions that it returns links to submission files, which is helpful behavioral information. However, it doesn't disclose important traits like whether this is a read-only operation, potential rate limits, authentication requirements beyond the role hint, or what happens if no submission exists. For a tool with zero annotation coverage, this leaves significant 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 efficiently structured with a clear purpose statement, role restriction, return value information, and parameter explanations in a bullet-like format. Every sentence earns its place with no wasted words, and the most important information (what the tool does) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there's an output schema (which handles return value documentation), the description doesn't need to explain return values in detail. However, for a tool with 3 parameters, 0% schema coverage, and no annotations, the description should provide more behavioral context about error conditions, permissions, and operational constraints to be 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 description coverage is 0%, so the description must compensate. It provides clear semantic meaning for all three parameters (course_id, assignment_id, student_email), explaining what each represents. This adds substantial value beyond the bare schema, though it doesn't specify format details like email validation or ID patterns.
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 action ('Get a specific student's most recent submission'), identifies the resource (submission files), and distinguishes it from siblings like tool_get_assignment_submissions (which likely returns all submissions) by specifying it's for a single student's most recent submission. The instructor/TA restriction further clarifies the access context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'instructor/TA only', providing clear context about when to use this tool based on user role. However, it doesn't mention when to use alternatives like tool_get_assignment_submissions or tool_smart_read_submission, nor does it specify prerequisites beyond the parameters.
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 key behavioral traits: access restrictions ('instructor/TA only'), performance characteristics ('May be slow for large classes'), and return format ('Returns a list of submission IDs and file counts'). This covers important operational context beyond basic functionality.
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 efficiently structured: purpose statement first, return format second, performance note third, and parameter explanations last. Every sentence adds value with zero waste, making it easy to scan and understand quickly.
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 2 parameters, no annotations, and an output schema (which handles return values), the description is reasonably complete. It covers purpose, access, performance, and parameters. It could mention pagination or error cases, but for a read-only tool with output schema, it's mostly adequate.
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 0%, so the description must compensate. It documents both parameters (course_id, assignment_id) with brief explanations, adding meaning beyond the schema's titles. However, it doesn't provide format details, examples, or constraints, so it only partially compensates 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's purpose: 'Get all submissions for an assignment' with the specific resource (submissions) and verb (get). It distinguishes from siblings like 'tool_get_student_submission' (singular) and 'tool_get_assignment_details' (metadata). However, it doesn't explicitly contrast with all relevant siblings, keeping it at 4 rather than 5.
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: 'instructor/TA only' specifies the required role, and 'May be slow for large classes' warns about performance limitations. It doesn't explicitly state when NOT to use it or name alternatives (e.g., 'tool_get_student_submission' for individual submissions), so it's not a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: it returns a structured reading plan with prioritized tiers (crop region, full page, adjacent pages), a confidence score, and a recommended action. However, it lacks details on permissions, rate limits, error handling, or whether it's read-only or mutative, leaving gaps for an AI agent.
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 sized and front-loaded: the first sentence states the core purpose, followed by a bulleted list detailing the output structure, and ends with parameter explanations. Every sentence adds value without redundancy, making it efficient and well-structured for quick comprehension.
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 complexity (involving tiered analysis), no annotations, and an output schema (which covers return values), the description is mostly complete. It explains the purpose, output format, and parameters well. However, it could improve by addressing behavioral aspects like permissions or error cases, slightly reducing completeness for an AI agent.
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 description coverage is 0%, so the description must compensate. It explicitly lists all four parameters (course_id, assignment_id, question_id, submission_id) and clarifies they are IDs for Gradescope entities, adding crucial meaning beyond the schema's generic titles like 'Course Id'. This fully addresses the parameter semantics gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('get a smart, tiered reading plan') and identifies the resource ('student's submission'). It distinguishes itself from siblings by focusing on reading plan generation rather than grading, assessment, or data retrieval functions like tool_get_student_submission or tool_assess_submission_readiness.
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 through the parameters (course_id, assignment_id, etc.), suggesting it's for analyzing specific submissions within Gradescope. However, it doesn't explicitly state when to use this tool versus alternatives like tool_get_student_submission or tool_assess_submission_readiness, nor does it mention prerequisites 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 provided, the description carries the full burden. It discloses access requirements ('Requires instructor/TA access') and hints at the return content ('hierarchical question structure with IDs, types, weights, and question text'), but lacks details on rate limits, error handling, or whether it's read-only (implied by 'Get' but not explicit).
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 sized and front-loaded: the first sentence states the purpose, followed by key details on returns and access, with a brief parameter section. Every sentence adds value without redundancy, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (2 parameters, no annotations, but has an output schema), the description is mostly complete. It covers purpose, usage context, and parameter semantics, but since the output schema exists, it need not explain return values. A minor gap is lack of behavioral details like error cases or performance.
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 adds meaning by explaining that course_id is 'The Gradescope course ID' and assignment_id is 'The assignment ID', clarifying their roles beyond the schema's generic titles. However, it does not specify format or constraints (e.g., numeric vs. string IDs).
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 action ('Get the question/rubric outline') and resource ('for an assignment'), distinguishing it from siblings like tool_get_assignment_details or tool_get_question_rubric by focusing on hierarchical structure rather than general details or specific rubric items.
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 by stating this is 'Essential for understanding how an assignment is structured' and 'Requires instructor/TA access', which helps guide usage. However, it does not explicitly mention when not to use it or name alternatives among siblings, such as tool_get_assignment_details for broader information.
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 key behaviors: it returns grading context or a completion message, handles optional submission_id with auto-discovery, and supports output formats. However, it lacks details on permissions, rate limits, or side effects (e.g., whether navigation affects state). It adds useful context but is incomplete for a tool with mutation-like navigation.
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 front-loaded with the core purpose, followed by return behavior and parameter details in a structured format. Every sentence adds value—no fluff or repetition—making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (navigation with auto-discovery), no annotations, and an output schema (which handles return values), the description is largely complete. It covers purpose, usage, parameters, and output behavior. However, it lacks some behavioral context like error handling or prerequisites, leaving minor 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?
Schema description coverage is 0%, so the description must compensate. It explains all four parameters: course_id and question_id as required IDs, submission_id as optional with auto-discovery behavior, and output_format with default and options. This adds significant meaning beyond the bare schema, though it could detail ID formats or validation rules.
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 action ('Navigate to the next ungraded submission') and resource (grading context), distinguishing it from siblings like tool_get_submission_grading_context (which gets context for a specific submission) or tool_get_grading_progress (which tracks overall progress). It precisely defines the verb and scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (grading workflow) and mentions an alternative outcome ('all submissions are graded'), but does not explicitly state when to use this tool versus alternatives like tool_get_submission_grading_context (for a known submission) or tool_get_grading_progress (for progress overview). It provides clear context but lacks explicit sibling differentiation.
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 of behavioral disclosure. It adds useful context: it mentions the return format ('table of pending and completed regrade requests') and access requirements ('Requires instructor/TA access'). However, it lacks details on potential side effects, rate limits, or error handling, leaving some behavioral aspects unclear.
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 front-loaded with the core purpose in the first sentence, followed by return details and access requirements, then parameter explanations. Every sentence earns its place with no wasted words, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no annotations, but with an output schema), the description is largely complete. It covers purpose, return format, access requirements, and parameters. Since an output schema exists, it needn't explain return values in detail, but it could benefit from mentioning any limitations (e.g., pagination) to achieve full completeness.
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 description coverage is 0%, so the description must compensate. It explicitly lists and describes both parameters ('course_id: The Gradescope course ID' and 'assignment_id: The assignment ID'), adding clear meaning beyond the bare schema. This fully compensates for the lack of schema descriptions, though it doesn't provide examples or format specifics.
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 action ('List all regrade requests') and resource ('for an assignment'), distinguishing it from siblings like tool_get_regrade_detail (which fetches details for a specific request) and tool_get_assignment_submissions (which focuses on submissions rather than regrade requests). The verb 'List' is precise and the scope 'all regrade requests' is well-defined.
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 by specifying 'Requires instructor/TA access,' which indicates when to use this tool based on user permissions. However, it does not explicitly state when not to use it or name alternatives (e.g., tool_get_regrade_detail for fetching details of a specific request), which prevents a perfect score.
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 describes the return data comprehensively (rubric items, evaluations, score, comments, navigation URLs, images) and implies a read-only operation, but does not disclose behavioral traits like authentication needs, rate limits, or error conditions.
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 front-loaded with the purpose, followed by a detailed list of returns, and ends with usage guidance and parameter explanations. Every sentence adds value with zero waste, making it efficient and well-structured.
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 complexity (grading context tool), no annotations, and an output schema exists, the description is mostly complete. It details what the tool returns and when to use it, but lacks information on permissions, errors, or pagination that could enhance completeness.
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 lists all three parameters (course_id, question_id, submission_id) and clarifies they are IDs for Gradescope entities, adding meaning beyond the bare schema. However, it does not provide format examples 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 clearly states the verb 'Get' and resource 'full grading context for a question submission', specifying it returns rubric items, evaluations, score, comments, navigation URLs, and images. It distinguishes from siblings like tool_apply_grade (which applies grades) and tool_get_question_rubric (which focuses only on rubric).
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 by stating 'Use this before applying grades', which implicitly guides when to use it relative to tool_apply_grade. However, it does not explicitly mention when not to use it or name alternative tools for similar purposes.
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 of behavioral disclosure. It describes the return format (grouped by role, with specific fields) and implies a read-only operation, but lacks details on permissions, rate limits, or error handling. It adds some context but is not comprehensive for a tool with 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 front-loaded with the core purpose in the first sentence, followed by essential return details in the second. Both sentences add value without redundancy, making it efficient and well-structured for quick understanding.
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 (0 parameters, output schema exists), the description is largely complete, covering purpose and return data. However, with no annotations, it could benefit from more behavioral context (e.g., authentication requirements or limitations) to fully compensate for the lack of structured metadata.
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 omits parameter details, focusing on the tool's purpose and output, which aligns with the schema's completeness.
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 action ('List all Gradescope courses') and resource ('for the authenticated user'), distinguishing it from sibling tools that focus on assignments, rubrics, submissions, or grading. It precisely defines the tool's scope without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying 'for the authenticated user' and listing return data (courses grouped by role, with details like ID and assignment count), which helps differentiate it from tools like tool_get_course_roster. However, it does not explicitly state when not to use it or name alternatives, leaving some guidance implicit.
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 of behavioral disclosure. It mentions the access requirement and includes a 'confirm_write' parameter as a safety measure, which adds useful context. However, it lacks details on potential side effects (e.g., if renaming affects linked data), rate limits, or error conditions, leaving gaps for a mutation tool.
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 front-loaded with the core purpose, followed by access requirements and parameter details in a clear, bullet-like structure. Every sentence earns its place with no wasted words, making it highly efficient and easy to parse.
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 that this is a mutation tool with no annotations but an output schema exists, the description covers the essential purpose, access needs, and parameters adequately. However, it could benefit from more behavioral context (e.g., confirmation of success/failure outcomes) to fully compensate for the lack of annotations, though the output schema mitigates some 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?
Schema description coverage is 0%, so the description must compensate. It lists all four parameters with brief explanations (e.g., 'The new title for the assignment'), adding meaningful semantics beyond the schema's titles. However, it does not provide format details (e.g., ID formats or title constraints), slightly limiting its utility.
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 action ('Rename an assignment') and the platform ('on Gradescope'), distinguishing it from sibling tools like 'tool_modify_assignment_dates' or 'tool_get_assignment_details'. It uses a precise verb ('rename') and identifies the resource ('assignment').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'Requires instructor or TA access,' providing clear context for when to use this tool based on user permissions. However, it does not specify when not to use it or mention alternatives (e.g., compared to 'tool_modify_assignment_dates'), which prevents a perfect score.
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 full burden and does well by disclosing: 1) the destructive nature ('This modifies student grades'), 2) the confidence gating behavior with specific thresholds, 3) the manual mode option, and 4) the safety mechanism (confirm_write). It doesn't mention rate limits or authentication requirements, but covers key behavioral aspects.
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 efficiently structured: purpose statement first, capabilities listed, warning highlighted, then detailed parameter explanations. Every sentence earns its place, with no redundant information. The bullet-like parameter explanations are clear without being verbose.
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 complexity (8 parameters, destructive operation, no annotations) and the presence of an output schema, the description is complete. It covers purpose, behavioral warnings, parameter semantics, and usage context. The output schema existence means return values don't need explanation in the description.
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 fully compensates by explaining all 8 parameters. It clarifies: rubric_item_ids behavior (items not in list become unchecked), point_adjustment/comment/confidence None semantics (keep unchanged/skip), confidence thresholds with specific ranges, and confirm_write's safety role. This adds substantial meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Apply a grade') and target resource ('student's question submission'), distinguishing it from sibling tools like tool_create_rubric_item or tool_update_rubric_item. It also lists specific capabilities: applying/removing rubric items, setting point adjustments, and adding comments.
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 through the warning about modifying student grades and the confirm_write parameter, but doesn't explicitly state when to use this tool versus alternatives like tool_grade_answer_group or tool_update_rubric_item. It provides some context about confidence gating but lacks explicit guidance on tool selection.
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 of behavioral disclosure. It effectively describes the destructive nature ('WARNING: Removes the item from ALL submissions and recalculates scores'), which is crucial for a mutation tool. It also mentions the 'confirm_write' parameter as a safety measure, adding context beyond basic functionality.
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 front-loaded with the core purpose and critical warning, followed by a clear parameter list. Every sentence adds value, with no wasted words, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (destructive mutation) and lack of annotations, the description does a good job covering purpose, impact, and parameters. Since an output schema exists, it need not explain return values. However, it could benefit from more details on prerequisites or error conditions.
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 description coverage is 0%, so the description must compensate. It lists all four parameters with brief explanations (e.g., 'The Gradescope course ID'), which adds meaning beyond the schema's titles. However, it does not provide detailed semantics like format examples or constraints, leaving some gaps.
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 action ('Delete a rubric item from a question'), identifies the resource ('rubric item'), and distinguishes it from siblings like 'tool_create_rubric_item' and 'tool_update_rubric_item' by specifying deletion rather than creation or modification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (to delete a rubric item) and includes a warning about the impact ('Removes the item from ALL submissions and recalculates scores'), which helps guide usage. However, it does not explicitly mention when not to use it or name specific alternatives among siblings.
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 of behavioral disclosure. It mentions the tool is for inspection ('inspect what answers are in a group'), implying it's read-only, but doesn't explicitly state this or cover other behavioral aspects like authentication needs, rate limits, or error handling. It adds some context about the output format but lacks comprehensive behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a clear purpose statement, usage guideline, and parameter list in just a few sentences. Every sentence adds value without redundancy, making it easy to parse and front-loaded with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 parameters, no annotations, but with an output schema), the description is reasonably complete. It covers purpose, usage, and parameters adequately. The presence of an output schema means the description doesn't need to explain return values, but it could benefit from more behavioral context (e.g., read-only confirmation).
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 description lists all four parameters with brief explanations, adding meaning beyond the schema (which has 0% description coverage). It clarifies that 'output_format' accepts 'markdown' or 'json' for structured output, which is not evident from the schema alone. However, it doesn't provide deeper semantics for IDs (e.g., format or sourcing), leaving some gaps.
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 action ('Get detail for one answer group') and the resources involved ('members, crops, graded status'). It distinguishes from sibling tools like 'tool_get_answer_groups' (which likely lists groups) and 'tool_grade_answer_group' (which performs grading), making the purpose unambiguous and well-differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'Use this to inspect what answers are in a group before batch-grading.' This provides clear context and distinguishes it from grading tools like 'tool_grade_answer_group', offering practical guidance for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that this is a read operation (listing/showing clusters) and mentions the efficiency benefit of batch grading. However, it doesn't cover important behavioral aspects like authentication requirements, rate limits, pagination, error conditions, or what happens if no groups exist. The description adds some context but leaves significant 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 efficiently structured with three sentences and a parameter section. Each sentence adds value: the core purpose, the clustering concept, and the efficiency benefit. The parameter explanations are brief but clear. No wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values), no annotations, and moderate complexity, the description does well. It covers purpose, usage context, and parameter semantics. However, for a tool with no annotations, it could better address behavioral aspects like authentication, error handling, and performance characteristics to be 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 description coverage is 0%, so the description must compensate. It provides clear semantic meaning for all three parameters: course_id and question_id identify the specific question, and output_format specifies the response structure. The description explains what these parameters do beyond their schema titles, though it doesn't provide format details or examples for the IDs.
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 action ('List all answer groups for a question') and resource ('AI-Assisted Grading'), distinguishing it from siblings like tool_get_answer_group_detail (which likely shows details of one group) or tool_grade_answer_group (which applies grades). It explicitly mentions clustering of similar student answers and the efficiency benefit of grading by group.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: for listing answer groups to enable efficient batch grading. It distinguishes from 1-by-1 grading alternatives and implies usage in AI-assisted grading workflows. The context of 'Grade one group to grade all members at once' clearly indicates its purpose versus individual grading 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It successfully adds important context beyond what's in the schema: it specifies the tool 'Requires instructor/TA access' (permissions requirement), describes what information is returned (student message, rubric details, grader response, links), and indicates parameter sources (from get_regrade_requests). It doesn't mention rate limits, pagination, or error behavior, but provides substantial operational 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 efficiently structured with zero waste: a clear purpose statement, specific information returned, usage guidance with parameter sources, and access requirements. Every sentence adds value, and it's appropriately sized for a tool with 3 parameters and no annotations. The information is front-loaded with the core purpose first.
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 complexity (regrade detail retrieval with 3 parameters), no annotations, but with an output schema present, the description provides substantial context. It covers purpose, returned information, parameter semantics, and access requirements. The output schema existence means the description doesn't need to explain return values. It could potentially mention error cases or rate limits, but covers the essential operational context well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate for the schema's lack of parameter documentation. It successfully adds meaning for all three parameters: course_id is identified as 'The Gradescope course ID', and both question_id and submission_id are specified as coming 'from get_regrade_requests'. This provides crucial context about parameter sources and relationships that isn't in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get detailed information') and resource ('about a specific regrade request'), and distinguishes it from siblings by specifying it's for detailed regrade info rather than listing regrade requests (tool_get_regrade_requests) or other operations. It explicitly lists the specific information returned: student's regrade message, current rubric, applied rubric items, grader's response, and submission page links.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: when you need detailed information about a specific regrade request, and it specifies that question_id and submission_id should come 'from the regrade request listing' (presumably tool_get_regrade_requests). However, it doesn't explicitly state when NOT to use it or name specific alternatives among the 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?
With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: it's a batch operation affecting multiple students, includes a safety warning, and specifies a confirm_write parameter as a safeguard. It doesn't detail permissions, rate limits, or exact effects on grades, but covers essential mutation 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 front-loaded with the core purpose and warning, followed by a structured Args section. Every sentence earns its place: the first states the action, the second warns, and the parameter list is necessary given low schema coverage. 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?
Given a complex mutation tool with 7 parameters, 0% schema coverage, no annotations, but an output schema exists, the description is mostly complete. It covers purpose, caution, and parameter meanings, but could benefit from more on prerequisites or error handling. The output schema reduces need for return value details.
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 lists all 7 parameters with brief explanations (e.g., 'Rubric item IDs to apply,' 'Point adjustment,' 'Grader comment'), adding meaningful semantics beyond the schema's titles. However, it lacks details on formats or constraints for IDs and adjustments.
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 action ('batch-grade ALL submissions'), the target resource ('answer group'), and scope ('at once'). It distinguishes from sibling tools like tool_apply_grade (which likely grades individual submissions) by emphasizing the batch nature and N students scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context with the 'WARNING' about grading N students at once and 'Use with caution,' which implicitly guides when to use this tool versus individual grading alternatives. However, it doesn't explicitly name alternative tools or state when-not-to-use scenarios beyond the caution.
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 of behavioral disclosure. It effectively describes the return format ('table grouped by role with name, email, SID, and submission count') and access requirements ('instructor or TA access'), covering key behavioral aspects. It doesn't mention rate limits or pagination, but provides sufficient context for safe use.
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 efficiently structured with three sentences: purpose, return format, access requirements, and parameter explanation. Each sentence adds essential information without redundancy, making it easy to scan and understand.
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 moderate complexity (single parameter, read-only operation), no annotations, and the presence of an output schema (which handles return value details), the description is complete. It covers purpose, access control, return format, and parameter semantics, leaving no significant gaps for the agent to operate effectively.
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 description coverage is 0%, so the description must compensate. It adds meaning by explaining that 'course_id' is 'The Gradescope course ID', clarifying the parameter's purpose beyond the schema's generic title 'Course Id'. This adequately covers the single parameter's semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get'), resource ('full roster for a course'), and scope ('students, TAs, instructors'), distinguishing it from sibling tools like tool_get_assignment_submissions or tool_get_student_submission that focus on submissions rather than roster data.
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 specifies when to use this tool by stating 'Requires instructor or TA access to the course', providing clear context about prerequisites. However, it doesn't explicitly mention when not to use it or name alternatives among siblings, such as tool_get_assignment_graders which might overlap in some contexts.
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 and does well by disclosing key behavioral traits: it's a mutation operation (implied by 'Modify'), requires specific permissions ('instructor or TA access'), has a safety mechanism ('confirm_write: Must be True'), and explains update behavior ('Only the provided dates will be changed'). It doesn't mention rate limits or error conditions.
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 perfectly structured and front-loaded: the first sentence states the purpose, followed by constraints, permissions, then detailed parameter explanations. Every sentence earns its place with 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 mutation tool with 6 parameters, no annotations, but with an output schema, the description is quite complete. It covers purpose, constraints, permissions, and all parameters thoroughly. The output schema presumably handles return values, so the description doesn't need to explain them. It could mention potential side effects more explicitly.
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 0% description coverage, but the description fully compensates by explaining all 6 parameters in detail: their purpose, format requirements ('ISO format: YYYY-MM-DDTHH:MM'), null behavior ('or None to keep unchanged'), and constraints ('At least one date must be provided'). This adds substantial value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Modify the dates of an assignment') and identifies the exact resources affected ('release, due, late due'), distinguishing it from siblings like 'tool_rename_assignment' or 'tool_set_extension' which handle different aspects of assignments.
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 about when to use it ('Modify the dates of an assignment') and prerequisites ('Requires instructor or TA access'), but doesn't explicitly state when not to use it or name alternative tools for related date operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: the overwrite behavior ('If the student already has an extension, it will be overwritten'), permission requirements ('Requires instructor or TA access'), and the confirmation mechanism ('confirm_write: Must be True to apply the extension update'). It doesn't mention error conditions, rate limits, or what the output contains, but provides substantial operational 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 efficiently structured with purpose first, then behavioral notes, then detailed parameter explanations. Every sentence earns its place: the first states the core function, the next three describe critical behaviors, and the parameter section provides essential context. There's no redundant or verbose content.
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 mutation tool with 7 parameters, 0% schema coverage, no annotations, but with an output schema present, the description is quite complete. It covers purpose, behavior, permissions, parameter semantics, and constraints. The presence of an output schema means return values don't need explanation. Minor gaps include lack of error case descriptions and no explicit distinction from sibling tools like 'tool_modify_assignment_dates'.
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 fully compensates by explaining all 7 parameters. It clarifies the purpose of each parameter, provides format requirements ('ISO format: YYYY-MM-DDTHH:MM'), ordering constraints ('Dates must be in order: release_date <= due_date <= late_due_date'), and special requirements ('At least one date must be provided', 'confirm_write: Must be True'). This adds significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Add or update an extension for a student on an assignment') and identifies the resources involved (student, assignment, extension). It distinguishes itself from sibling tools like 'tool_get_extensions' (which reads extensions) and 'tool_modify_assignment_dates' (which modifies assignment-level dates rather than student-specific extensions).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: when managing student-specific assignment extensions. It mentions prerequisites ('Requires instructor or TA access') and references a related tool ('user_id... found via get_course_roster'). However, it doesn't explicitly state when NOT to use it (e.g., vs. modifying assignment-level dates with 'tool_modify_assignment_dates') or provide alternatives for related operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing important behavioral traits: the destructive nature ('WARNING: Changes the rubric for ALL submissions'), weight semantics based on scoring type, and the confirm_write safety mechanism. It doesn't cover rate limits or authentication needs, but provides substantial operational 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?
Perfectly structured and front-loaded: purpose statement first, critical warning next, weight semantics explanation, then parameter details. Every sentence earns its place with zero waste. The bullet formatting enhances readability without verbosity.
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 mutation tool with no annotations, 5 parameters, and 0% schema coverage, the description is remarkably complete. It covers purpose, behavioral implications, parameter semantics, and critical warnings. The presence of an output schema means return values don't need explanation, making this description fully adequate 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?
Given 0% schema description coverage, the description compensates excellently by explaining all 5 parameters in the Args section. It adds crucial semantic context beyond schema types: course_id and question_id identify resources, description is the rubric content, weight has scoring-type dependencies, and confirm_write serves as a safety flag. This fully addresses the schema coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Create a new rubric item') and resource ('for a question'), distinguishing it from sibling tools like tool_delete_rubric_item and tool_update_rubric_item. It provides precise verb+resource pairing 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?
The description provides clear context about when to use this tool (creating rubric items) and includes a critical warning about scope ('Changes the rubric for ALL submissions'), but doesn't explicitly mention when NOT to use it or name alternatives like tool_update_rubric_item for modifications.
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 of behavioral disclosure. It clearly describes the tool's action (extracts questions, saves to a specific file path), purpose (to avoid re-fetching), and output location (/tmp/gradescope-answerkey-{assignment_id}.md). However, it doesn't mention potential side effects like file overwriting or error conditions.
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 efficiently structured with three sentences: purpose statement, detailed action, and usage timing. Every sentence adds value without redundancy. The parameter documentation is clear and directly relevant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values), no annotations, and only 2 parameters with 0% schema coverage, the description does well by explaining the tool's purpose, behavior, and parameter roles. However, it lacks details on error handling or what happens if the file already exists, which would be helpful for a tool that saves files.
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 adds meaningful context for both parameters: course_id is described as 'The Gradescope course ID' and assignment_id as 'The assignment ID', which clarifies their roles in locating the specific assignment. However, it doesn't provide format examples or validation rules.
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 action ('Prepare a complete answer key'), the resource ('entire assignment'), and the scope ('extracts ALL questions from the outline'). It distinguishes itself from siblings like tool_get_assignment_outline (which likely fetches but doesn't process) and tool_grade_answer_group (which grades specific answers rather than preparing a key).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('Run this ONCE before grading to avoid re-fetching question details') and provides a clear timing guideline. It implies this is a preparatory step distinct from actual grading tools like tool_grade_answer_group, though it doesn't name specific alternatives.
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?
With no annotations provided, the description carries the full burden and excels by disclosing key behavioral traits: it's a mutation tool (implied by 'Update'), includes a critical warning about cascading changes to all submissions, specifies that description/weight can be kept unchanged with None, and requires explicit confirmation via confirm_write. This covers safety, side-effects, and user intent verification.
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 front-loaded with the core purpose and critical warning, followed by a concise parameter breakdown. Every sentence earns its place: the first states the action, the second warns of cascading effects, and the Args section efficiently documents each parameter without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (mutation with cascading effects), no annotations, and an output schema (which handles return values), the description is complete. It covers purpose, critical behavior, all parameters, and usage context, leaving no gaps for the agent to operate safely and effectively.
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 fully. It explains all 6 parameters: course_id, question_id, and rubric_item_id as identifiers, and clarifies that description and weight accept new values or None to keep unchanged, with confirm_write required to apply updates. This adds essential meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Update an existing rubric item's description or weight'), identifies the resource ('rubric item'), and distinguishes from siblings like tool_create_rubric_item and tool_delete_rubric_item by focusing on modification rather than creation or deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (updating rubric items) and includes a critical warning about cascading effects, but it doesn't explicitly mention when not to use it or name specific alternatives among the sibling tools (e.g., tool_create_rubric_item for new items).
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:

[![gradescope-mcp MCP server](https://glama.ai/mcp/servers/Yuanpeng-Li/gradescope-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Yuanpeng-Li/gradescope-mcp)

Score Badge

Copy to your README.md:

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

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