Skip to main content
Glama

buildcontext

Organize and expand your academic knowledge graph by creating educational entities, establishing relationships, and adding observations to streamline study materials and track progress effectively.

Instructions

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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataYesData for the creation operation, structure varies by type but must be an array
typeYesType of creation operation: 'entities', 'relations', or 'observations'
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.

Install Server

Other Tools

Related Tools

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