Skip to main content
Glama

学生 MCP 服务器

一个 MCP 服务器实现,提供用于管理学生知识图谱的工具,从而实现课程、作业、考试、概念和学习资源的结构化呈现。该服务器可帮助学生跟踪学业进度、管理截止日期并优化学习旅程。

特征

  • 持久的教育背景:维护跨多个会话的教育实体和关系的结构化知识图

  • 学习课程管理:使用唯一 ID 跟踪学习课程并记录一段时间内的进度

  • 课程管理:以结构化格式组织课程、讲座、作业和考试

  • 概念图:连接学习概念以显示关系和先决条件

  • 任务跟踪:监控任务状态、截止日期和相关资源

  • 考试准备:跟踪考试日期并组织学习材料

  • 截止日期管理:跟踪即将到来的作业和考试的截止日期

  • 资源组织:将学习资源与特定课程和概念联系起来

  • 进度监控:跟踪课程、作业和考试的完成情况

  • 知识联系:可视化不同教育概念之间的关系

Related MCP server: Quantitative Researcher MCP Server

实体

学生 MCP 服务器可识别以下实体类型:

  • 课程:正在修读的学术课程

  • 作业:家庭作业、项目和其他提交的作业

  • 考试:考试、测验和其他评估

  • 概念:知识主题和学习目标

  • 资源:教科书、文章、视频和其他学习材料

  • 笔记:个人学习笔记和观察

  • 讲座:单独授课

  • 项目:大型教育项目或事业

  • 问题:需要研究或审查的具体问题

  • term :学期

  • 目标:学习目标和指标

  • 教授:课程讲师和教师

  • status :实体状态值(活动、已完成、待定、放弃)

  • 优先级:优先级值(高、低)

关系

实体可以通过以下关系类型连接:

  • enrolled_in :学生正在参加课程

  • 已分配:作业是课程的一部分

  • due_on :作业/考试有具体的截止日期

  • 涵盖:讲座/资源涵盖概念

  • 引用:注意引用的概念

  • prerequisite_for :概念是另一个概念的基础

  • teach_by :教授讲授的课程

  • scheduled_for :安排在特定时间的讲座/考试

  • 包含:课程包含讲座/作业

  • 需要:作业需要特定概念

  • related_to :与另一个概念相关的概念

  • created_for :为特定讲座创建的笔记

  • 学习:学习课程重点关注概念/考试

  • helps_with :资源帮助完成任务/概念

  • 已提交:作业提交日期

  • part_of :实体是另一个实体的一部分

  • includes_in :包含在更大的组件中

  • 遵循:实体按顺序跟随另一个实体

  • 出席:学生出席讲座

  • graded_with :根据特定标准评分的作业/考试

  • has_status :将实体链接到其当前状态(活动、已完成、待定、放弃)

  • has_priority :将实体与其优先级(高、低)链接起来

  • 先于:表示一个任务或分配按顺序先于另一个任务或分配

状态和优先级管理

学生 MCP 服务器提供全面的状态和优先级跟踪功能:

  • 状态值:

    • active :目前正在进行或研究

    • 已完成:已完成或已成功提交

    • 待定:尚未开始,但已计划

    • 被遗弃:不再被追寻

  • 优先级值:

    • 高:需要立即关注或对成绩有重大影响

    • 低:可以在高优先级项目完成后处理

  • 顺序学习管理:

    • 定义哪些作业或概念必须先于其他作业或概念完成

    • 按逻辑顺序组织学习活动

    • 在相关学习任务之间创建依赖关系

    • 通过课程材料构建结构化的学习路径

可用工具

学生 MCP 服务器提供了以下与教育知识交互的工具:

开始会话

启动一个新的学习课程,生成唯一的课程 ID,并显示当前课程、即将到来的截止日期、最近学习的概念以及过去的学习课程。通过 has_status 关系显示状态信息,通过 has_priority 关系显示优先级,并根据顺序依赖关系识别下一个准备处理的作业。

加载上下文

加载特定实体(课程、作业等)的详细上下文,并根据实体类型显示相关信息。包括状态信息、优先级以及相关实体之间的顺序关系。

结束会话

通过结构化的多阶段流程记录学习成果:

  1. summary :记录课程摘要、持续时间和课程重点

  2. 学习的概念:记录课程中学习的概念

  3. assignmentUpdates :跟踪作业更新

  4. statusUpdates :记录实体状态值的变化

  5. courseStatus :更新整体课程状态、优先级分配和顺序关系

  6. newConcepts :记录课程中学到的新概念

  7. 组装:所有会话数据的最终组装

构建上下文

在知识图谱中创建新的实体、关系或观察:

  • 实体:添加新的教育实体(课程、作业、概念、状态、优先级等)

  • relations :创建实体之间的关系(包括 has_status、has_priority、precedes)

  • 观察:向现有实体添加观察结果

删除上下文

从知识图谱中删除实体、关系或观察结果:

  • entities :删除教育实体

  • 关系:删除实体之间的关系(包括状态、优先级和顺序关系)

  • 观察:从实体中删除特定观察结果

高级上下文

从知识图谱中检索信息:

  • graph :获取整个知识图谱

  • search :根据查询条件搜索节点

  • nodes :通过名称获取特定节点

  • 课程:获取特定课程的详细信息

  • 截止日期:获取即将到来的截止日期

  • 作业:获取特定作业的详细信息

  • 考试:获取特定考试的详细信息

  • 概念:获取有关概念的信息

  • 讲座:获取有关讲座的信息

  • term :获取有关学期的详细信息

  • status :查找具有特定状态值的实体

  • 优先级:查找具有特定优先级值的实体

  • 序列:确定学习活动的顺序关系

领域特定函数

学生 MCP 服务器包括针对教育领域的专门功能:

  • getCourseOverview :课程的综合视图,包括讲座、作业、考试和资源

  • getUpcomingDeadlines :查找即将到期的作业和考试

  • getAssignmentStatus :获取作业的详细状态,包括进度和相关概念

  • getExamPrep :获取考试准备材料和相关概念

  • findRelatedConcepts :发现不同教育概念之间的联系

  • getStudyProgress :跟踪课程的学习进度

  • getTermOverview :获取学期课程和作业的概述

  • getConceptMastery :评估对特定概念的理解程度

  • getStatusOverview :查看具有特定状态的所有实体(活动、已完成、待定、放弃)

  • getPriorityItems :识别高优先级的作业和学习任务

  • getLearningSequence :根据先行关系可视化学习活动的顺序

示例提示

开始会话

Let's start a new study session for my Computer Science course.

正在加载课程内容

Load the context for my Calculus 101 course so I can see upcoming assignments and exams.

记录学习进度

I've just finished studying for 2 hours on Calculus 101. I focused on limits and derivatives, completed my homework assignment on basic differentiation, and took notes on the chain rule. I've marked the limits content as completed and set the derivatives practice as high priority. I'm feeling more confident about the upcoming exam next week.

管理学习材料

Create a new concept called "Binary Trees" related to my Data Structures course with the description "A binary tree is a tree data structure in which each node has at most two children." Set its status to active and make it precede the "Graph Algorithms" concept.
Update the status of my "Database Assignment" to "completed" and add that I successfully implemented all required queries. Mark the "Advanced SQL" concept as high priority for my next study session.

用法

该 MCP 服务器使学生能够:

  • 保持学习的连续性:跟踪你在多个学习课程中所学到的知识

  • 优化学习时间:专注于高优先级的作业和概念

  • 跟踪学业进展:监控课程、作业的完成情况和概念的掌握情况

  • 准备考试:整理学习材料并跟踪考试准备进度

  • 管理截止日期:掌握即将到来的作业和考试的截止日期

  • 连接知识:查看跨课程不同概念之间的关系

  • 优先处理工作:专注于高优先级的任务和学习任务

  • 结构化学习:创建学习相关概念的逻辑序列

  • 跟踪状态:监控作业、项目和学习活动的状态

配置

与 Claude Desktop 一起使用

将其添加到您的claude_desktop_config.json中:

从 GitHub 安装并使用 npx 运行

{
  "mcpServers": {
    "student": {
      "command": "npx",
      "args": [
        "-y",
        "github:tejpalvirk/student"
      ]
    }
  }
}

全局安装并直接运行

首先,全局安装该包:

npm install -g github:tejpalvirk/student

然后配置Claude桌面:

{
  "mcpServers": {
    "student": {
      "command": "contextmanager-student"
    }
  }
}

码头工人

{
  "mcpServers": {
    "student": {
      "command": "docker",
      "args": [
        "run",
        "--rm",
        "-i",
        "mcp/student"
      ]
    }
  }
}

建筑

来自源

# Clone the repository
git clone https://github.com/tejpalvirk/contextmanager.git
cd contextmanager

# Install dependencies
npm install

# Build the server
npm run build

# Run the server
cd student
node student_index.js

Docker:

docker build -t mcp/student -f student/Dockerfile .

执照

此 MCP 服务器采用 MIT 许可证。这意味着您可以自由使用、修改和分发该软件,但须遵守 MIT 许可证的条款和条件。更多详情,请参阅项目仓库中的 LICENSE 文件。

环境变量

学生 MCP 服务器支持以下环境变量来自定义数据存储位置:

  • MEMORY_FILE_PATH :知识图谱数据的存储路径

    • 可以是绝对路径或相对路径(相对路径使用当前工作目录)

    • 默认值: ./student/memory.json memory.json

  • SESSIONS_FILE_PATH :存储会话数据的路径

    • 可以是绝对路径或相对路径(相对路径使用当前工作目录)

    • 默认值: ./student/sessions.json sessions.json

使用示例:

# Store data in the current directory
MEMORY_FILE_PATH="./student-memory.json" SESSIONS_FILE_PATH="./student-sessions.json" npx github:tejpalvirk/contextmanager-student

# Store data in a specific location (absolute path)
MEMORY_FILE_PATH="/path/to/data/student-memory.json" npx github:tejpalvirk/contextmanager-student

# Store data in user's home directory
MEMORY_FILE_PATH="$HOME/contextmanager/student-memory.json" npx github:tejpalvirk/contextmanager-student

Available Tools

6 tools
advancedcontextA

A comprehensive tool for querying and analyzing your educational knowledge graph. This tool provides specialized operations to extract meaningful insights and contextual information about your academic journey. It enables deep exploration of courses, assignments, exams, concepts, and educational resources.

When to use this tool:

  • Retrieving the complete educational knowledge graph

  • Searching for specific academic entities using keyword matching

  • Fetching details on a precise set of educational entities

  • Getting comprehensive information about a specific course

  • Finding upcoming assignment and exam deadlines

  • Checking detailed status of a specific assignment

  • Preparing for exams with concept retrieval

  • Discovering connections between learning concepts

  • Tracking and reviewing lecture notes

  • Getting an overview of an entire academic term

  • Identifying entities by status (not_started, in_progress, complete)

  • Finding high-priority assignments and tasks

  • Exploring sequential relationships between entities

Key features:

  • Ten specialized query operation types

  • Full educational graph retrieval with entities and relations

  • Keyword-based search across academic entities and their properties

  • Direct entity lookup by exact name

  • Course details including lectures, assignments, exams, and resources

  • Deadline tracking with time-based filtering

  • Assignment status with progress tracking through has_status relations

  • Priority information via has_priority relations

  • Exam preparation with related concepts and materials

  • Concept relationship mapping

  • Sequential entity relationships via follows relations

  • Lecture note organization

  • Term-based academic overview

  • JSON-formatted response with query results

Parameters explained:

  • type: The query operation type to perform, which must be one of:

    • "graph" - Retrieve the entire educational knowledge graph

    • "search" - Find academic entities by keyword/partial match

    • "nodes" - Get specific educational entities by exact name

    • "course" - Get comprehensive details about a specific course

    • "deadlines" - Get upcoming assignment and exam deadlines

    • "assignment" - Get detailed status of a specific assignment

    • "exam" - Get preparation materials for a specific exam

    • "concepts" - Find related concepts based on a starting concept

    • "lecture" - Track and organize notes for lectures

    • "term" - Get overview of an academic term

  • params: Operation-specific parameters structure:

    • For "graph": No parameters needed

    • For "search": { query: "search text" }

    • For "nodes": { names: ["EntityName1", "EntityName2", ...] }

    • For "course": { courseName: "Course Name" }

    • For "deadlines": { termName: "Term Name", courseName: "Course Name", daysAhead: 14 }

    • For "assignment": { assignmentName: "Assignment Name" }

    • For "exam": { examName: "Exam Name" }

    • For "concepts": { conceptName: "Concept Name", depth: 1 }

    • For "lecture": { courseName: "Course Name" }

    • For "term": { termName: "Term Name" }

Operation details:

  • "graph" returns the complete educational knowledge graph structure

  • "search" performs partial matching on entity names, types, and observations

  • "nodes" retrieves specific entities by exact name matching

  • "course" provides a comprehensive view of a course with its components

  • "deadlines" finds upcoming assignments and exams with due dates

  • "assignment" shows detailed status and related concepts for an assignment

  • "exam" provides study resources and related concepts for exam preparation

  • "concepts" maps relationships between different learning concepts

  • "lecture" organizes and retrieves notes for course lectures

  • "term" gives an overview of courses and work for an academic term

Status information:

  • All entities include status information (not_started, in_progress, complete) via has_status relations

  • Status can be used in search queries (e.g., "status:complete")

  • Course views show assignment completion status

  • Term views highlight course completion percentages based on status

Priority information:

  • Entities can have priority values (low, high) via has_priority relations

  • Priority can be used in search queries (e.g., "priority:high")

  • High-priority items are highlighted in course and term views

Sequential relationships:

  • Entities can have sequence relationships through follows relations

  • Course views show recommended sequence of assignments and lectures

  • Concept views show prerequisite relationships

Return structures:

  • All operations return { success: true/false, ... } with operation-specific data

  • Error responses include detailed error messages

  • Complex operations return rich, structured data about academic entities

  • Educational relationships are preserved in all returned data

  • Status and priority information is included in relevant entity data

You should:

  1. Select the most appropriate query type for your educational information need

  2. Provide the required parameters for your chosen operation type

  3. Start with broader queries and refine to more specific ones

  4. Use "search" for exploratory investigation of your academic knowledge

  5. Use "course" to get a comprehensive view of your coursework

  6. Use "deadlines" to stay on top of upcoming academic work

  7. Use "concepts" to understand relationships between learning topics

  8. Filter search results by status to focus on incomplete work

  9. Prioritize assignments based on priority values

  10. Follow sequential relationships to create effective study plans

  11. Combine query results to build comprehensive study strategies

ParametersJSON Schema
NameRequiredDescriptionDefault
paramsYesParameters for the operation, structure varies by type
typeYesType of get operation: 'graph', 'search', 'nodes', 'course', 'deadlines', 'assignment', 'exam', 'concepts', 'lecture', or 'term'

TDQS

A4.6/5.0
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 detailing return structures ('All operations return { success: true/false, ... }'), error handling ('Error responses include detailed error messages'), data relationships ('Educational relationships are preserved'), and specific behaviors like status/priority filtering capabilities. It doesn't mention rate limits or authentication requirements, keeping it from a perfect score.

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

Conciseness3/5

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

While well-structured with clear sections, the description is excessively long (over 700 words) with repetitive information. The 'Operation details' section largely repeats what's already in 'Parameters explained,' and the 'You should' section could be more concise. Every sentence doesn't earn its place given the redundancy.

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

Completeness5/5

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

For a complex tool with 10 operation types, no annotations, and no output schema, the description provides comprehensive context. It covers purpose, usage scenarios, parameter semantics, behavioral details, return structures, and practical guidance. The agent has everything needed to select and invoke this tool correctly despite the missing structured metadata.

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?

Despite 100% schema description coverage, the description adds substantial value with a detailed 'Parameters explained' section that clarifies each operation type's purpose and provides concrete examples of the params structure for every type. This transforms the schema's generic 'object' parameter into actionable guidance for the agent.

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

Purpose5/5

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

The description clearly states the tool's purpose as 'querying and analyzing your educational knowledge graph' with 'specialized operations to extract meaningful insights and contextual information about your academic journey.' It distinguishes from siblings like 'buildcontext' and 'deletecontext' by focusing on query/analysis rather than creation or deletion operations.

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 with a 'When to use this tool' section listing 13 specific scenarios, plus a numbered 'You should' section with 11 actionable recommendations. It distinguishes when to use specific operation types (e.g., 'Use "search" for exploratory investigation' vs 'Use "course" to get a comprehensive view').

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

buildcontextA

A flexible tool for constructing and enhancing your educational knowledge graph. This tool allows you to add new academic entities, create relationships between educational components, or add observations to existing study materials. Each operation type serves a specific purpose in building a comprehensive representation of your academic journey.

When to use this tool:

  • Creating new educational entities like courses, assignments, and exams

  • Establishing relationships between academic entities (e.g., assignment is part of a course)

  • Documenting observations about your academic materials

  • Building a connected graph of your educational experience

  • Organizing your study resources and materials

  • Tracking relationships between concepts and learning materials

  • Recording course-specific details like schedules and due dates

  • Creating structured representations of your academic knowledge

  • Setting status values for educational entities

  • Assigning priority to assignments and tasks

Key features:

  • Three distinct operation types (entities, relations, observations)

  • Type validation against academic domain standards

  • Automatic rejection of invalid entity or relation types

  • Safe addition of new observations to existing academic entities

  • Status and priority assignment through entity-relation model

  • JSON-formatted response with operation results

  • Clear error messages when operations fail

  • Handles both single and batch operations

Parameters explained:

  • type: The operation type to perform, which must be one of:

    • "entities" - Create new academic entities

    • "relations" - Create relationships between existing entities

    • "observations" - Add observations to existing entities

  • data: Operation-specific data structure:

    • For "entities": Array of objects with { name, entityType, observations[] }

    • For "relations": Array of objects with { from, to, relationType }

    • For "observations": Array of objects with { entityName, contents[] }

Entity Types:

  • course - Academic courses you're taking

  • assignment - Homework, projects, and other submitted work

  • exam - Tests, quizzes, and other assessments

  • concept - Knowledge topics and learning objectives

  • resource - Textbooks, articles, videos, and other learning materials

  • note - Personal study notes and observations

  • lecture - Individual class sessions

  • project - Larger educational projects

  • question - Specific questions for study or review

  • term - Academic terms or semesters

  • goal - Learning objectives and targets

  • professor - Course instructors and teachers

  • status - Entity status (not_started, in_progress, complete)

  • priority - Entity priority (low, high)

Relation Types include:

  • enrolled_in - Student is taking a course

  • assigned_in - Assignment is part of a course

  • due_on - Assignment/exam has specific due date

  • covers - Lecture/resource covers concept

  • references - Note references concept

  • prerequisite_for - Concept is foundation for another

  • taught_by - Course taught by professor

  • scheduled_for - Lecture/exam scheduled for specific time

  • contains - Course contains lectures/assignments

  • has_status - Links entity to its status (not_started, in_progress, complete)

  • has_priority - Links entity to its priority (low, high)

  • follows - Entity follows another in a sequence

Status Values:

  • not_started - Work on the entity has not begun

  • in_progress - Work is actively underway

  • complete - Work has been finished

Priority Values:

  • low - Lower priority item

  • high - Higher priority item

You should:

  1. Specify the operation type based on what you need to create (entities, relations, or observations)

  2. Structure your data according to the operation type's requirements

  3. Use valid entity types and relation types from the academic domain

  4. Ensure entities exist before creating relations between them

  5. Provide meaningful names and descriptions for new entities

  6. Use observations to add general metadata about entities

  7. Use has_status relations to track progress (not_started, in_progress, complete)

  8. Use has_priority relations to indicate importance (low, high)

  9. Use follows relations to establish sequences between related entities

  10. Create complete structures rather than adding entities/relations piecemeal

  11. Check the operation result to confirm successful creation

ParametersJSON Schema
NameRequiredDescriptionDefault
dataYesData for the creation operation, structure varies by type but must be an array
typeYesType of creation operation: 'entities', 'relations', or 'observations'

TDQS

A4.6/5.0
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 does an excellent job describing behavioral traits: it explains the three operation types, mentions type validation and automatic rejection of invalid types, describes safe addition of observations, notes JSON-formatted responses and clear error messages, and specifies that it handles both single and batch operations. The only minor gap is not explicitly stating whether this is a read-only or mutation operation, though 'constructing and enhancing' implies mutation.

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

Conciseness3/5

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

The description is comprehensive but overly long at approximately 650 words. While well-structured with clear sections (purpose, when to use, key features, parameters explained, etc.), it includes some redundant information and could be more front-loaded. The 'You should' list contains 11 items where 5-6 might suffice, and some content (like the full lists of entity/relation types) might belong in documentation rather than the tool description.

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 (multiple operation types, extensive domain-specific constraints) and the absence of both annotations and an output schema, the description provides exceptional completeness. It covers purpose, usage scenarios, behavioral characteristics, parameter details with examples, domain-specific constraints (valid types), and practical implementation guidelines. An agent would have everything needed to use this tool correctly.

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

Parameters5/5

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

Despite 100% schema description coverage, the description adds substantial value beyond the schema. It provides detailed explanations of what each 'type' value means (entities, relations, observations), specifies the exact data structure required for each type with examples, and enumerates all valid entity types, relation types, status values, and priority values. This transforms abstract parameters into concrete, actionable guidance.

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: 'constructing and enhancing your educational knowledge graph' with three specific operation types (entities, relations, observations). It distinguishes this from siblings like 'deletecontext' and 'loadcontext' by emphasizing creation and enhancement rather than deletion or loading.

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 an explicit 'When to use this tool' section with 11 specific scenarios, plus a numbered list of 11 guidelines for effective use. It clearly differentiates when to use each operation type and provides practical advice like 'Ensure entities exist before creating relations between them' and 'Create complete structures rather than adding entities/relations piecemeal.'

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

deletecontextA

A precise tool for removing elements from your educational knowledge graph. This tool enables targeted deletion of academic entities, relationships between educational components, or specific observations about study materials. It helps maintain an accurate and current representation of your academic landscape as your learning journey evolves.

When to use this tool:

  • Removing completed or dropped courses

  • Deleting obsolete relationships between academic entities

  • Pruning outdated notes or observations that are no longer relevant

  • Correcting errors in your academic knowledge graph

  • Cleaning up test or practice entities

  • Maintaining graph accuracy as your educational focus changes

  • Removing duplicate learning materials or resources

  • Archiving completed assignments or exams

  • Updating status or priority relations when they change

  • Modifying entity sequences

Key features:

  • Three distinct deletion operation types (entities, relations, observations)

  • Cascading deletion for entities (automatically removes related relations)

  • Precise deletion of specific observations without removing entire entities

  • Targeted relation removal with exact matching on from/to/type

  • Batch operations for efficient cleanup

  • JSON-formatted response with operation results

  • Secure validation before deletion

  • Clear error messages when operations fail

Parameters explained:

  • type: The deletion operation type to perform, which must be one of:

    • "entities" - Remove academic entities and their relations

    • "relations" - Remove specific relationships between entities

    • "observations" - Remove specific observations from entities

  • data: Operation-specific data structure:

    • For "entities": Array of entity names to delete

    • For "relations": Array of objects with { from, to, relationType }

    • For "observations": Array of objects with { entityName, observations[] }

Deletion behavior by type:

  • "entities": Completely removes the specified entities and any relations where they appear

  • "relations": Removes only the exact relations specified, matching on all three attributes

  • "observations": Removes specific observations from entities while preserving the entities themselves

Status and Priority Management:

  • To change an entity's status, delete the old has_status relation and create a new one

  • To change priority, delete the old has_priority relation and create a new one

  • Status values (not_started, in_progress, complete) are managed through relations, not direct properties

  • Priority values (low, high) are managed through relations, not direct properties

Safety considerations:

  • Entity deletion cascades to relations, so be careful when deleting key entities

  • There is no "undo" operation, so confirm deletions carefully

  • Partial graph information can lead to inconsistent views of your academic knowledge

  • Relations require entities on both ends to exist

  • Deleting status or priority relations without replacing them can lead to inconsistent state

  • Consider creating new status/priority relations before deleting old ones

You should:

  1. Identify the specific elements in your academic graph that need to be removed

  2. Choose the appropriate deletion type (entities, relations, or observations)

  3. Structure your data according to the deletion type's requirements

  4. Start with more specific deletions (observations) before broader ones

  5. Verify the entities or relations exist before attempting deletion

  6. When updating status, create a new has_status relation before deleting the old one

  7. When updating priority, create a new has_priority relation before deleting the old one

  8. Consider the impact on entity sequences when deleting follows relations

  9. Check the operation result to confirm successful deletion

  10. Consider documenting major deletions as observations on related entities

  11. When removing an entire course, first delete its components for cleaner removal

ParametersJSON Schema
NameRequiredDescriptionDefault
dataYesData for the deletion operation, structure varies by type but must be an array
typeYesType of deletion operation: 'entities', 'relations', or 'observations'

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations provided, the description carries full burden and delivers comprehensive behavioral disclosure. It details three deletion types with specific behaviors (cascading deletion for entities, exact matching for relations), safety considerations (no undo, cascading effects), and status/priority management workflows. It explains JSON-formatted responses, batch operations, and validation processes.

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 well-structured with clear sections (purpose, usage guidelines, features, parameters, behavior, management, safety, procedures) but is quite lengthy. While every section adds value, some redundancy exists (e.g., status/priority management appears in multiple sections), preventing a perfect score for conciseness.

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 destructive tool with no annotations and no output schema, the description provides exceptional completeness. It covers purpose, usage scenarios, parameter semantics, behavioral details, safety considerations, procedural workflows, and edge cases. The absence of output schema is compensated by mentioning 'JSON-formatted response with operation results' and 'Check the operation result' guidance.

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?

Despite 100% schema description coverage, the description adds significant value beyond the schema. It provides detailed 'Parameters explained' and 'Deletion behavior by type' sections that clarify what each parameter means in practice, including specific data structures for each operation type and behavioral differences between entity/relation/observation deletions.

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: 'removing elements from your educational knowledge graph' with specific deletion operations (entities, relationships, observations). It distinguishes from siblings like 'buildcontext' (creation) and 'loadcontext' (retrieval) by focusing exclusively on deletion operations.

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 'When to use this tool' section with 10 specific scenarios (e.g., 'Removing completed or dropped courses', 'Deleting obsolete relationships'), plus a numbered 'You should' section with 11 procedural guidelines. It clearly differentiates when to use this deletion tool versus creation/retrieval siblings.

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

endsessionA

A multi-stage tool for documenting study sessions, tracking academic progress, recording concepts learned, updating assignment status, and enriching the student knowledge graph.

When to use this tool: Only use this tool when the user explicity requests it or provides explicit approval.

Key features:

  • Provides a structured, multi-stage workflow for session documentation

  • Records concepts learned in the knowledge graph

  • Updates assignment status using has_status relations (not_started, in_progress, complete)

  • Updates assignment priorities using has_priority relations (low, high)

  • Establishes sequential relationships between concepts using follows relations

  • Creates connections between concepts and courses

  • Updates course status metadata

  • Creates new concept entities for topics you've studied

  • Maintains session continuity with unique session IDs

  • Supports revision of previous stages when needed

  • Offers a comprehensive assembly stage that consolidates all session information

  • Organizes your academic knowledge into a coherent structure

The endsession tool uses a sequential, multi-stage approach with 6 typical stages:

  1. Summary Stage: Records basic session information

  2. Concepts Learned Stage: Documents specific concepts studied

  3. Assignment Updates Stage: Records status and priority changes to assignments

  4. New Concepts Stage: Defines new concept entities to add

  5. Course Status Stage: Updates the overall course status

  6. Assembly Stage: Consolidates all information and finalizes the session record

Parameters explained:

  1. sessionId: Required - Unique identifier for the study session

  • Obtained from the startsession tool

  • Example: "stu_1234567890_abc123"

  1. stage: Required - Current stage of the endsession workflow

  • Accepts: "summary", "conceptsLearned", "assignmentUpdates", "newConcepts", "courseStatus", or "assembly"

  • Each stage has specific data requirements and processing logic

  1. stageNumber: Required - The sequence number of the current stage

  • Starts at 1 and typically progresses through 6 stages

  • Used to track progress through the session documentation workflow

  1. totalStages: Required - Total number of stages planned for this workflow

  • Typically 6 for the complete workflow

  • Provides context for the progress within the overall process

  1. analysis: Optional - Text analysis or observations for the current stage

  • Descriptive text explaining the work done in this stage

  • Example: "Analyzed progress on studying for the final exam"

  1. stageData: Optional - Stage-specific structured data

  • Structure varies by stage type:

    • summary: { summary: "Session summary text", duration: "2 hours", course: "CourseName" }

    • conceptsLearned: { concepts: ["Concept A", "Concept B", "Concept C"] }

    • assignmentUpdates: { updates: [{ name: "Assignment1", status: "complete", priority: "high" }, { name: "Assignment2", status: "in_progress" }] }

    • newConcepts: { concepts: [{ name: "NewConcept1", description: "Definition of the concept", follows: "PriorConcept" }] }

    • courseStatus: { courseStatus: "in_progress", courseObservation: "Making good progress" }

    • assembly: No stageData needed - automatically assembled from previous stages

  1. nextStageNeeded: Required - Whether additional stages are needed after this one

  • Boolean value (true/false)

  • Set to false on the final stage to complete the session

  1. isRevision: Optional - Whether this is revising a previous stage

  • Boolean value (true/false)

  • Default: false

  1. revisesStage: Optional - If revising, which stage number is being revised

  • Required when isRevision is true

  • Indicates which previous stage is being updated

When the endsession workflow completes (assembly stage with nextStageNeeded: false), the tool performs these updates:

  1. Concept Entities: Creates entities for each concept learned and links them to the course

  2. Assignment Status Updates: Updates assignment status via has_status relations (not_started, in_progress, complete)

  3. Assignment Priority Updates: Updates assignment priority via has_priority relations (low, high)

  4. Sequential Concept Relationships: Establishes follows relations between concepts when specified

  5. Course Status Update: Updates the course status via has_status relation, adds an updated timestamp, and records observations

  6. New Concept Creation: Creates new concept entities, links them to the course, and establishes any sequential relationships

  7. Session Recording: Marks the session as completed in persistent storage

Return information:

  • JSON response with the following structure:

    • success: Boolean indicating whether the operation succeeded

    • stageCompleted: The stage that was just completed

    • nextStageNeeded: Whether more stages are required

    • stageResult: The processed result of the current stage

    • endSessionArgs: (Only in assembly stage) Consolidated arguments for the session

    • sessionRecorded: (Final stage only) Whether the session was recorded

    • summaryMessage: (Final stage only) Formatted summary of all recorded information

    • error: (Only on failure) Error message describing the issue

  • Error information when operation fails

Status and Priority Values:

  • Valid status values: not_started, in_progress, complete

  • Valid priority values: low, high

You should:

  • Complete all stages in order for comprehensive session documentation

  • Provide specific details in each stage for accurate knowledge graph updates

  • Be precise about assignment names to ensure they match existing assignments

  • Use valid status values (not_started, in_progress, complete) when updating assignments

  • Use valid priority values (low, high) when specifying assignment importance

  • Specify sequential relationships between concepts when appropriate

  • Use clear, descriptive names for any new concepts

  • Include relevant observations for course status updates

  • If making a revision, specify which stage is being revised

  • Only mark nextStageNeeded as false on the final assembly stage

  • Review the final summary message to confirm all session details were recorded properly

  • Use the unique session ID consistently across all stages

ParametersJSON Schema
NameRequiredDescriptionDefault
analysisNoText analysis or observations for the current stage
isRevisionNoWhether this is revising a previous stage
nextStageNeededYesWhether additional stages are needed after this one (false for final stage)
revisesStageNoIf revising, which stage number is being revised
sessionIdYesThe unique session identifier obtained from startsession
stageYesCurrent stage of analysis: 'summary', 'conceptsLearned', 'assignmentProgress', 'questions', 'nextSteps', or 'assembly'
stageDataNoStage-specific data structure - format depends on the stage type: - For 'summary' stage: { summary: "Session summary text", duration: "2 hours", focus: "CourseName" } - For 'conceptsLearned' stage: { concepts: ["Concept A", "Concept B", "Concept C"] } - For 'assignmentProgress' stage: { assignments: [{ name: "Assignment1", status: "completed" }, { name: "Assignment2", status: "in_progress" }] } - For 'questions' stage: { questions: ["Question about topic X", "Question about concept Y"] } - For 'nextSteps' stage: { nextSteps: ["Review chapter 7", "Complete practice problems", "Attend office hours"] } - For 'assembly' stage: no stageData needed - automatic assembly of previous stages
stageNumberYesThe sequence number of the current stage (starts at 1)
totalStagesYesTotal number of stages in the workflow (typically 5 for standard workflow)

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations provided, the description carries full burden and delivers comprehensive behavioral disclosure. It details the 6-stage sequential workflow, revision capabilities, final consolidation process, specific updates performed (concept entities, assignment status/priority, course status), persistence behavior ('marks the session as completed in persistent storage'), and return structure including error handling.

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

Conciseness3/5

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

The description is comprehensive but overly verbose (700+ words). While well-structured with clear sections (purpose, when-to-use, features, stages, parameters, updates, returns, guidelines), it contains repetitive information and could be more efficiently organized. Every sentence adds value, but the overall length exceeds what's needed for clarity.

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 complex 9-parameter tool with no annotations and no output schema, the description provides exceptional completeness. It covers purpose, usage, workflow, parameters with examples, behavioral details, return structure, error handling, and implementation guidelines. The only minor gap is not explicitly mentioning authentication or rate limits, but given the academic context, this is reasonable.

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?

Despite 100% schema description coverage, the description adds substantial value beyond the schema. It provides concrete examples for all parameters (e.g., sessionId format, stageData structures for each stage type), explains parameter relationships (isRevision requires revisesStage), clarifies typical values (totalStages 'typically 6'), and contextualizes parameters within the multi-stage workflow.

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's purpose as 'documenting study sessions, tracking academic progress, recording concepts learned, updating assignment status, and enriching the student knowledge graph' with a multi-stage workflow. It clearly distinguishes from sibling tools like 'startsession' by focusing on session completion rather than initiation, and from context management tools by its academic documentation focus.

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 usage instructions: 'Only use this tool when the user explicitly requests it or provides explicit approval.' It also implicitly distinguishes from siblings by its specialized academic documentation purpose versus general context management tools, and mentions session continuity with 'startsession' for obtaining sessionId.

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

loadcontextA

A powerful tool for retrieving comprehensive, structured information about specific educational entities, providing context-rich details tailored to academic needs.

When to use this tool:

  • Retrieving detailed information about courses, assignments, exams, and academic concepts

  • Exploring course materials, lecture schedules, and assignment deadlines

  • Preparing for upcoming exams by identifying key concepts and resources

  • Tracking assignment status and due dates

  • Understanding relationships between academic concepts

  • Examining course structures and learning resources

  • Planning study sessions around specific courses or topics

  • Reviewing term schedules and upcoming deadlines

  • Organizing academic resources by courses and concepts

  • Establishing context for effective learning and study planning

  • Viewing entity status information (not_started, in_progress, complete)

  • Checking priority levels for assignments and tasks

  • Understanding sequential relationships between academic entities

Key features:

  • Provides richly formatted, context-aware information about educational entities

  • Adapts output format based on entity type (course, assignment, exam, concept, term)

  • Presents both direct entity information and related academic elements

  • Shows time-sensitive information like due dates and exam schedules

  • Tracks loaded entities within the current session for continuity

  • Formats information in a clean, readable markdown structure

  • Automatically identifies relationships between academic entities

  • Displays status information via has_status relations

  • Shows priority levels via has_priority relations

  • Presents sequential relationships through follows relations

  • Highlights status of assignments and upcoming deadlines

  • Shows progress metrics for courses and assignment completion

Parameters explained:

  1. entityName: Required - The name of the entity to retrieve context for

  • Example: "Introduction to Computer Science", "Midterm Paper", "Binary Trees"

  1. entityType: Optional - The type of entity being retrieved

  • Default: "course"

  • Accepts values from valid entity types for the student domain

  • Helps the system format the output appropriately

  1. sessionId: Optional - The current session identifier

  • Typically provided by startsession

  • Used for tracking entity views within the session

Each entity type returns specialized context information:

  • Course: Shows code, status (via has_status), schedule, location, description, professor information, lectures, assignments (with status and priority), exams, key concepts, and resources

  • Assignment: Displays course, status (not_started, in_progress, complete), priority (low, high), due date, points, time remaining, instructions, related concepts, helpful resources, and your notes

  • Exam: Shows course, date, time remaining, location, format, duration, concepts to study, key lectures, and study resources

  • Concept: Displays difficulty level, description, related concepts (including sequential relationships), courses covering this concept, and learning resources

  • Term: Shows start date, end date, status, courses for the term (with completion percentages), and upcoming deadlines

  • Other Entity Types: Shows observations and both incoming and outgoing relationships within the knowledge graph

Status and Priority:

  • All entities include status values (not_started, in_progress, complete) retrieved via has_status relations

  • Relevant entities include priority values (low, high) retrieved via has_priority relations

  • Status information is used to calculate completion percentages and filter assignments

  • Priority information helps identify important tasks and assignments

Sequential Relationships:

  • Related entities may have follows relationships indicating recommended sequence

  • Course view shows sequenced lectures and assignments

  • Concept view shows prerequisite relationships between concepts

Return information:

  • Formatted markdown text with hierarchical structure

  • Sections adapted to the specific entity type

  • Related entities shown with their status, priority, and descriptions

  • Error messages if the entity doesn't exist or can't be retrieved

You should:

  • Specify the exact entity name for accurate retrieval

  • Provide the entity type when possible for optimally formatted results

  • Start with course entities to get a high-level overview of academic materials

  • Use assignment context to track deadlines and submission status

  • Prepare for exams by examining exam context for study resources

  • Explore concept context to understand relationships between academic topics

  • Review term context to plan your academic schedule

  • Pay attention to status values to identify incomplete assignments

  • Consider priority information when planning your study schedule

  • Follow sequential relationships to create effective learning paths

  • After retrieving context, follow up on specific entities of interest

  • Use in conjunction with startsession to maintain session tracking

  • Combine with endsession to document your learning progress

  • Remember that this tool only retrieves existing information; use buildcontext to add new entities

ParametersJSON Schema
NameRequiredDescriptionDefault
entityNameYes
entityTypeNoType of entity to load, defaults to 'course'
sessionIdNoSession ID from startsession to track context loading

TDQS

A4.5/5.0
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 thoroughly explains the tool's behavior, including output formatting (markdown), session tracking, entity type adaptations, and relationships like status and priority. However, it lacks details on error handling or rate limits, which are minor gaps.

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

Conciseness2/5

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

The description is excessively long and repetitive, with sections like 'Key features' and 'You should' that reiterate points already covered. While structured, it includes unnecessary details (e.g., listing all entity type outputs) that could be condensed, reducing efficiency for the agent.

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 (3 parameters, no annotations, no output schema), the description is highly complete. It covers purpose, usage, parameters, behavior, output format, and relationships with sibling tools, providing all necessary context for effective agent use without relying on structured fields.

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 includes a detailed 'Parameters explained' section that adds significant meaning beyond the input schema. It explains each parameter's purpose, provides examples, and clarifies defaults and usage, compensating for the 67% schema description coverage and enriching the agent's understanding.

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

Purpose5/5

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

The description clearly states the tool's purpose as 'retrieving comprehensive, structured information about specific educational entities' with 'context-rich details tailored to academic needs.' It distinguishes itself from sibling tools like buildcontext (for adding new entities) and deletecontext, making its retrieval-only function explicit.

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 includes an explicit 'When to use this tool' section with 13 specific scenarios, such as retrieving course details or tracking assignments. It also provides guidance on when not to use it (e.g., 'use buildcontext to add new entities') and mentions alternatives like startsession for session tracking, ensuring clear differentiation from siblings.

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

startsessionA

A powerful tool for initializing a new academic study session. This tool starts a new study session and provides a comprehensive overview of your current educational landscape. It retrieves recent study sessions, active courses, upcoming deadlines, and recently studied concepts to help focus your learning effectively.

When to use this tool:

  • Beginning a new study session or learning period

  • Getting oriented in your current academic state

  • Planning which courses or assignments to focus on

  • Reviewing recent study activity and progress

  • Checking upcoming deadlines for assignments and exams

  • Deciding which concepts need attention

  • Establishing context before diving into specific study work

  • Creating a structured record of your study activity

  • Identifying high-priority assignments that need attention

  • Tracking progress through status information

Key features:

  • Generates a unique study session identifier for tracking activity

  • Retrieves and displays your most recent study sessions

  • Shows active courses (based on has_status relations)

  • Highlights high-priority assignments (based on has_priority relations)

  • Identifies assignment status (not_started, in_progress, complete)

  • Highlights upcoming assignment and exam deadlines

  • Lists recently studied concepts for review

  • Formats information in a structured, easy-to-read format

  • Provides seamless integration with loadcontext tool

  • Stores study session data for historical record keeping

Parameters explained:

  • No parameters required - the tool automatically retrieves all relevant context

Return information:

  • Session ID: A unique identifier for this study session (format: stud_timestamp_randomstring)

  • Recent Study Sessions: Up to 3 most recent sessions with:

    • Date

    • Course focus

    • Study session summary (truncated for readability)

  • Active Courses: List of courses with active status (via has_status relation), including:

    • Course name

    • Course code or description

    • Status via has_status relation

    • Priority if assigned via has_priority relation

  • High-Priority Assignments: Assignments with high priority status (via has_priority relation), including:

    • Assignment name

    • Current status (not_started, in_progress, complete)

    • Course it belongs to

    • Due date if available

  • Upcoming Deadlines: Assignment and exam deadlines in the next 14 days, including:

    • Assignment/exam name

    • Course it belongs to

    • Due date

    • Days remaining until due

    • Status (not_started, in_progress, complete)

  • Recently Studied Concepts: List of concepts you've recently studied

Session workflow:

  1. Starting a session creates a session identifier in the student domain

  2. This session can be referenced when loading course context with loadcontext

  3. Session activities are tracked for later recording

  4. Sessions should be ended with endsession to record learning progress

  5. Session history becomes available for future startsession calls

Status and Priority:

  • Course status is retrieved through has_status relations (not_started, in_progress, complete)

  • Assignment priority is retrieved through has_priority relations (low, high)

  • This information helps you prioritize your study activities

You should:

  1. Begin each focused study period with startsession

  2. Review the provided context to determine your study focus

  3. Prioritize high-priority assignments with upcoming deadlines

  4. Focus on incomplete assignments (not_started or in_progress status)

  5. Choose a specific course, assignment, or concept to work on

  6. Use the generated session ID with the loadcontext tool to load specific entities

  7. Complete your study work on your selected focus area

  8. End the session with endsession when work is complete

  9. Record concepts learned, assignment status updates, and study accomplishments

  10. Use the session history to maintain continuity between study periods

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.3/5.0
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 comprehensively discloses behavioral traits: it explains the tool generates a unique session ID, retrieves recent sessions/active courses/deadlines, stores data for historical records, and outlines the session workflow (e.g., referencing with loadcontext, ending with endsession). It doesn't mention rate limits or auth needs, but covers most operational aspects.

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

Conciseness2/5

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

The description is excessively long (over 500 words) with redundant sections (e.g., 'Key features' and 'Return information' overlap, 'You should' repeats earlier guidance). While well-structured with headings, it includes unnecessary details like specific ID formats and relation types that don't add proportional value, reducing efficiency.

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 0 parameters, no annotations, and no output schema, the description provides extensive context: it details return information (session ID, recent sessions, active courses, etc.), workflow integration with sibling tools, and usage instructions. It slightly over-explains but covers nearly all needed aspects for a parameterless initialization 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 has 0 parameters with 100% coverage, so the baseline is 4. The description explicitly states 'No parameters required - the tool automatically retrieves all relevant context', which adds clarity beyond the empty schema, confirming the tool's parameterless nature.

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 'initializes a new academic study session' and 'starts a new study session', clearly distinguishing it from sibling tools like 'endsession' or 'loadcontext'. It specifies the verb ('starts', 'initializes') and resource ('study session') with precise scope.

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 includes a dedicated 'When to use this tool' section with 10 specific scenarios (e.g., 'Beginning a new study session', 'Getting oriented in your current academic state'), and explicitly mentions integration with 'loadcontext' and 'endsession' tools, providing clear alternatives and workflow context.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 6 tool updatesv1.0.0
    • First observedadvancedcontext
    • First observedbuildcontext
    • First observeddeletecontext
    • First observedendsession
    • First observedloadcontext
    • First observedstartsession

TDQS

A4.6/5.0

Scored across 6 tools

Disambiguation4/5

The tools are mostly distinct with clear purposes: advancedcontext for querying, buildcontext for creating, deletecontext for deleting, loadcontext for retrieving details, startsession for initiating sessions, and endsession for documenting sessions. However, advancedcontext and loadcontext have some overlap in retrieving educational information, which could cause confusion about when to use each, though their descriptions help differentiate query operations from detailed context retrieval.

Naming Consistency5/5

All tool names follow a consistent pattern using descriptive compound words (e.g., advancedcontext, buildcontext, deletecontext, loadcontext, startsession, endsession). This consistency in naming style (all lowercase, no underscores or camelCase) makes the set predictable and easy to understand, enhancing usability for agents.

Tool Count5/5

With 6 tools, the server is well-scoped for managing an educational knowledge graph. Each tool serves a distinct role in the CRUD lifecycle (create, read, update, delete) and session management, with no redundant or missing pieces. This count is appropriate for the domain, providing comprehensive coverage without being overwhelming.

Completeness5/5

The tool set offers complete coverage for the educational knowledge graph domain. It includes advancedcontext for querying, buildcontext for creating entities/relations/observations, deletecontext for removal, loadcontext for detailed retrieval, startsession for session initiation, and endsession for session documentation and updates. This covers all essential operations from data management to progress tracking, with no obvious gaps that would hinder agent workflows.

Maintenance

ActivityInactive
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers