Skip to main content
Glama
tejpalvirk

Developer MCP Server

by tejpalvirk

buildcontext

Enhance software development knowledge graphs by creating entities, establishing relationships, and adding observations. Use this tool to structure projects, track dependencies, and document development progress efficiently.

Instructions

A powerful tool for building and enriching the software development knowledge graph through creation operations. This tool allows developers to add new entities, create relationships between entities, or add observations to existing entities. Each operation type serves a specific purpose in constructing a comprehensive development context model.

When to use this tool:

  • Creating new project components like features, tasks, and milestones

  • Establishing relationships between development entities (e.g., component implements feature)

  • Documenting observations about existing entities (statuses, descriptions, etc.)

  • Building a graph of connected software development artifacts

  • Recording new information discovered during development

  • Tracking project structure, dependencies, and status

  • Documenting developer roles and assignments

  • Setting entity status and priority values

  • Defining task sequencing and dependencies

Key features:

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

  • Type validation against software development domain standards

  • Automatic rejection of invalid entity or relation types

  • Safe addition of new observations to existing entities

  • 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 software development 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:

  • project - Overall software project

  • component - Module, service, or package within a project

  • feature - Specific functionality being developed

  • issue - Bug or problem to be fixed

  • task - Work item or activity needed for development

  • developer - Team member working on the project

  • technology - Language, framework, or tool used

  • decision - Important technical or architectural decision

  • milestone - Key project deadline or phase

  • environment - Development, staging, production environments

  • documentation - Project documentation

  • requirement - Project requirement or specification

  • status - Entity status (inactive, active, or complete)

  • priority - Entity priority (low or high)

Relation Types include:

  • depends_on - Dependency relationship

  • implements - Component implements a feature

  • blocked_by - Task is blocked by an issue

  • uses - Component uses a technology

  • part_of - Component is part of a project

  • contains - Project contains a component

  • has_status - Links entity to its status (inactive, active, complete)

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

  • precedes - Task precedes another task (for sequencing)

  • related_to - General relationship

  • affects - Issue affects a component

  • resolves - Task resolves an issue

  • documented_in - Component is documented in documentation

  • decided_in - Decision was made in a meeting

  • required_by - Feature is required by a requirement

  • depends_on_milestone - Task depends on reaching a milestone

  • tested_in - Component is tested in an environment

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 software development domain

  4. Ensure entities exist before creating relations between them

  5. Provide meaningful names and descriptions for new entities

  6. Use observations to add metadata about entities

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

  8. For task sequencing, use the 'precedes' relation to define which tasks must be completed before others

  9. Set status values using the has_status relation (valid values: inactive, active, complete)

  10. Set priority values using the has_priority relation (valid values: low, high)

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 full burden and does so effectively. It discloses key behavioral traits: 'Three distinct operation types,' 'Type validation against software development domain standards,' 'Automatic rejection of invalid entity or relation types,' 'Safe addition of new observations,' 'JSON-formatted response,' 'Clear error messages,' and 'Handles both single and batch operations.' It covers most aspects well but could mention performance characteristics like rate limits or latency.

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 appropriately structured with clear sections (purpose, when to use, key features, parameters explained, entity types, relation types, guidelines), but it is lengthy with multiple lists and detailed examples. While informative, some content could be more condensed without losing value, making it less front-loaded than ideal.

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 types) and lack of annotations or output schema, the description is highly complete. It covers purpose, usage, behavior, parameters with examples, valid types, and detailed guidelines, providing all necessary context for an AI agent to use the tool effectively without 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 adds significant meaning beyond the input schema's 100% coverage. It explains the 'type' parameter's three values with detailed semantics ('entities' for creating new entities, 'relations' for relationships, 'observations' for adding metadata) and provides extensive context for the 'data' parameter with examples of valid structures, entity types (14 listed), and relation types (17 listed). This greatly enhances understanding of how to structure inputs.

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: 'building and enriching the software development knowledge graph through creation operations' and specifies it 'allows developers to add new entities, create relationships between entities, or add observations to existing entities.' It distinguishes from siblings like 'deletecontext' and 'loadcontext' by focusing on creation 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 includes an explicit 'When to use this tool' section with 8 specific use cases (e.g., 'Creating new project components,' 'Establishing relationships between development entities'), plus a 'You should' section with 10 detailed guidelines (e.g., 'Specify the operation type,' 'Ensure entities exist before creating relations'). This provides comprehensive guidance on when and how to use this tool versus alternatives.

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/developer'

If you have feedback or need assistance with the MCP directory API, please join our Discord server