Student MCP Server
学生 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 关系显示优先级,并根据顺序依赖关系识别下一个准备处理的作业。
加载上下文
加载特定实体(课程、作业等)的详细上下文,并根据实体类型显示相关信息。包括状态信息、优先级以及相关实体之间的顺序关系。
结束会话
通过结构化的多阶段流程记录学习成果:
summary :记录课程摘要、持续时间和课程重点
学习的概念:记录课程中学习的概念
assignmentUpdates :跟踪作业更新
statusUpdates :记录实体状态值的变化
courseStatus :更新整体课程状态、优先级分配和顺序关系
newConcepts :记录课程中学到的新概念
组装:所有会话数据的最终组装
构建上下文
在知识图谱中创建新的实体、关系或观察:
实体:添加新的教育实体(课程、作业、概念、状态、优先级等)
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.jsDocker:
docker build -t mcp/student -f student/Dockerfile .执照
此 MCP 服务器采用 MIT 许可证。这意味着您可以自由使用、修改和分发该软件,但须遵守 MIT 许可证的条款和条件。更多详情,请参阅项目仓库中的 LICENSE 文件。
环境变量
学生 MCP 服务器支持以下环境变量来自定义数据存储位置:
MEMORY_FILE_PATH :知识图谱数据的存储路径
可以是绝对路径或相对路径(相对路径使用当前工作目录)
默认值:
./student/memory.jsonmemory.json
SESSIONS_FILE_PATH :存储会话数据的路径
可以是绝对路径或相对路径(相对路径使用当前工作目录)
默认值:
./student/sessions.jsonsessions.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-studentAvailable Tools
6 toolsadvancedcontextA
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:
Select the most appropriate query type for your educational information need
Provide the required parameters for your chosen operation type
Start with broader queries and refine to more specific ones
Use "search" for exploratory investigation of your academic knowledge
Use "course" to get a comprehensive view of your coursework
Use "deadlines" to stay on top of upcoming academic work
Use "concepts" to understand relationships between learning topics
Filter search results by status to focus on incomplete work
Prioritize assignments based on priority values
Follow sequential relationships to create effective study plans
Combine query results to build comprehensive study strategies
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes | Parameters for the operation, structure varies by type | |
| type | Yes | Type of get operation: 'graph', 'search', 'nodes', 'course', 'deadlines', 'assignment', 'exam', 'concepts', 'lecture', or 'term' |
TDQS
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.
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.
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.
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.
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.
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:
Specify the operation type based on what you need to create (entities, relations, or observations)
Structure your data according to the operation type's requirements
Use valid entity types and relation types from the academic domain
Ensure entities exist before creating relations between them
Provide meaningful names and descriptions for new entities
Use observations to add general metadata about entities
Use has_status relations to track progress (not_started, in_progress, complete)
Use has_priority relations to indicate importance (low, high)
Use follows relations to establish sequences between related entities
Create complete structures rather than adding entities/relations piecemeal
Check the operation result to confirm successful creation
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | Data for the creation operation, structure varies by type but must be an array | |
| type | Yes | Type of creation operation: 'entities', 'relations', or 'observations' |
TDQS
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.
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.
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.
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.
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.
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:
Identify the specific elements in your academic graph that need to be removed
Choose the appropriate deletion type (entities, relations, or observations)
Structure your data according to the deletion type's requirements
Start with more specific deletions (observations) before broader ones
Verify the entities or relations exist before attempting deletion
When updating status, create a new has_status relation before deleting the old one
When updating priority, create a new has_priority relation before deleting the old one
Consider the impact on entity sequences when deleting follows relations
Check the operation result to confirm successful deletion
Consider documenting major deletions as observations on related entities
When removing an entire course, first delete its components for cleaner removal
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | Data for the deletion operation, structure varies by type but must be an array | |
| type | Yes | Type of deletion operation: 'entities', 'relations', or 'observations' |
TDQS
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.
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.
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.
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.
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.
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:
Summary Stage: Records basic session information
Concepts Learned Stage: Documents specific concepts studied
Assignment Updates Stage: Records status and priority changes to assignments
New Concepts Stage: Defines new concept entities to add
Course Status Stage: Updates the overall course status
Assembly Stage: Consolidates all information and finalizes the session record
Parameters explained:
sessionId: Required - Unique identifier for the study session
Obtained from the startsession tool
Example: "stu_1234567890_abc123"
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
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
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
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"
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
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
isRevision: Optional - Whether this is revising a previous stage
Boolean value (true/false)
Default: false
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:
Concept Entities: Creates entities for each concept learned and links them to the course
Assignment Status Updates: Updates assignment status via has_status relations (not_started, in_progress, complete)
Assignment Priority Updates: Updates assignment priority via has_priority relations (low, high)
Sequential Concept Relationships: Establishes follows relations between concepts when specified
Course Status Update: Updates the course status via has_status relation, adds an updated timestamp, and records observations
New Concept Creation: Creates new concept entities, links them to the course, and establishes any sequential relationships
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
| Name | Required | Description | Default |
|---|---|---|---|
| analysis | No | Text analysis or observations for the current stage | |
| isRevision | No | Whether this is revising a previous stage | |
| nextStageNeeded | Yes | Whether additional stages are needed after this one (false for final stage) | |
| revisesStage | No | If revising, which stage number is being revised | |
| sessionId | Yes | The unique session identifier obtained from startsession | |
| stage | Yes | Current stage of analysis: 'summary', 'conceptsLearned', 'assignmentProgress', 'questions', 'nextSteps', or 'assembly' | |
| stageData | No | Stage-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 | |
| stageNumber | Yes | The sequence number of the current stage (starts at 1) | |
| totalStages | Yes | Total number of stages in the workflow (typically 5 for standard workflow) |
TDQS
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.
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.
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.
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.
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.
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:
entityName: Required - The name of the entity to retrieve context for
Example: "Introduction to Computer Science", "Midterm Paper", "Binary Trees"
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
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
| Name | Required | Description | Default |
|---|---|---|---|
| entityName | Yes | ||
| entityType | No | Type of entity to load, defaults to 'course' | |
| sessionId | No | Session ID from startsession to track context loading |
TDQS
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.
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.
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.
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.
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.
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:
Starting a session creates a session identifier in the student domain
This session can be referenced when loading course context with loadcontext
Session activities are tracked for later recording
Sessions should be ended with endsession to record learning progress
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:
Begin each focused study period with startsession
Review the provided context to determine your study focus
Prioritize high-priority assignments with upcoming deadlines
Focus on incomplete assignments (not_started or in_progress status)
Choose a specific course, assignment, or concept to work on
Use the generated session ID with the loadcontext tool to load specific entities
Complete your study work on your selected focus area
End the session with endsession when work is complete
Record concepts learned, assignment status updates, and study accomplishments
Use the session history to maintain continuity between study periods
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
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.
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.
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.
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.
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.
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.
6 tool updates
v1.0.0- First observed
advancedcontext - First observed
buildcontext - First observed
deletecontext - First observed
endsession - First observed
loadcontext - First observed
startsession
TDQS
Scored across 6 tools
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.
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.
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.
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
Related MCP Connectors
Search, retrieve, create, and update visual knowledge maps in a user's KnowMapped account.
Knowledge graph for AI agents. Query concepts, walk edges, get advisories.
Knowledge graph ingestion, entity search, ontology analysis, and CoSync scoring.
- GoMindOAuthcom.gominddb
Persistent knowledge graph for AI agents. Remember, recall, and forget facts.
Related MCP Servers
- FlicenseAqualityDmaintenanceProvides tools for managing project knowledge graphs, enabling structured representation of projects, tasks, milestones, resources, and team members.616-
- FlicenseAqualityDmaintenanceProvides tools for managing quantitative research knowledge graphs, enabling structured representation of research projects, datasets, variables, hypotheses, statistical tests, models, and results.69-
- FlicenseAqualityDmaintenanceProvides tools for managing qualitative research knowledge graphs, enabling structured representation of research projects, participants, interviews, observations, codes, themes, and findings.610-
- AlicenseNot gradedqualityDmaintenanceIngest, query, and generate study materials from documents (PDF, DOCX, Markdown, images, web pages) using vector search, knowledge graph, and study tools through OpenCode chat.MIT