Student MCP Server
Provides containerized deployment option for the Student MCP Server, enabling portable and consistent environments across different systems.
Allows installation of the MCP server directly from GitHub repositories for easy deployment and updates.
Enables installation and management of the Student MCP Server through the npm package manager, supporting both global installation and npx execution.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Student MCP Serverstartsession"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Student MCP Server
An MCP server implementation that provides tools for managing student knowledge graphs, enabling structured representation of courses, assignments, exams, concepts, and study resources. This server helps students track their academic progress, manage deadlines, and optimize their learning journey.
Features
Persistent Educational Context: Maintain a structured knowledge graph of educational entities and relationships across multiple sessions
Study Session Management: Track study sessions with unique IDs and record progress over time
Course Management: Organize courses, lectures, assignments, and exams in a structured format
Concept Mapping: Connect learning concepts to show relationships and prerequisites
Assignment Tracking: Monitor assignment status, due dates, and related resources
Exam Preparation: Track exam dates and organize study materials
Deadline Management: Keep track of upcoming due dates for assignments and exams
Resource Organization: Connect learning resources to specific courses and concepts
Progress Monitoring: Track completion status of courses, assignments, and exams
Knowledge Connections: Visualize relationships between different educational concepts
Related MCP server: Quantitative Researcher MCP Server
Entities
The Student MCP Server recognizes the following entity types:
course: Academic courses being taken
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 or undertakings
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 values (active, completed, pending, abandoned)
priority: Priority level values (high, low)
Relationships
Entities can be connected through the following relationship types:
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
requires: Assignment requires specific concepts
related_to: Concept related to another concept
created_for: Note created for specific lecture
studies: Study session focuses on concept/exam
helps_with: Resource helps with assignment/concept
submitted: Assignment submitted on date
part_of: Entity is part of another entity
included_in: Included in a larger component
follows: Entity follows another in sequence
attends: Student attends lecture
graded_with: Assignment/exam graded with specific criteria
has_status: Links entities to their current status (active, completed, pending, abandoned)
has_priority: Links entities to their priority level (high, low)
precedes: Indicates that one task or assignment comes before another in a sequence
Status and Priority Management
The Student MCP Server provides comprehensive status and priority tracking capabilities:
Status Values:
active: Currently being worked on or studied
completed: Finished or successfully submitted
pending: Not yet started but planned
abandoned: No longer being pursued
Priority Values:
high: Requires immediate attention or has significant impact on grades
low: Can be addressed after higher priority items are complete
Sequential Learning Management:
Define which assignments or concepts must be completed before others
Organize study activities in a logical progression
Create dependencies between related learning tasks
Build structured learning paths through course material
Available Tools
The Student MCP Server provides these tools for interacting with educational knowledge:
startsession
Starts a new study session, generating a unique session ID and displaying current courses, upcoming deadlines, recently studied concepts, and past study sessions. Shows status information via has_status relations, priority levels via has_priority relations, and identifies assignments ready to be worked on next based on sequential dependencies.
loadcontext
Loads detailed context for a specific entity (course, assignment, etc.), displaying relevant information based on entity type. Includes status information, priority levels, and sequential relationships between related entities.
endsession
Records the results of a study session through a structured, multi-stage process:
summary: Records session summary, duration, and course focus
conceptsLearned: Documents concepts studied during the session
assignmentUpdates: Tracks updates to assignments
statusUpdates: Records changes to entity status values
courseStatus: Updates overall course status, priority assignments, and sequential relationships
newConcepts: Records new concepts learned during the session
assembly: Final assembly of all session data
buildcontext
Creates new entities, relations, or observations in the knowledge graph:
entities: Add new educational entities (courses, assignments, concepts, status, priority, etc.)
relations: Create relationships between entities (including has_status, has_priority, precedes)
observations: Add observations to existing entities
deletecontext
Removes entities, relations, or observations from the knowledge graph:
entities: Remove educational entities
relations: Remove relationships between entities (including status, priority, and sequential relations)
observations: Remove specific observations from entities
advancedcontext
Retrieves information from the knowledge graph:
graph: Get the entire knowledge graph
search: Search for nodes based on query criteria
nodes: Get specific nodes by name
course: Get details about a specific course
deadlines: Get upcoming deadlines
assignment: Get details about a specific assignment
exam: Get details about a specific exam
concepts: Get information about concepts
lecture: Get information about lectures
term: Get details about an academic term
status: Find entities with a specific status value
priority: Find entities with a specific priority value
sequence: Identify sequential relationships for learning activities
Domain-Specific Functions
The Student MCP Server includes specialized domain functions for education:
getCourseOverview: Comprehensive view of a course including lectures, assignments, exams, and resources
getUpcomingDeadlines: Find assignments and exams with approaching due dates
getAssignmentStatus: Get detailed status of assignments, including progress and related concepts
getExamPrep: Get exam preparation materials and related concepts
findRelatedConcepts: Discover connections between different educational concepts
getStudyProgress: Track study progress across courses
getTermOverview: Get overview of courses and work for an academic term
getConceptMastery: Assess level of understanding for specific concepts
getStatusOverview: View all entities with a specific status (active, completed, pending, abandoned)
getPriorityItems: Identify high-priority assignments and study tasks
getLearningSequence: Visualize the sequence of learning activities based on precedes relations
Example Prompts
Starting a Session
Let's start a new study session for my Computer Science course.Loading Course Context
Load the context for my Calculus 101 course so I can see upcoming assignments and exams.Recording Study Progress
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.Managing Learning Materials
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.Usage
This MCP server enables students to:
Maintain Study Continuity: Keep track of what you've learned across multiple study sessions
Optimize Learning Time: Focus on high-priority assignments and concepts
Track Academic Progress: Monitor completion of courses, assignments, and mastery of concepts
Prepare for Exams: Organize study materials and track progress towards exam readiness
Manage Deadlines: Stay on top of upcoming due dates for assignments and exams
Connect Knowledge: See relationships between different concepts across courses
Prioritize Work: Focus on high-priority assignments and learning tasks
Structure Learning: Create logical sequences for learning related concepts
Track Status: Monitor the status of assignments, projects, and learning activities
Configuration
Usage with Claude Desktop
Add this to your claude_desktop_config.json:
Install from GitHub and run with npx
{
"mcpServers": {
"student": {
"command": "npx",
"args": [
"-y",
"github:tejpalvirk/student"
]
}
}
}Install globally and run directly
First, install the package globally:
npm install -g github:tejpalvirk/studentThen configure Claude Desktop:
{
"mcpServers": {
"student": {
"command": "contextmanager-student"
}
}
}docker
{
"mcpServers": {
"student": {
"command": "docker",
"args": [
"run",
"--rm",
"-i",
"mcp/student"
]
}
}
}Building
From Source
# 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 .License
This MCP server is licensed under the MIT License. This means you are free to use, modify, and distribute the software, subject to the terms and conditions of the MIT License. For more details, please see the LICENSE file in the project repository.
Environment Variables
The Student MCP Server supports the following environment variables to customize where data is stored:
MEMORY_FILE_PATH: Path where the knowledge graph data will be stored
Can be absolute or relative (relative paths use current working directory)
Default:
./student/memory.json
SESSIONS_FILE_PATH: Path where session data will be stored
Can be absolute or relative (relative paths use current working directory)
Default:
./student/sessions.json
Example usage:
# 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. Dates show when Glama detected each change.
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
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
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
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.
Search, read, cite, create, and safely update a user's private KeepFlash knowledge library.
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 gradedqualityBmaintenanceIngest, 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
Appeared in Searches
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/tejpalvirk/student'
If you have feedback or need assistance with the MCP directory API, please join our Discord server