MCPaeroedu

Official

by aerovfx

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v0.5.0
Disambiguation5/5
Each tool targets a distinct function: course creation, content blocks, exams, knowledge graph, DaVinci editing, question bank, and student/report operations. Within each group, tools are clearly differentiated (e.g., block_add_lab vs block_add_pdf). No two tools appear to overlap in purpose.
Naming Consistency2/5
All tools share the 'aeroedu_' prefix, but the structure after that is inconsistent. Some follow module_verb_noun (e.g., aeroedu_block_add_lab), others module_noun_verb (e.g., aeroedu_davinci_clip_import), and some use just verb or noun (e.g., aeroedu_kg_search, aeroedu_report_exam). Within the same module (e.g., kg), patterns vary (extract, node_detail, path_find, record_visit).
Tool Count4/5
24 tools cover a wide array of educational tasks from course management to video editing. While the count is high, each tool serves a distinct purpose within the platform's scope. The number is slightly above typical but still appropriate for a comprehensive educational server.
Completeness3/5
The tool set covers major workflows (course creation, content delivery, exam management, knowledge graph, question bank, video editing), but lacks update and delete operations for courses, chapters, lessons, exams, and questions. This creates gaps in lifecycle management that agents may need to work around.
Average 4.1/5 across 24 of 24 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- Last stable release on May 26, 2026
- 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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate mutation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description confirms attachment but adds no further behavioral details (e.g., permissions, side effects). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each providing useful information. No redundancy or fluff. Efficiently conveys the core purpose and display behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple PDF attachment tool with well-documented parameters and no output schema, the description is largely complete. It could benefit from usage guidelines, but overall adequate given tool complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage for all 5 parameters, so the description adds no additional meaning beyond stating inline display. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Đính kèm tài liệu PDF vào bài học' - attach PDF to lesson) and the resource (lesson). It differentiates from sibling tools which add other block types like lab, quiz, video.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., when to attach a PDF vs a video). The description only mentions inline display but gives no context for selection among 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?
Reveals significant behavioral traits: applies to all clips, automatically switches to Color page, supports specific file formats. Annotations provide idempotent hint but description adds valuable context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four concise sentences, each adding unique information. Front-loaded with main action and scope, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers scope, node application, auto-switch, and file format constraints. Lacks potential caveats like Resolve state requirements, but overall highly complete for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good parameter descriptions. The tool description adds limited parameter-specific value (file formats) but not enough to raise above baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it applies a LUT to all clips in the Resolve timeline, identifies the target node, and mentions automatic workspace switching. It distinguishes this tool from siblings, none of which are color-related.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives or when not to use it. The description lacks explicit usage conditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations show readOnlyHint=false, destructiveHint=false, consistent with creation, but the description adds minimal behavioral context beyond the obvious side effects. It does not disclose potential impacts (e.g., overwriting, permissions, or rate limits) or what happens on success/failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (two sentences) with no filler content. The first sentence states the purpose, and the second provides key details about question types and LaTeX, making it easily scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, nested questions) and lack of output schema, the description covers the main purpose and special features well. However, it omits the return value (e.g., exam ID) and would benefit from briefly explaining how true_false_4 differs from other types.
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 100% description coverage, but the tool description adds value by explaining the four question types in natural language and highlighting LaTeX support, which aids understanding beyond schema definitions.
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 creates exams with question lists, specifies four question types (mcq, true_false_4, short_answer, essay), and mentions LaTeX support. It effectively distinguishes from sibling tools like aeroedu_exam_publish (publishing) and aeroedu_question_create_bulk (creating questions only).
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 creating new exams but lacks explicit guidance on when to use it versus alternatives, such as when to publish an exam or create questions separately. No when-not-to-use or prerequisite information is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide no read/idempotent hints; description adds that it returns lesson_id and explains type-specific fields. However, it does not disclose side effects, permissions, or confirmation that it creates a resource, which is partially inferred.
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?
Description is three sentences long, front-loaded with the core action, and efficiently covers purpose, types, and return value with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, no output schema, description explains the 5 types and their fields, and return value. Fields like order and duration_minutes are only in schema, but still documented. Minor gap: no explanation of behavioral implications like creation confirmation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. Description adds context about which fields correspond to which lesson type, but does not significantly extend beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Thêm' (add) and resource 'bài học vào chương' (lesson to a chapter). It lists 5 specific types with their required fields and indicates return value, distinguishing from sibling tools that add blocks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for adding lessons to chapters but does not explicitly state when not to use or mention alternatives like aeroedu_block_add_* tools. There is no exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations do not indicate destructive or idempotent behavior. The description clarifies it only sets up, not renders, but lacks details on side effects like overwriting existing jobs or required project state. Some transparency but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences, no redundant information. It front-loads the primary action and then lists formats and the follow-up call. Every sentence adds value.
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?
Covers the basic purpose and follow-up but omits important context like whether it modifies existing render jobs, required project state, or if multiple calls create duplicates. Given no output schema and sparse annotations, more completeness is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters. The description adds a brief mention of formats but no additional semantics beyond what the enum and parameter descriptions provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: setting up a render job in Resolve Deliver page. It lists supported formats and distinguishes itself from the sibling 'aeroedu_davinci_render_start' by specifying the follow-up action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance to use 'aeroedu_davinci_render_start' after calling this tool. However, it does not mention prerequisites or alternative tools; the only related sibling is addressed, so it is moderately helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=true, destructiveHint=false, idempotentHint=true) are consistent. The description adds that the AI analyzes the query semantically and returns specific node information, but does not mention rate limits or error handling. Overall, it provides reasonable behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (3-4 sentences) and front-loaded with purpose. It includes examples but could be more structured (e.g., separating purpose, usage, output). Still, it is efficient and clear.
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 schema coverage and annotations, the description explains the return format and typical usage. It does not cover pagination, sorting, or edge cases, but for a search tool with high schema coverage, it 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 coverage is 100%, so each parameter has a description. The description adds example queries but no additional detail per parameter beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs semantic search in AeroEdu's Knowledge Graph using natural language, specifying it returns nodes with descriptions, subject, grade, difficulty, and links. It provides examples and distinguishes itself from sibling tools like node_detail and path_find.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives examples but does not explicitly state when to use this tool versus alternatives (e.g., node_detail for specific nodes, path_find for paths). While siblings provide context, the description lacks direct usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds search scope details (filters, output usability) but no additional behavioral traits beyond what annotations imply. No contradictions; the description aligns with the read-only, non-destructive nature.
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 two sentences in Vietnamese, concise and front-loaded. First sentence states purpose, second lists supported filters and output use. No redundancy or fluff. Could be slightly more structured, but highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 9 optional parameters, no nested objects, and no output schema, the description provides a solid overview of capabilities and downstream integration (exam creation). It doesn't detail pagination behavior beyond schema-defined limit/offset, but that is adequate. Missing explicit return format info, but not critical given schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% – every parameter already has a clear description in the schema (e.g., 'Full-text search', 'Môn học', 'Lớp học'). The tool description merely summarizes these filters without adding significant new semantics. Thus, baseline score of 3.
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 'Tìm kiếm câu hỏi trong Ngân hàng câu hỏi (Question Bank) của AeroEdu' – a specific verb ('search') and resource ('question bank'). It lists multiple search dimensions (subject, grade, topic, etc.), distinguishing it from siblings like 'aeroedu_kg_search' (knowledge graph) and 'aeroedu_exam_create' (which uses the results). 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 explicitly mentions that results can be used directly for 'aeroedu_exam_create questions array', providing clear downstream usage context. While it doesn't state when not to use this tool versus alternatives, the search criteria and purpose are well-defined enough for an agent to decide appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false (mutation) and destructiveHint=false. The description confirms the mutation with 'Add' but does not add additional behavioral details such as required permissions, error cases, or side effects. It provides modest value by describing the lab types, but these are more about input semantics than behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences long, front-loading the core action and then listing lab types. Every sentence contributes meaningfully, with no redundancy. It is extremely concise 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 parameter complexity (7 parameters with nested objects) and no output schema, the description adequately explains the tool's purpose and lab types. However, it does not mention conditional dependencies like embed_url being required only for custom lab_type, nor does it elaborate on the config parameter. The combination of description and detailed schema is largely sufficient, but minor gaps exist.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% coverage with descriptions for all 7 parameters. The tool description reiterates the lab type values (circuit, graph, etc.) but does not significantly enhance understanding of other parameters like lesson_id, config, or embed_url. Therefore, it meets the baseline but does not exceed schema information.
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 'Thêm' (Add) and the resource 'lab challenge thực hành vào bài học', and explicitly lists all five supported lab types (circuit, graph, python, arduino, custom). This specific and detailed purpose distinguishes it clearly from sibling tools such as aeroedu_block_add_pdf or aeroedu_block_add_quiz.
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 the tool adds lab challenges and enumerating the lab types. This helps the agent understand when to use this tool, but it does not explicitly compare with sibling tools or specify when not to use it. However, the context is sufficient for appropriate selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the tool is not read-only, not destructive, and not idempotent. The description adds that scores auto-record to GradeBook, which is useful. However, it does not clarify idempotency (multiple calls may create duplicate blocks) or other side effects like whether it modifies existing blocks. This insufficient explanation beyond annotations results in a score of 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, immediately stating the main action and key details. Every sentence adds value: purpose, prerequisite, and outcome. No wasted words, well front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (5 parameters, full schema coverage, annotations present), the description covers the primary behavior and important context. However, it does not explain return values or detailed behavior for parameters like position or required, leaving minor gaps. No output schema exists, so more explanation would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions. The description adds minimal value beyond the schema, such as noting the source of exam_id and that title is optional. Since the schema already provides detailed explanations, the description does not significantly enhance understanding, warranting the baseline score of 3.
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 'Gắn' (attach) and the resources 'đề thi/quiz' and 'bài học' (lesson). It distinguishes from sibling block add tools (lab, pdf, video) which add different content types. The specific outcome (automatically recording to GradeBook) further clarifies purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to use 'exam_id từ aeroedu_exam_create', implying a prerequisite. It is clear that this tool should be used after creating an exam and a lesson. However, it does not explicitly state when not to use it or list alternatives, so it falls short of 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?
Annotations show it's a write operation (readOnlyHint=false) but provide no other behavioral details. The description adds that it returns chapter_id but does not mention side effects, error conditions, or prerequisites beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-load the purpose and output usage with no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple creation tool, the description covers purpose and output. It lacks error handling details but is sufficient given the tool's simplicity and the absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters. The description does not add additional meaning to the parameters beyond what the schema provides.
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 adds a new chapter to a course, specifies the return value (chapter_id) for use with aeroedu_lesson_add, and differentiates from sibling tools like aeroedu_block_add_* and aeroedu_lesson_add.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says when to use (to add a chapter) and mentions the next step (aeroedu_lesson_add). While it doesn't explicitly state when not to use or list alternatives, the context from siblings makes the usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false, but the description adds context: it creates in draft status and returns courseId. This goes beyond annotations by specifying the initial state and intended use. However, it does not disclose potential side effects or authorization requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences. The first sentence front-loads the action, resource, state, and return value. The second lists subjects. 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 the tool's complexity (6 parameters, no output schema), the description adequately explains the return value and integration with aeroedu_chapter_add. It covers the draft state. However, it could be more complete by mentioning that the course is initially empty or the need for authentication.
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?
All 6 parameters have full schema description coverage (100%), so the schema already provides meaning. The description adds minimal extra parameter info; it only lists subjects which are already in the enum. Thus, baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Tạo' (Create) and the resource 'khoá học mới trên AeroEdu' with the specific state 'draft'. It distinguishes from siblings like aeroedu_course_list (list) and aeroedu_chapter_add (add chapter) by noting the return of courseId for subsequent use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a workflow by stating 'Trả về courseId để dùng cho aeroedu_chapter_add', but does not explicitly specify when to use this tool vs alternatives or provide exclusions. It lacks guidance on prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide basic hints (not read-only, not destructive), and description adds that bin is auto-created. However, it lacks details on duplicate handling, file existence errors, or idempotency, which are not covered by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, no filler, essential information front-loaded. Ideal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers inputs and core behavior (path, bin). Lacks return value or success indication; but given no output schema, description is adequate for a simple import 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 coverage is 100% with good descriptions. The tool description adds value by confirming auto-creation of bin and reinforcing local path requirement, going beyond schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it imports video/audio into DaVinci Resolve Media Pool, specifies absolute local path requirement, and names the target bin. This distinguishes it from sibling tools like color LUT application or rendering.
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?
Implied usage from purpose, but no explicit guidance on when to use or avoid, nor comparison with alternatives. Adding a sentence like 'Use before editing or rendering' would improve.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals that created questions automatically get 'Active' status and are attributed to the teacher, and it specifies the batch size limit of 50. These details go beyond the minimal annotations (all false) and help the agent understand side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact at two sentences, clearly front-loading the main purpose and then adding the use case and behavioral outcomes. Every sentence adds value, 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?
The description covers the essential aspects: purpose, batch limit, and resulting state. However, it does not describe the return value or potential errors. Given no output schema, a minor gap exists, but overall it is 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?
The input schema already provides full descriptions for all parameters (100% coverage). The tool description adds no additional parameter-level documentation beyond reiterating the max 50 constraint. Hence, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the purpose: creating multiple questions into the question bank, with a batch size limit. It is unambiguous and distinguishable from sibling tools by function, though no explicit comparison is made.
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 a specific use case: batch import after Claude generates questions from documents. This gives clear context on when to use the tool, though it does not mention alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate idempotentHint=true, readOnlyHint=false, destructiveHint=false. The description adds that DaVinci Resolve must be running, which is useful, but it does not explain behavioral details like what happens if the project already exists or if creation fails. The description does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loading the main purpose. Every sentence adds value: the first states the action, the second adds a prerequisite and a follow-up tool suggestion. No superfluous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two parameters and no output schema, the description covers the prerequisite (DaVinci Resolve running) and a logical next step (importing clips). Annotations provide additional behavioral hints. The description is complete enough for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters (project_name and create_if_missing) with their meanings and constraints. The tool description does not add any additional parameter semantics beyond what the schema provides. With 100% schema coverage, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool opens or creates a project in DaVinci Resolve, specifying the verb and resource. It distinguishes from sibling tools that handle clips, color, rendering, etc., which are about different aspects of DaVinci Resolve.
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 requires DaVinci Resolve to be running (prerequisite) and suggests using aeroedu_davinci_clip_import after opening a project. While it gives clear context, it does not explicitly state when not to use this tool or provide alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the agent knows this is a safe read operation. The description adds context about where class_id comes from but does not add further behavioral details beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long with no extraneous information. It front-loads the core purpose and immediately provides actionable guidance, making it efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with annotations present and no output schema, the description covers the purpose, input requirements, and returned fields sufficiently. No additional context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all parameters. The description mentions class_id and its source, but this is redundant with the schema description. No additional parameter semantics are provided.
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 'Liệt kê' (list) and the resource 'học sinh trong 1 lớp' (students in a class). It specifies the returned fields and how to obtain the required class_id, distinguishing it from sibling tools that operate on other entities.
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 using class_id from the teacher's class list with a reference URL. It does not explicitly state when not to use the tool, but the context is clear and alternatives are not needed given the sibling tool set focuses on different resources.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations show readOnlyHint=false, destructiveHint=false, idempotentHint=false. The description adds behavioral context: videos appear in order by position, and if position is omitted, it is added at the end. It also lists supported URL formats. This goes beyond annotations, but lacks details on error handling or authorization.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler. The most critical information is front-loaded: action, resource, and supported URL types. Every part is useful.
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 parameter count (5) and no output schema, the description provides sufficient context: what the tool does, supported URL formats, and ordering behavior. It does not explain return values or error cases, but for a creation tool, this is acceptable.
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 100%, so baseline is 3. The description adds value by explaining that the title parameter can be left empty to auto-fetch from URL, and position can be left empty to append to end. This enhances understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (add), resource (video block), and context (to lesson). It specifies support for YouTube, Google Drive, and direct MP4/WebM URLs, and mentions ordering by position. This distinguishes it from sibling block add tools (e.g., pdf, lab).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool should be used when adding a video block to a lesson. However, it does not explicitly state when not to use it or provide alternatives. The context of sibling tools (e.g., aeroedu_block_add_pdf) indirectly guides selection, but no strict guidelines are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate idempotency and non-destructiveness, which the description does not contradict. The description adds behavioral context about scheduling flexibility. Could further explain the effect of the 'status' parameter on student visibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, each serving a clear purpose: state the function and provide usage context. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple publish operation with good annotations and schema, the description is adequate. It covers the main usage steps and links to create tool. Could include brief explanation of status enum 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 coverage is 100% with descriptions for each parameter. The description adds minimal extra beyond the schema, except linking exam_id to aeroedu_exam_create. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool publishes exams so students can see and take them. It distinguishes itself from the sibling 'aeroedu_exam_create' by referencing its exam_id.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to use exam_id from aeroedu_exam_create and explains that after publishing, start/end times can be set for scheduled exams or left blank for free practice. This provides clear usage context, but lacks explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false, indicating no destructive or read-only behavior. The description adds context: it suggests adding to KG, and the auto_add parameter defaults to false with a recommendation to preview first. This provides useful behavioral insight beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a concise three-sentence paragraph. Every sentence provides essential information: purpose, process, and usage context. No redundancy or unnecessary 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?
The description covers purpose and the AI process. It mentions prerequisite relationships and preview recommendation. However, it lacks details on output format and error handling. Still adequate for a complex extraction tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with detailed parameter descriptions. The tool description adds purpose but does not significantly enhance individual parameter understanding. The baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it extracts concepts (nodes) from text/educational documents for the Knowledge Graph. It specifies the AI analysis identifies main concepts and prerequisite relationships, and distinguishes from sibling tools like search or path finding.
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 the tool is used to expand the KG from textbooks, lectures, and textbooks. While it doesn't mention when not to use, the context is clear. No alternative tools are referenced, which would improve clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint; description adds algorithm (BFS) and output structure (ordered nodes + estimated time), enhancing transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words, front-loaded with purpose.
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?
No output schema, but description mentions return values (list + time); covers essential info for a path-finding tool with 3 parameters.
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 has 100% description coverage; the tool description does not significantly add meaning beyond the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it finds optimal learning path from concept A to B in Knowledge Graph using BFS, distinguishing from siblings like aeroedu_kg_search and aeroedu_kg_node_detail.
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?
Implies usage for shortest path between concepts via prerequisites, but no explicit when-not-to-use or alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description aligns with annotations (readOnlyHint=true, destructiveHint=false) and adds useful behavioral details about return fields and status filtering. It does not contradict annotations and provides valuable context beyond structural metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence for purpose and return fields, one sentence for usage tip. No unnecessary words, and critical information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains return fields (id, name, subject, class, status, chapters, students). Three parameters are fully described in schema, and the description covers all essential aspects for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds minimal additional meaning beyond the schema (only a hint about status='all'), but does not compensate significantly. Thus score remains 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists courses for the current teacher on AeroEdu, specifying the exact fields returned (id, name, subject, class, status, chapters, students). This distinguishes it from sibling tools which focus on different resources or operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use the tool (listing current teacher's courses) and a usage tip for status='all' to include draft/archived. While it doesn't explicitly exclude alternatives, the sibling tools are sufficiently different that an agent can infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds useful behavioral context by detailing the returned information (full description, related concepts, learning materials, mastery stats). No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the first covers purpose and what is returned, the second provides usage dependency. No wasted words, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains what the tool returns (full description, related concepts, learning materials, mastery stats). It also notes the optional parameter include_resources. For a detail view tool, this is 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 100%, so parameters are well-documented. The description reinforces the use of node_id from search results and mentions that include_resources controls learning materials listing, but does not add new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is for viewing details of a knowledge graph node, listing specific content (full description, related concepts, learning materials, mastery stats). It also notes to use node_id from aeroedu_kg_search, distinguishing it from sibling tools like aeroedu_kg_search and aeroedu_kg_path_find.
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 says to use node_id from aeroedu_kg_search, providing clear context for when to invoke this tool. It does not include exclusions or mention alternatives, but the context is sufficient for correct selection among 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?
Annotations already indicate read-only, non-destructive, and idempotent behavior. The description adds value by detailing the report contents, offering transparency on what the tool returns beyond the safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two sentences with no redundant information. It front-loads the tool's purpose and efficiently provides essential usage guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description adequately lists the report metrics. It does not cover potential error cases or format details, but given the low complexity, it is sufficiently complete for a single-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes the single parameter 'exam_id', and the description adds meaningful context by specifying that the exam_id should come from specific sibling tools, helping agents understand the parameter's origin.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool generates an exam result analysis report, listing specific metrics such as average score, score distribution, per-question correct/incorrect ratio, Cronbach alpha, and highest/lowest scores. It also clarifies the source of the exam_id, distinguishing it from other exam-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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on obtaining the required exam_id from sibling tools 'aeroedu_exam_create' or 'aeroedu_exam_publish'. While it does not explicitly state when not to use this tool, the context is sufficient given its unique report functionality.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, and the description confirms it updates mastery score, which is consistent. It adds that the tool should be used after a lesson, but no additional side effects are needed. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences in Vietnamese, clear and front-loaded: first sentence states main purpose, second adds detail, third gives usage context. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully explains the tool's purpose, when to use it, and parameter details. With 100% schema coverage and no output schema needed, the description is complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 4 parameters have schema descriptions (100% coverage). The description adds context that mastery_score can be automatically calculated from quiz if omitted, and source defaults to ai_tutor, going beyond 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 verb 'ghi nhận' (record) and the resource 'node trong Knowledge Graph' and updates mastery score. It distinguishes from sibling tools like kg_node_detail (view) and kg_search (search).
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 says 'Dùng sau khi HS hoàn thành bài học liên quan đến khái niệm đó' (Use after the student completes a lesson), providing clear context for when to use. It doesn't specify alternatives but sibling tools are distinct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description details the behavioral difference between wait=true (wait for completion, report result) and wait=false (return immediately, continue in background). This adds significant context beyond the annotations, which only indicate non-read-only and non-destructive.
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?
Three sentences in Vietnamese, front-loaded with the main purpose. No wasted words, and the structure is logical: purpose, wait behavior, prerequisite.
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?
While the description covers the tool's purpose and wait behavior, it lacks explicit mention of return values (only 'báo kết quả' for wait=true). No output schema exists, so a brief note on what the result contains would improve completeness. Still, given the tool's simplicity, it is largely adequate.
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 description adds meaning to the parameters beyond the schema: it explains that wait=true leads to waiting and reporting result, while wait=false returns immediately. This contextualizes the timeout parameter as well. Schema description coverage is 100%, but the description still adds value.
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 starts the render queue in DaVinci Resolve. It distinguishes itself from sibling tool aeroedu_davinci_timeline_export by noting that the latter is a prerequisite.
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 instructs to use aeroedu_davinci_timeline_export first, providing clear usage guidance. It also explains the wait parameter options and their implications.
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:

[![MCPaeroedu MCP server](https://glama.ai/mcp/servers/aerovfx/MCPaeroedu/badges/card.svg)](https://glama.ai/mcp/servers/aerovfx/MCPaeroedu)

Score Badge

Copy to your README.md:

[![MCPaeroedu MCP server](https://glama.ai/mcp/servers/aerovfx/MCPaeroedu/badges/score.svg)](https://glama.ai/mcp/servers/aerovfx/MCPaeroedu)

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/aerovfx/MCPaeroedu'

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