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., "@Codebase Knowledge Graph MCP Server show observations for validatePayment function"
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.
This server provides a Model Context Protocol (MCP) interface specifically designed to interact with a knowledge graph representing a software codebase. It allows storing and retrieving rich, structured information about code entities (classes, functions, files, etc.), their relationships (calls, imports, implements, etc.), and associated qualitative observations (such as design decisions, pattern usage, change rationale, comments, and more).
The goal is to build a comprehensive, queryable representation of the codebase that goes beyond static analysis, capturing architectural insights and development context.
server.js: The main Node.js script that runs the MCP server.
memory.json: The default file used to persist the knowledge graph data.
Related MCP server: GID MCP Server
Install Dependencies:
npm installRun the Server:
node server.jsThe server will listen for MCP requests on standard input/output.
Persistence Configuration:
The knowledge graph is persisted in a file named memory.json by default, located in the same directory as server.js.
The file uses the JSON Lines (JSONL) format, where each line is a separate JSON object representing either an entity or a relation.
You can specify a custom path for the persistence file by setting the MEMORY_FILE_PATH environment variable before running the server:
# Example using a custom path (Linux/macOS)
export MEMORY_FILE_PATH=/path/to/your/custom-graph.jsonl
node server.js
# Example using a custom path (Windows PowerShell)
$env:MEMORY_FILE_PATH = "C:\path\to\your\custom-graph.jsonl"
node server.jsThe graph stored and managed by this server consists of three primary components: Entities, Relations, and Observations. Entities represent the core elements (code constructs, project), Relations define connections between them, and Observations attach qualitative information or metadata.
The detailed structure of these components, as defined in server.js, is as follows:
EntityRepresents a distinct element within the codebase or project.
name (string, required): Unique identifier (e.g., function name, class name, file path).
entityType (string, required): Type of entity (e.g., 'class', 'function', 'module', 'variable', 'file', 'project').
language (string, optional): Programming language (e.g., 'javascript', 'python').
filePath (string, optional): Relative path to the file containing the entity.
startLine (number, optional): Starting line number (1-indexed).
endLine (number, optional): Ending line number (1-indexed).
signature (string, optional): For functions/methods: parameter list, return type.
summary (string, optional): Brief description (e.g., from docstring).
accessModifier ('public' | 'private' | 'protected', optional): Language-specific access control.
isStatic (boolean, optional): Language-specific static indicator.
isAsync (boolean, optional): Language-specific async indicator.
namespace (string, optional): Module or namespace.
tags (string[], optional): User-defined tags for categorization.
observations (Observation[], required): Array of Observation objects associated with this entity (initialized as empty array if not provided).
metadata (Record<string, any>, optional): Other custom or tool-specific data.
ProjectEntityA specific type of Entity (entityType: 'project') used to store high-level information about the project itself.
name (string, required): Unique name/identifier for the project (e.g., 'my-web-app').
entityType ('project', required): Must be 'project'.
description (string, optional): High-level description of the project.
technologies (string[], optional): List of key technologies used (e.g., ['React', 'Node.js', 'PostgreSQL']).
architectureStyle (string, optional): Overall architecture (e.g., 'Microservices', 'Monolith', 'Serverless').
repositoryUrl (string, optional): URL of the code repository.
observations (Observation[], required): Relevant observations for the project itself (e.g., high-level design decisions, roadmap links).
metadata (Record<string, any>, optional): Other custom project-specific data.
RelationRepresents a directed relationship between two Entities.
from (string, required): Name of the source entity.
to (string, required): Name of the target entity.
relationType (string, required): Type of relationship (e.g., 'CALLS', 'IMPLEMENTS', 'IMPORTS', 'CONTAINS').
filePath (string, optional): File where the relation occurs/is defined.
line (number, optional): Line number where the relation occurs (1-indexed).
contextSnippet (string, optional): Small code snippet illustrating the relation.
metadata (Record<string, any>, optional): Other custom or tool-specific data.
ObservationRepresents a piece of qualitative information or metadata attached to an Entity.
id (string, required): Unique ID for the observation (automatically generated UUID if not provided).
observationType (string, required): Type of observation. Standard types include:
'design_pattern_use': Describes the use of a design pattern. Recommended metadata: { patternName: string, role?: string }.
'design_decision': Documents a specific design choice. Recommended metadata: { rationale?: string, alternativesConsidered?: string[], decisionMaker?: string, relatedIssue?: string }.
'change_rationale': Explains the reason for a code change. Recommended metadata: { commitHash?: string, author?: string, relatedIssue?: string, summaryOfChange?: string }.
'project_meta': Stores project-level metadata (usually attached to a 'Project' entity). Recommended metadata depends on the specific info (e.g., { repositoryUrl: string, primaryTechnology: string }).
Other common types: 'comment', 'todo', 'fixme', 'security_note', 'performance_note'.
content (string, required): The main text/content of the observation.
filePath (string, optional): File relevant to the observation.
line (number, optional): Line number relevant to the observation (1-indexed).
severity ('high' | 'medium' | 'low' | 'info', optional): Severity level.
source (string, optional): Origin (e.g., 'static_analysis', 'human_annotator', 'llm', 'code_comment').
timestamp (string, optional): ISO 8601 timestamp (e.g., new Date().toISOString()).
author (string, optional): Who/what created the observation.
relatedEntities (string[], optional): Names of other related entities.
metadata (Record<string, any>, optional): Other custom data. See recommended fields under observationType for standard types.
The server exposes the following tools via the Model Context Protocol (MCP). The input for each tool corresponds to the arguments field within an MCP CallToolRequest.
create_entitiesPurpose: Creates one or more new entities in the knowledge graph. If an entity with the same name already exists, it is ignored.
Arguments:
{
"entities": [ ]
}Output: Returns a JSON string representation of the array of entities that were successfully created.
create_relationsPurpose: Creates one or more new relations between existing entities. Duplicate relations are ignored.
Arguments:
{
"relations": [ ]
}Output: Returns a JSON string representation of the array of relations that were successfully created.
add_observationsPurpose: Adds observations to existing entities. Fails if the target entity doesn't exist. Assigns unique IDs if missing. Ignores observations with duplicate IDs for the same entity.
Arguments:
{
"observationsInput": [
{
"entityName": "string",
"observationsToAdd": [ ]
}
]
}Output: Returns a JSON string representation of results, showing added observations per entity.
delete_entitiesPurpose: Removes entities and connected relations.
Arguments:
{
"entityNames": [ "string" ]
}Output: Confirmation message.
delete_observationsPurpose: Removes specific observations by ID from entities.
Arguments:
{
"deletions": [
{
"entityName": "string",
"observationIds": [ "string"]
}
]
}Output: Confirmation message.
delete_relationsPurpose: Removes specific relations.
Arguments:
{
"relations": [
{ "from": "string", "to": "string", "relationType": "string" },
]
}Output: Confirmation message.
read_graphPurpose: Retrieves the entire graph.
Arguments: None (or {}).
Output: JSON string of the graph: { "entities": [...], "relations": [...] }.
search_nodesPurpose: Searches entities based on a query string (checks names, types, observations, metadata, etc.).
Arguments:
{
"query": "string"
}Output: JSON string of the filtered graph (matching entities and relations between them).
open_nodesPurpose: Retrieves specific entities by name and relations between them.
Arguments:
{
"names": [ "string"]
}Output: JSON string of the filtered graph (requested entities and relations between them).
Here are examples showing the arguments part of an MCP CallToolRequest for common operations:
Use create_entities with entityType: 'project':
{
"entities": [
{
"name": "my-awesome-library",
"entityType": "project",
"description": "A library for doing awesome things.",
"technologies": ["TypeScript", "Node.js"],
"architectureStyle": "Monolith",
"repositoryUrl": "https://github.com/user/my-awesome-library",
"observations": []
}
]
}Use create_entities with entityType: 'function':
{
"entities": [
{
"name": "calculateTotalAmount(items)",
"entityType": "function",
"language": "javascript",
"filePath": "src/utils/calculations.js",
"startLine": 25,
"endLine": 40,
"signature": "(items: Item[]): number",
"summary": "Calculates the total amount based on a list of items.",
"accessModifier": "public",
"isAsync": false,
"observations": [],
"tags": ["core-logic", "billing"]
}
]
}Use add_observations. Note the structure: observationsInput is an array, containing objects for each entity being updated. Each object specifies entityName and an observationsToAdd array.
{
"observationsInput": [
{
"entityName": "MyCoreClass",
"observationsToAdd": [
{
"observationType": "design_decision",
"content": "Decided to use Strategy pattern for handling different output formats.",
"source": "architect_meeting_notes_2023-10-27",
"author": "Alice",
"timestamp": "2023-10-27T10:00:00Z",
"metadata": {
"rationale": "Provides flexibility to add new formats without modifying the core class.",
"alternativesConsidered": ["Factory Method", "Simple if/else"],
"decisionMaker": "Bob",
"relatedIssue": "PROJ-123"
}
}
]
}
]
}Use add_observations:
{
"observationsInput": [
{
"entityName": "ConfigurationManager",
"observationsToAdd": [
{
"observationType": "design_pattern_use",
"content": "Implemented as a Singleton to ensure single point of access to configuration.",
"source": "code_review_comment_456",
"author": "Charlie",
"metadata": {
"patternName": "Singleton",
"role": "unique_instance"
}
}
]
}
]
}Use add_observations:
{
"observationsInput": [
{
"entityName": "calculateTotalAmount(items)",
"observationsToAdd": [
{
"observationType": "change_rationale",
"content": "Refactored calculation logic for improved performance.",
"source": "git_commit_a1b2c3d4",
"author": "David",
"timestamp": "2023-10-26T15:30:00Z",
"metadata": {
"commitHash": "a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2",
"relatedIssue": "PERF-45",
"summaryOfChange": "Replaced loop with vectorized operation."
}
}
]
}
]
}Use create_relations to link two existing entities (e.g., OrderProcessor calls calculateTotalAmount):
{
"relations": [
{
"from": "OrderProcessor.process()",
"to": "calculateTotalAmount(items)",
"relationType": "CALLS",
"filePath": "src/services/OrderProcessor.js",
"line": 88
}
]
}This command downloads and runs the latest version of the server:
{
"mcpServers": {
"codenexus-knowledge-graph": {
"command": "npx",
"args": [
"-y",
"codenexus-mcp"
]
}
}
}(Note: VS Code uses a slightly different structure in settings.json or .vscode/mcp.json)
"mcp": {
"servers": {
"codenexus-knowledge-graph": {
"command": "npx",
"args": [
"-y",
"codenexus-mcp"
]
}
}
}The server can be configured using the MEMORY_FILE_PATH environment variable to specify a custom location for the knowledge graph data file.
{
"mcpServers": {
"codenexus-knowledge-graph": {
"command": "npx",
"args": [
"-y",
"codenexus-mcp"
],
"env": {
"MEMORY_FILE_PATH": "/path/to/your/custom-graph.jsonl"
}
}
}
}(Note: Example for VS Code settings.json below)
"mcp": {
"servers": {
"codenexus-knowledge-graph": {
"command": "npx",
"args": [
"-y",
"codenexus-mcp"
],
"env": {
"MEMORY_FILE_PATH": "/path/to/your/custom-graph.jsonl"
}
}
}
}This project is currently unlicensed. Please add appropriate license information here (e.g., MIT License) and include a LICENSE file if applicable.
Add observations to existing entities.
| Name | Required | Description | Default |
|---|---|---|---|
| observationsInput | Yes |
| Name | Required | Description |
|---|---|---|
| content | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description does not disclose side effects (e.g., whether observations are appended or overwritten), error conditions, or authorization requirements. The simple statement 'Add observations' lacks behavioral depth.
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 a single sentence with no unnecessary words. It is appropriately front-loaded and efficient.
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?
The tool has a complex input schema with nested objects, but the description omits key details like return value (output schema exists) and behavior for missing entities. Given sibling diversity, more context is needed for safe usage.
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 a 0% description coverage according to context, so the description must compensate. However, it only says 'Add observations to existing entities'—nothing about the required 'entityName' or the 'observationsToAdd' array structure. This adds minimal meaning beyond the tool name.
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 action (add) and resource (observations to existing entities). It is specific and distinguishes from sibling tools like 'delete_observations' and 'create_entities'.
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?
No guidance is provided on when to use this tool versus alternatives, prerequisites (e.g., entity must exist), or exclusions. The description is purely functional without strategic context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create multiple new entities in the knowledge graph.
| Name | Required | Description | Default |
|---|---|---|---|
| entities | Yes | Array of partial entity objects to create. 'name' and 'entityType' are required. Nested 'observations' require 'observationType' and 'content'. |
| Name | Required | Description |
|---|---|---|
| content | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full behavioral disclosure. It only states the action of creating entities, but lacks details on idempotency, error handling, side effects, or expected behavior on duplicate entries. This is a significant gap for a creation tool.
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 a single, front-loaded sentence that efficiently communicates the tool's purpose without any wasted words. It is appropriately concise.
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 complexity of the input schema (nested objects, many optional fields) and the existence of an output schema, the one-line description is insufficient. It does not address constraints, return values, or broader context that would help an agent use the 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?
Schema description coverage is 100%, with each property having a clear description. The tool description adds no extra meaning beyond what the schema already provides, meeting the baseline for high coverage.
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 verb 'create' and the resource 'multiple new entities in the knowledge graph'. It effectively distinguishes from sibling tools like 'create_relations' and 'add_observations' by specifying that it deals with entities and supports batch creation.
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 implies usage for creating entities but provides no explicit guidance on when to use this tool versus alternatives like 'create_relations' or 'add_observations'. The context of 'multiple new entities' suggests batch operations, but no exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create multiple new relations between existing entities.
| Name | Required | Description | Default |
|---|---|---|---|
| relations | Yes | Array of partial relation objects to create. 'from', 'to', and 'relationType' are required. |
| Name | Required | Description |
|---|---|---|
| content | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It states that relations are between existing entities but does not mention side effects, permissions, error handling, or whether it is an atomic operation.
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 a single sentence that front-loads the verb and resource. It is appropriately sized with no wasted words.
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?
Despite having an output schema and full parameter coverage, the description is too brief for a bulk creation operation. It lacks details about partial failures, idempotency, or validation of existing entities.
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?
All parameters have descriptions in the schema, achieving 100% coverage. The description adds minimal extra context (e.g., 'multiple', 'existing entities') but does not elaborate on parameter formats or constraints beyond the schema.
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 action (create), the resource (relations), and the scope (multiple new, between existing entities). It is distinct from sibling tools like 'delete_relations'.
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 implies usage for creating relations but provides no explicit guidance on when to use this tool versus alternatives like 'create_entities' or 'add_observations'. No conditions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete entities and their associated relations/observations by name.
| Name | Required | Description | Default |
|---|---|---|---|
| entityNames | Yes | Array of names of the entities to delete. |
| Name | Required | Description |
|---|---|---|
| content | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that deletion cascades to associated relations and observations, which is a critical behavioral trait beyond the obvious delete. No annotations exist, so the description carries the burden and does well, though it could mention irreversibility or permissions.
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?
Single sentence, no redundant words, directly communicates the core action and side effect.
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?
Simple tool with one parameter and output schema present. The description covers the main function and cascade, but lacks details on error handling (e.g., non-existent entities). Still mostly complete for this context.
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?
Schema coverage is 100% and the description adds no extra meaning beyond what the schema already provides. Baseline score of 3 is appropriate.
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 action (delete) and resource (entities), and mentions associated relations/observations. It distinguishes from sibling tools that only delete observations or relations, but does not explicitly name alternatives.
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?
No guidance on when to use this tool versus siblings like delete_observations or delete_relations. The description does not provide context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete specific observations from entities.
| Name | Required | Description | Default |
|---|---|---|---|
| deletions | Yes |
| Name | Required | Description |
|---|---|---|
| content | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description only mentions 'Delete' without detailing side effects, permissions, error handling, or whether deletions are cascading. The behavior is under-described for a mutation tool.
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 a single sentence, front-loading the core action. It is concise but could be expanded slightly without losing impact. No unnecessary words.
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 complexity (a delete operation requiring precise input) and the presence of an output schema, the description fails to provide sufficient context about usage, preconditions, or return values. It is minimally complete.
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?
Schema description coverage is 0%, so the description carries full burden. It does not explain the 'deletions' parameter structure (array of objects with entityName and observationIds). The schema itself has descriptions, but the tool description adds no parameter-level 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 deletes 'specific observations from entities,' which matches the tool name and distinguishes it from siblings like 'add_observations' and 'delete_entities'.
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?
No guidance is given on when to use this tool versus alternatives (e.g., delete_entities, delete_relations). The description implies it is for observations, but lacks explicit usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete specific relations between entities.
| Name | Required | Description | Default |
|---|---|---|---|
| relations | Yes | Array of partial relation objects identifying relations to delete. 'from', 'to', and 'relationType' are required. |
| Name | Required | Description |
|---|---|---|
| content | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only states 'delete', which implies destructiveness, but fails to disclose permanence, error handling (e.g., what if a relation doesn't exist), or impact on associated data. The output schema exists but is not described.
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 extremely concise (6 words), front-loading the action. However, it sacrifices substance important for accurate tool selection and invocation. Every word earns its place, but the description is too terse to be fully informative.
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 moderate complexity (one parameter with nested objects) and existence of an output schema, the description lacks context about return values, batch behavior, or side effects. It does not explain how the tool fits into the overall entity-relation model compared to siblings.
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?
Schema coverage is 100%, so the baseline is 3. The description adds minimal value beyond the schema, simply restating 'specific relations' which is already implied by the required fields. No additional context is given about the format of from/to or behavior for missing relations.
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 action 'delete specific relations between entities', which is a specific verb and resource. It distinguishes from siblings like create_relations and delete_entities by specifying 'relations' as the target. However, it could be more detailed about what 'specific' means, though the schema clarifies.
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 no guidance on when to use this tool versus alternatives like delete_entities or delete_observations. It does not mention prerequisites, when not to use it, or any conditions. This is a significant gap for agent decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve specific entities by name and their direct relations.
| Name | Required | Description | Default |
|---|---|---|---|
| names | Yes | Array of entity names to retrieve. |
| Name | Required | Description |
|---|---|---|
| content | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It clearly states that the tool retrieves entities and their direct relations, implying a read-only operation. No contradictions exist. While additional details (e.g., performance, pagination) could enhance transparency, the core behavior is well communicated.
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 a single, front-loaded sentence with no redundant words. It communicates the essential action and scope efficiently, earning its place without any filler.
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 simplicity (one required parameter, no nested objects, presence of an output schema), the description adequately conveys the main functionality. However, it could be slightly improved by clarifying how 'direct relations' are defined, especially to differentiate from sibling tools like 'read_graph'.
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?
Schema description coverage is 100%, so the input schema already documents the 'names' parameter. The description adds minimal semantic value by linking 'by name' to the parameter, but does not provide additional constraints, formatting, or examples beyond what the schema offers. Baseline score of 3 is appropriate.
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 uses a specific verb 'retrieve' and clearly identifies the resource ('entities by name') and scope ('their direct relations'). It distinguishes from sibling tools like 'search_nodes' (likely broader search) and 'read_graph' (likely all nodes) by specifying retrieval by name with relations.
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 no explicit guidance on when to use this tool versus alternatives such as 'search_nodes' or 'read_graph'. It does not state prerequisites, limitations, or exclusions, leaving the agent to infer usage solely from the purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the entire current knowledge graph.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| content | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states it reads the entire graph but does not disclose potential performance impacts, idempotency, or whether it's a safe operation. This minimal transparency is acceptable but not thorough.
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 a single sentence with no wasted words. It is concise and to the point, achieving its purpose without extraneous information.
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 has no parameters and an output schema exists, the description covers the core functionality. However, it could note that the operation might be large or slow. Mostly complete for a simple read 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?
There are no parameters, and the schema coverage is 100% (trivially). The description does not need to add parameter details. Baseline for 0 parameters is 4, and the description appropriately focuses on the tool's action.
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 uses the verb 'Read' and specifies the resource 'entire current knowledge graph', clearly indicating the tool's function. It distinguishes itself from sibling tools like add_observations, create_entities, etc., which are mutation or search 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?
No guidance is provided on when to use this tool versus alternatives like search_nodes or open_nodes. The description does not mention that it returns the entire graph, which could be expensive for large graphs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for nodes (entities) based on a query string across various fields.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The search query string. |
| Name | Required | Description |
|---|---|---|
| content | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description should fully disclose behavior. It mentions 'across various fields' but doesn't specify which fields, query syntax, case sensitivity, pagination, or output format. This lack of detail makes it hard for an agent to predict behavior.
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?
A single, concise sentence that fronts the verb and resource. Every word earns its place with no 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?
Given the single parameter and existence of an output schema, the description partially covers search behavior but remains vague about field coverage and result handling. Adequate but not rich.
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?
Schema description coverage is 100% (the single 'query' parameter has a description). The tool description adds 'across various fields', which provides some context but is generic. Baseline 3 is appropriate.
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 verb 'search' and the resource 'nodes', specifying that it searches across various fields. This distinguishes it from siblings like create_entities or delete_entities, which have different purposes.
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?
No explicit guidance on when to use this tool versus alternatives. The name implies search functionality, but there is no mention of when not to use it or comparison to other search capabilities among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.5add_observationscreate_entitiescreate_relationsdelete_entitiesdelete_observationsdelete_relationsopen_nodesread_graphsearch_nodesEach tool has a clearly distinct purpose: creating, deleting, or querying entities, relations, or observations. No overlap between tools like create_entities and create_relations, or delete_entities and delete_observations.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., create_entities, delete_relations, search_nodes). No deviations or mixed conventions.
With 9 tools, the server covers the essential operations for a knowledge graph: CRUD for entities, relations, and observations, plus graph-wide and search queries. The count is well-scoped without bloat.
The tool set provides create, read (via open_nodes, read_graph, search_nodes), and delete operations for all core elements. The update aspect is partially covered by add_observations and create_relations, but missing explicit update for entity or relation properties, which is a minor gap.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Ground-truth code graph for your codebase: exact callers, callees, symbols & dependencies.
Project memory for coding agents: requirements, decisions, code graph and delivery telemetry.
Deterministic context layer for your codebase: change impact, blast radius, answers with receipts.
Ask a codebase what calls what: search, blast radius, paths between symbols, and diffs.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/jigneshsuvariya/codenexus-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
