Skip to main content
Glama

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:

  1. summary: Records session summary, duration, and course focus

  2. conceptsLearned: Documents concepts studied during the session

  3. assignmentUpdates: Tracks updates to assignments

  4. statusUpdates: Records changes to entity status values

  5. courseStatus: Updates overall course status, priority assignments, and sequential relationships

  6. newConcepts: Records new concepts learned during the session

  7. 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/student

Then 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.js

Docker:

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-student

Available Tools

6 tools
advancedcontextA

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

When to use this tool:

  • Retrieving the complete educational knowledge graph

  • Searching for specific academic entities using keyword matching

  • Fetching details on a precise set of educational entities

  • Getting comprehensive information about a specific course

  • Finding upcoming assignment and exam deadlines

  • Checking detailed status of a specific assignment

  • Preparing for exams with concept retrieval

  • Discovering connections between learning concepts

  • Tracking and reviewing lecture notes

  • Getting an overview of an entire academic term

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

  • Finding high-priority assignments and tasks

  • Exploring sequential relationships between entities

Key features:

  • Ten specialized query operation types

  • Full educational graph retrieval with entities and relations

  • Keyword-based search across academic entities and their properties

  • Direct entity lookup by exact name

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

  • Deadline tracking with time-based filtering

  • Assignment status with progress tracking through has_status relations

  • Priority information via has_priority relations

  • Exam preparation with related concepts and materials

  • Concept relationship mapping

  • Sequential entity relationships via follows relations

  • Lecture note organization

  • Term-based academic overview

  • JSON-formatted response with query results

Parameters explained:

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

    • "graph" - Retrieve the entire educational knowledge graph

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

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

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

    • "deadlines" - Get upcoming assignment and exam deadlines

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

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

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

    • "lecture" - Track and organize notes for lectures

    • "term" - Get overview of an academic term

  • params: Operation-specific parameters structure:

    • For "graph": No parameters needed

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

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

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

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

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

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

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

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

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

Operation details:

  • "graph" returns the complete educational knowledge graph structure

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

  • "nodes" retrieves specific entities by exact name matching

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

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

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

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

  • "concepts" maps relationships between different learning concepts

  • "lecture" organizes and retrieves notes for course lectures

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

Status information:

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

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

  • Course views show assignment completion status

  • Term views highlight course completion percentages based on status

Priority information:

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

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

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

Sequential relationships:

  • Entities can have sequence relationships through follows relations

  • Course views show recommended sequence of assignments and lectures

  • Concept views show prerequisite relationships

Return structures:

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

  • Error responses include detailed error messages

  • Complex operations return rich, structured data about academic entities

  • Educational relationships are preserved in all returned data

  • Status and priority information is included in relevant entity data

You should:

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

  2. Provide the required parameters for your chosen operation type

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

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

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

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

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

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

  9. Prioritize assignments based on priority values

  10. Follow sequential relationships to create effective study plans

  11. Combine query results to build comprehensive study strategies

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

TDQS

A4.6/5.0
Behavior4/5

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

With no annotations provided, the description carries full burden and does well by detailing return structures ('All operations return { success: true/false, ... }'), error handling ('Error responses include detailed error messages'), data relationships ('Educational relationships are preserved'), and specific behaviors like status/priority filtering capabilities. It doesn't mention rate limits or authentication requirements, keeping it from a perfect score.

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

Conciseness3/5

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

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

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

Completeness5/5

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

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

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

Parameters5/5

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

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

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

Purpose5/5

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

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

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance with a 'When to use this tool' section listing 13 specific scenarios, plus a numbered 'You should' section with 11 actionable recommendations. It distinguishes when to use specific operation types (e.g., 'Use "search" for exploratory investigation' vs 'Use "course" to get a comprehensive view').

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

buildcontextA

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

When to use this tool:

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

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

  • Documenting observations about your academic materials

  • Building a connected graph of your educational experience

  • Organizing your study resources and materials

  • Tracking relationships between concepts and learning materials

  • Recording course-specific details like schedules and due dates

  • Creating structured representations of your academic knowledge

  • Setting status values for educational entities

  • Assigning priority to assignments and tasks

Key features:

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

  • Type validation against academic domain standards

  • Automatic rejection of invalid entity or relation types

  • Safe addition of new observations to existing academic entities

  • Status and priority assignment through entity-relation model

  • JSON-formatted response with operation results

  • Clear error messages when operations fail

  • Handles both single and batch operations

Parameters explained:

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

    • "entities" - Create new academic entities

    • "relations" - Create relationships between existing entities

    • "observations" - Add observations to existing entities

  • data: Operation-specific data structure:

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

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

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

Entity Types:

  • course - Academic courses you're taking

  • assignment - Homework, projects, and other submitted work

  • exam - Tests, quizzes, and other assessments

  • concept - Knowledge topics and learning objectives

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

  • note - Personal study notes and observations

  • lecture - Individual class sessions

  • project - Larger educational projects

  • question - Specific questions for study or review

  • term - Academic terms or semesters

  • goal - Learning objectives and targets

  • professor - Course instructors and teachers

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

  • priority - Entity priority (low, high)

Relation Types include:

  • enrolled_in - Student is taking a course

  • assigned_in - Assignment is part of a course

  • due_on - Assignment/exam has specific due date

  • covers - Lecture/resource covers concept

  • references - Note references concept

  • prerequisite_for - Concept is foundation for another

  • taught_by - Course taught by professor

  • scheduled_for - Lecture/exam scheduled for specific time

  • contains - Course contains lectures/assignments

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

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

  • follows - Entity follows another in a sequence

Status Values:

  • not_started - Work on the entity has not begun

  • in_progress - Work is actively underway

  • complete - Work has been finished

Priority Values:

  • low - Lower priority item

  • high - Higher priority item

You should:

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

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

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

  4. Ensure entities exist before creating relations between them

  5. Provide meaningful names and descriptions for new entities

  6. Use observations to add general metadata about entities

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

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

  9. Use follows relations to establish sequences between related entities

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

  11. Check the operation result to confirm successful creation

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

TDQS

A4.6/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does an excellent job describing behavioral traits: it explains the three operation types, mentions type validation and automatic rejection of invalid types, describes safe addition of observations, notes JSON-formatted responses and clear error messages, and specifies that it handles both single and batch operations. The only minor gap is not explicitly stating whether this is a read-only or mutation operation, though 'constructing and enhancing' implies mutation.

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

Conciseness3/5

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

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

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

Completeness5/5

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

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

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

Parameters5/5

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

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

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

Purpose5/5

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

The description clearly states the tool's purpose: 'constructing and enhancing your educational knowledge graph' with three specific operation types (entities, relations, observations). It distinguishes this from siblings like 'deletecontext' and 'loadcontext' by emphasizing creation and enhancement rather than deletion or loading.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

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

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

deletecontextA

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

When to use this tool:

  • Removing completed or dropped courses

  • Deleting obsolete relationships between academic entities

  • Pruning outdated notes or observations that are no longer relevant

  • Correcting errors in your academic knowledge graph

  • Cleaning up test or practice entities

  • Maintaining graph accuracy as your educational focus changes

  • Removing duplicate learning materials or resources

  • Archiving completed assignments or exams

  • Updating status or priority relations when they change

  • Modifying entity sequences

Key features:

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

  • Cascading deletion for entities (automatically removes related relations)

  • Precise deletion of specific observations without removing entire entities

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

  • Batch operations for efficient cleanup

  • JSON-formatted response with operation results

  • Secure validation before deletion

  • Clear error messages when operations fail

Parameters explained:

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

    • "entities" - Remove academic entities and their relations

    • "relations" - Remove specific relationships between entities

    • "observations" - Remove specific observations from entities

  • data: Operation-specific data structure:

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

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

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

Deletion behavior by type:

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

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

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

Status and Priority Management:

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

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

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

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

Safety considerations:

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

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

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

  • Relations require entities on both ends to exist

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

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

You should:

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

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

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

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

  5. Verify the entities or relations exist before attempting deletion

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

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

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

  9. Check the operation result to confirm successful deletion

  10. Consider documenting major deletions as observations on related entities

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

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

TDQS

A4.9/5.0
Behavior5/5

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

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

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

Conciseness4/5

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

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

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

Completeness5/5

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

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

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

Parameters5/5

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

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

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

Purpose5/5

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

The description clearly states the tool's purpose: 'removing elements from your educational knowledge graph' with specific deletion operations (entities, relationships, observations). It distinguishes from siblings like 'buildcontext' (creation) and 'loadcontext' (retrieval) by focusing exclusively on deletion operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit 'When to use this tool' section with 10 specific scenarios (e.g., 'Removing completed or dropped courses', 'Deleting obsolete relationships'), plus a numbered 'You should' section with 11 procedural guidelines. It clearly differentiates when to use this deletion tool versus creation/retrieval siblings.

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

endsessionA

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

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

Key features:

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

  • Records concepts learned in the knowledge graph

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

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

  • Establishes sequential relationships between concepts using follows relations

  • Creates connections between concepts and courses

  • Updates course status metadata

  • Creates new concept entities for topics you've studied

  • Maintains session continuity with unique session IDs

  • Supports revision of previous stages when needed

  • Offers a comprehensive assembly stage that consolidates all session information

  • Organizes your academic knowledge into a coherent structure

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

  1. Summary Stage: Records basic session information

  2. Concepts Learned Stage: Documents specific concepts studied

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

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

  5. Course Status Stage: Updates the overall course status

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

Parameters explained:

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

  • Obtained from the startsession tool

  • Example: "stu_1234567890_abc123"

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

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

  • Each stage has specific data requirements and processing logic

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

  • Starts at 1 and typically progresses through 6 stages

  • Used to track progress through the session documentation workflow

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

  • Typically 6 for the complete workflow

  • Provides context for the progress within the overall process

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

  • Descriptive text explaining the work done in this stage

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

  1. stageData: Optional - Stage-specific structured data

  • Structure varies by stage type:

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

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

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

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

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

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

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

  • Boolean value (true/false)

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

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

  • Boolean value (true/false)

  • Default: false

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

  • Required when isRevision is true

  • Indicates which previous stage is being updated

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

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

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

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

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

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

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

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

Return information:

  • JSON response with the following structure:

    • success: Boolean indicating whether the operation succeeded

    • stageCompleted: The stage that was just completed

    • nextStageNeeded: Whether more stages are required

    • stageResult: The processed result of the current stage

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

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

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

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

  • Error information when operation fails

Status and Priority Values:

  • Valid status values: not_started, in_progress, complete

  • Valid priority values: low, high

You should:

  • Complete all stages in order for comprehensive session documentation

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

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

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

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

  • Specify sequential relationships between concepts when appropriate

  • Use clear, descriptive names for any new concepts

  • Include relevant observations for course status updates

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

  • Only mark nextStageNeeded as false on the final assembly stage

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

  • Use the unique session ID consistently across all stages

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

TDQS

A4.8/5.0
Behavior5/5

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

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

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

Conciseness3/5

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

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

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

Completeness5/5

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

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

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

Parameters5/5

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

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

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

Purpose5/5

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

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

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

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

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

loadcontextA

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

When to use this tool:

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

  • Exploring course materials, lecture schedules, and assignment deadlines

  • Preparing for upcoming exams by identifying key concepts and resources

  • Tracking assignment status and due dates

  • Understanding relationships between academic concepts

  • Examining course structures and learning resources

  • Planning study sessions around specific courses or topics

  • Reviewing term schedules and upcoming deadlines

  • Organizing academic resources by courses and concepts

  • Establishing context for effective learning and study planning

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

  • Checking priority levels for assignments and tasks

  • Understanding sequential relationships between academic entities

Key features:

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

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

  • Presents both direct entity information and related academic elements

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

  • Tracks loaded entities within the current session for continuity

  • Formats information in a clean, readable markdown structure

  • Automatically identifies relationships between academic entities

  • Displays status information via has_status relations

  • Shows priority levels via has_priority relations

  • Presents sequential relationships through follows relations

  • Highlights status of assignments and upcoming deadlines

  • Shows progress metrics for courses and assignment completion

Parameters explained:

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

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

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

  • Default: "course"

  • Accepts values from valid entity types for the student domain

  • Helps the system format the output appropriately

  1. sessionId: Optional - The current session identifier

  • Typically provided by startsession

  • Used for tracking entity views within the session

Each entity type returns specialized context information:

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

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

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

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

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

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

Status and Priority:

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

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

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

  • Priority information helps identify important tasks and assignments

Sequential Relationships:

  • Related entities may have follows relationships indicating recommended sequence

  • Course view shows sequenced lectures and assignments

  • Concept view shows prerequisite relationships between concepts

Return information:

  • Formatted markdown text with hierarchical structure

  • Sections adapted to the specific entity type

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

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

You should:

  • Specify the exact entity name for accurate retrieval

  • Provide the entity type when possible for optimally formatted results

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

  • Use assignment context to track deadlines and submission status

  • Prepare for exams by examining exam context for study resources

  • Explore concept context to understand relationships between academic topics

  • Review term context to plan your academic schedule

  • Pay attention to status values to identify incomplete assignments

  • Consider priority information when planning your study schedule

  • Follow sequential relationships to create effective learning paths

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

  • Use in conjunction with startsession to maintain session tracking

  • Combine with endsession to document your learning progress

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

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

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It thoroughly explains the tool's behavior, including output formatting (markdown), session tracking, entity type adaptations, and relationships like status and priority. However, it lacks details on error handling or rate limits, which are minor gaps.

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

Conciseness2/5

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

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

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

Completeness5/5

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

Given the tool's complexity (3 parameters, no annotations, no output schema), the description is highly complete. It covers purpose, usage, parameters, behavior, output format, and relationships with sibling tools, providing all necessary context for effective agent use without relying on structured fields.

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

Parameters5/5

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

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

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

Purpose5/5

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

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

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

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

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

startsessionA

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

When to use this tool:

  • Beginning a new study session or learning period

  • Getting oriented in your current academic state

  • Planning which courses or assignments to focus on

  • Reviewing recent study activity and progress

  • Checking upcoming deadlines for assignments and exams

  • Deciding which concepts need attention

  • Establishing context before diving into specific study work

  • Creating a structured record of your study activity

  • Identifying high-priority assignments that need attention

  • Tracking progress through status information

Key features:

  • Generates a unique study session identifier for tracking activity

  • Retrieves and displays your most recent study sessions

  • Shows active courses (based on has_status relations)

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

  • Identifies assignment status (not_started, in_progress, complete)

  • Highlights upcoming assignment and exam deadlines

  • Lists recently studied concepts for review

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

  • Provides seamless integration with loadcontext tool

  • Stores study session data for historical record keeping

Parameters explained:

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

Return information:

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

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

    • Date

    • Course focus

    • Study session summary (truncated for readability)

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

    • Course name

    • Course code or description

    • Status via has_status relation

    • Priority if assigned via has_priority relation

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

    • Assignment name

    • Current status (not_started, in_progress, complete)

    • Course it belongs to

    • Due date if available

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

    • Assignment/exam name

    • Course it belongs to

    • Due date

    • Days remaining until due

    • Status (not_started, in_progress, complete)

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

Session workflow:

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

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

  3. Session activities are tracked for later recording

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

  5. Session history becomes available for future startsession calls

Status and Priority:

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

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

  • This information helps you prioritize your study activities

You should:

  1. Begin each focused study period with startsession

  2. Review the provided context to determine your study focus

  3. Prioritize high-priority assignments with upcoming deadlines

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

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

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

  7. Complete your study work on your selected focus area

  8. End the session with endsession when work is complete

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

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

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations provided, the description carries full burden and comprehensively discloses behavioral traits: it explains the tool generates a unique session ID, retrieves recent sessions/active courses/deadlines, stores data for historical records, and outlines the session workflow (e.g., referencing with loadcontext, ending with endsession). It doesn't mention rate limits or auth needs, but covers most operational aspects.

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

Conciseness2/5

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

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

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

Completeness4/5

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

Given 0 parameters, no annotations, and no output schema, the description provides extensive context: it details return information (session ID, recent sessions, active courses, etc.), workflow integration with sibling tools, and usage instructions. It slightly over-explains but covers nearly all needed aspects for a parameterless initialization tool.

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

Parameters4/5

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

The schema has 0 parameters with 100% coverage, so the baseline is 4. The description explicitly states 'No parameters required - the tool automatically retrieves all relevant context', which adds clarity beyond the empty schema, confirming the tool's parameterless nature.

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

Purpose5/5

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

The description explicitly states the tool 'initializes a new academic study session' and 'starts a new study session', clearly distinguishing it from sibling tools like 'endsession' or 'loadcontext'. It specifies the verb ('starts', 'initializes') and resource ('study session') with precise scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

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

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

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

TDQS

A4.6/5.0
Disambiguation4/5

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

Naming Consistency5/5

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

Tool Count5/5

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

Completeness5/5

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

Maintenance

ActivityInactive
ResponsivenessNo issues

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

Related MCP Servers

Latest Blog Posts

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