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., "@LogicMap MCP Server Create a project 'MyApp' and add a node for user authentication flow."
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.
An MCP server implementation that provides semantic knowledge graph tools for understanding project structure, business logic, and code relationships.
Semantic Knowledge Graph: Record business logic and conceptual relationships, not just code structure
Multi-Project Management: Manage multiple project knowledge graphs simultaneously
Rich Node Types: Support for concepts, flows, modules, components, data entities, and external dependencies
Relationship Modeling: Express various logical relationships (calls, depends, implements, flows_to, uses_data, triggers, extends)
Powerful Query Tools: Search nodes, query relationships, and explore graph structure
Language Agnostic: No dependency on specific language parsers, works with any codebase
Progressive Construction: Build knowledge graphs incrementally, starting with core flows
Related MCP server: RAG MCP Server
createProject: Create a new project with metadata
updateProject: Update project information
deleteProject: Remove a project
listProjects: List all available projects
addNode: Add a semantic node to the knowledge graph
Types: concept, flow, module, component, data, external
Supports tags, file associations, and custom metadata
updateNode: Update existing node information
removeNode: Remove a node and optionally cascade delete related edges
linkNodes: Create relationships between nodes
Types: calls, depends, implements, flows_to, uses_data, triggers, extends
Supports relationship strength and descriptions
unlinkNodes: Remove relationships between nodes
queryNode: Get detailed node information with relationships
Supports neighbor traversal with configurable depth
searchNodes: Search nodes by criteria
Filter by type, tags, files, or text content
Configurable result limits
LogicMap is designed for:
Understanding complex codebases and business logic
Documenting system architecture and data flows
Impact analysis before making changes
Onboarding new team members
AI-assisted code comprehension
Cross-team knowledge sharing
Add this to your claude_desktop_config.json:
{
"mcpServers": {
"logicmap": {
"command": "node",
"args": [
"/absolute/path/to/logicmap-mcp-server/dist/index.js"
]
}
}
}Add the configuration to your MCP configuration file. Open the Command Palette (Ctrl + Shift + P or Cmd + Shift + P) and run MCP: Open User Configuration. This will open your user mcp.json file where you can add the server configuration.
User Configuration (Recommended):
{
"mcpServers": {
"logicmap": {
"command": "node",
"args": [
"/absolute/path/to/logicmap-mcp-server/dist/index.js"
]
}
}
}Workspace Configuration:
Alternatively, create .kiro/settings/mcp.json in your workspace:
{
"mcpServers": {
"logicmap": {
"command": "node",
"args": [
"/absolute/path/to/logicmap-mcp-server/dist/index.js"
]
}
}
}For more details about MCP configuration, see the Kiro MCP documentation.
See mcp-config-example.json for a complete configuration example.
# Clone the repository
git clone https://github.com/yourusername/logicmap-mcp-server.git
cd logicmap-mcp-server
# Install dependencies
npm install
# Build the project
npm run buildAfter building, test the server:
# Run tests
npm test
# Check build output
ls dist/# Development mode (watch for changes)
npm run dev
# Run tests
npm test
# Run tests with coverage
npm run test:coverage
# Lint code
npm run lint
# Format code
npm run format
# Clean build output
npm run clean// 1. Create a project
await createProject({
name: "My Web App",
description: "E-commerce platform",
workspacePath: "/path/to/project"
});
// 2. Add semantic nodes
await addNode({
id: "user-auth-flow",
type: "flow",
name: "User Authentication Flow",
description: "Handles user login, token validation, and permission checks",
files: ["src/auth/controller.ts", "src/auth/service.ts"],
tags: ["core", "security"]
});
await addNode({
id: "payment-service",
type: "module",
name: "Payment Service",
description: "Integrates with Stripe and PayPal for payment processing",
files: ["src/payment/processor.ts"],
tags: ["core", "third-party"]
});
// 3. Create relationships
await linkNodes({
from: "user-auth-flow",
to: "payment-service",
type: "depends",
description: "Payment requires authenticated user session"
});
// 4. Query the graph
const result = await queryNode({
id: "user-auth-flow",
includeNeighbors: true,
depth: 2
});
// 5. Search nodes
const searchResults = await searchNodes({
tags: ["core"],
types: ["flow", "module"],
limit: 10
});logicmap-mcp-server/
├── src/
│ ├── index.ts # Entry point
│ ├── types/ # TypeScript type definitions
│ ├── schemas/ # JSON Schema validation
│ ├── services/ # Core business logic
│ │ ├── NodeService.ts # Node CRUD operations
│ │ ├── EdgeService.ts # Relationship management
│ │ └── QueryService.ts # Graph queries
│ ├── storage/ # Data persistence
│ │ └── StorageManager.ts # File-based storage with locking
│ └── mcp/ # MCP protocol implementation
│ └── MCPServerHandler.ts
├── tests/ # Test files
├── dist/ # Build output
└── package.jsonLogicMap stores project data in ~/.logicmap/projects/ as JSON files:
~/.logicmap/
└── projects/
└── {project-id}/
└── graph.json # Complete knowledge graphEach graph file contains:
Project metadata
Node dictionary (for O(1) lookups)
Edge list
Timestamps
Runtime: Node.js >= 18.0.0
Language: TypeScript 5.3+
Protocol: Model Context Protocol (MCP)
Validation: Ajv (JSON Schema)
Storage: JSON files with proper-lockfile
Testing: Vitest + fast-check
# Build TypeScript to JavaScript
npm run build
# Output will be in dist/ directoryContributions are welcome! Please see CONTRIBUTING.md for guidelines.
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.
Add a new node to the knowledge graph
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | 节点唯一标识符（kebab-case） | |
| name | Yes | 节点显示名称 | |
| tags | No | 节点标签 | |
| type | Yes | 节点类型 | |
| files | No | 关联的文件路径 | |
| metadata | No | 自定义元数据 | |
| projectId | No | 项目 ID（可选，默认使用当前项目） | |
| description | Yes | 节点语义描述 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description offers no behavioral details beyond the basic action. It does not disclose what happens on duplicate IDs, whether the operation is reversible, or any side effects. With no annotations to cover safety or behavioral traits, the description leaves all behavioral aspects uncertain.
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 clear sentence with no unnecessary words. It is front-loaded and does not waste the agent's attention, scoring high on conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 8 parameters, nested metadata objects, and no output schema, the one-line description is inadequate. It does not explain the node lifecycle, relationship to projects, or expected outcomes, leaving the agent with too much uncertainty for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all 8 parameters, achieving 100% coverage. The description adds no additional parameter semantics, but the schema already does the heavy lifting, warranting the baseline score of 3.
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 'Add a new node to the knowledge graph' clearly identifies the action (add) and the resource (node in the knowledge graph). It distinguishes the tool from siblings like updateNode and removeNode, which imply modification and deletion respectively.
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 such as updateNode or linkNodes. There are no prerequisites or situational context given, such as whether the graph must already exist or how this relates to projects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new project with metadata
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | 项目名称 | |
| description | Yes | 项目描述 | |
| workspacePath | Yes | 工作区路径 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only states the generic fact that a project is created, but omits important details such as whether the operation is idempotent, whether workspacePath must be pre-existing, what side effects occur (e.g., directory creation), or what the response contains. This is insufficient 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, front-loaded sentence with no filler. It efficiently communicates the core purpose. However, it is slightly under-specified, which prevents a perfect score—it could have included a brief note on usage or outcome without becoming verbose.
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?
Although the schema fully covers the parameters, the tool is a create operation with no annotations and no output schema. The description does not explain the return value, error conditions, or dependencies (e.g., whether workspacePath must be valid). This leaves significant gaps in understanding the tool's full behavior, making it incomplete for an AI agent to invoke with confidence.
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 input schema provides descriptions for all three parameters (100% coverage), so the baseline is 3. The description adds no additional meaning beyond what the schema already specifies—it merely says 'with metadata' without elaborating on the parameters. The schema itself is clear enough, so the tool description does not need to compensate.
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 'Create a new project with metadata' clearly states the action (create) and the resource (project), distinguishing it from sibling tools like updateProject, deleteProject, and listProjects. The verb-resource pair is specific and unambiguous.
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. It does not mention that it is the creation counterpart to updateProject, nor does it offer any context about prerequisites (e.g., workspacePath must exist) or situations where a different tool might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a project
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | 要删除的项目 ID（kebab-case） |
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 merely states 'Delete a project' without mentioning reversibility, cascade effects on related nodes/links, permission requirements, or any confirmation steps. For a destructive operation, this is a significant transparency gap.
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 concise sentence with no fluff, but it essentially restates the tool name without adding useful information. It is appropriately short, but not effective enough to earn a higher score because it lacks substance and is essentially a tautology.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations and no output schema, the description is incomplete. It does not explain what happens on success, whether the operation is idempotent, or how associated data (e.g., nodes linked to the project) is affected. The simplicity of the parameter schema does not compensate for this missing behavioral 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?
The input schema covers 100% of the single parameter with a description stating the project ID should be kebab-case and provides a pattern, so schema coverage is high. The tool description itself does not add any parameter-level information beyond what the schema already provides, matching the baseline of 3.
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 'Delete a project' clearly identifies the action (delete) and the resource (project), distinguishing it from sibling tools like createProject and updateProject. However, it lacks any additional scope or specific behavior (e.g., permanent deletion) that would fully contrast it with alternatives, so it doesn't reach a perfect 5.
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 such as updateProject or removeNode. There are no stated prerequisites, side effects, or indications of whether this should be used for soft-delete or hard-delete scenarios, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a relationship between two nodes
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | 目标节点 ID | |
| from | Yes | 源节点 ID | |
| type | Yes | 关系类型 | |
| metadata | No | 自定义元数据 | |
| strength | No | 关系强度 (0-1) | |
| projectId | No | 项目 ID（可选，默认使用当前项目） | |
| description | No | 关系描述 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose side effects, but it only states the basic action. It does not mention whether the relationship is idempotent, what happens if the relationship already exists, how metadata/strength defaults behave, or what response is returned. For a mutation tool, this is a significant gap.
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 concise sentence with no filler, front-loading the core purpose. However, it is minimal and does not fully exploit the space to aid the agent, yet it remains 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?
For a tool with 7 parameters, nested objects, and no output schema, the description is severely under-specified. It provides no information about return values, error cases, or behavioral nuances, making it incomplete for an agent to invoke correctly in varied scenarios.
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 covers all 7 parameters with descriptions (100% coverage), so the baseline is 3. The tool description adds no additional meaning beyond the schema; parameters like 'from', 'to', 'type', and optional ones are not elaborated in the description.
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 states a specific verb ('Create') and resource ('relationship between two nodes'), distinguishing it from sibling tools like addNode (creates a node) and unlinkNodes (removes a relationship). However, it does not enumerate the relationship types or mention that it links existing nodes, leaving some ambiguity.
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 such as unlinkNodes or addNode. There is no mention of prerequisites (e.g., nodes must exist) or when creating a relationship is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all projects
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'List all projects' implies a read-only operation but does not report return format, pagination, or any side effects. It lacks depth beyond the literal meaning.
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 concise sentence with no wasted words. It is appropriately front-loaded and easy to parse.
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 (no parameters, no annotations, no output schema), the description is mostly sufficient. It names the action and resource clearly, though it omits return value details which could be inferred from a list operation.
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 input schema has zero parameters, so there is nothing to document. The description's 'all' adds meaning by indicating the scope is unfiltered, which is useful context. This meets the baseline for zero params.
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 ('List') and resource ('projects'), clearly indicating the action. It distinguishes from sibling tools like createProject, updateProject, and deleteProject, which have different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention exclusions or specific use cases, leaving the agent to infer from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query a node and its relationships
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | 要查询的节点 ID | |
| depth | No | 查询深度 | |
| projectId | No | 项目 ID（可选，默认使用当前项目） | |
| includeNeighbors | No | 是否包含邻居节点 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. 'Query' implies a read-only operation, and 'its relationships' hints at relationship traversal, but there is no explicit mention of safety, side effects, or limits. The description adds minimal behavioral context beyond the verb itself.
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 filler words, front-loading the verb and resource. It is highly concise, though it may be under-specified; conciseness itself is exemplary.
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 no output schema, so the description should explain what the query returns. It only states 'Query a node and its relationships' without detailing return format, depth behavior, or how relationships are represented. With no annotations and no output schema, the description is incomplete for a tool with 4 parameters and relationship traversal.
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 all four parameters documented in the input schema. The description itself adds no parameter-specific meaning, but the schema already provides descriptions for id, depth, projectId, and includeNeighbors, so the description is not required to compensate.
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 'Query' and specifies the resource 'a node and its relationships,' clearly stating the tool's function. However, it does not explicitly distinguish from sibling tool 'searchNodes' or mention that it queries by ID, so it is clear but lacks sibling differentiation.
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 such as 'searchNodes' or 'listProjects'. No context or exclusions are given, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a node from the knowledge graph
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | 要删除的节点 ID | |
| cascade | No | 是否级联删除相关的边 | |
| projectId | No | 项目 ID（可选，默认使用当前项目） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only says 'remove' without explaining cascade behavior, irreversibility, or effects on connected edges. The cascade parameter suggests important behavior that is not disclosed in the text.
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 sentence that states the core function without verbosity; it is front-loaded and earns its place.
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 description is minimal for a destructive operation with no annotations or output schema; it omits cascade behavior, permanence, and any return value information, leaving agents to infer these from the schema alone.
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 descriptions cover 100% of parameters (id, cascade, projectId), so the description need not repeat them; baseline 3 is appropriate. The tool description adds no additional semantic context 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 uses the specific verb 'Remove' and identifies the resource as 'a node from the knowledge graph', clearly distinguishing it from project tools like deleteProject and node modification tools like updateNode.
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 about when to use this tool versus alternatives such as unlinkNodes for edges or deleteProject for projects, and 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.
Search nodes by criteria
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | 标签过滤 | |
| files | No | 文件路径过滤 | |
| limit | No | 结果数量限制 | |
| query | No | 文本搜索（名称、描述） | |
| types | No | 节点类型过滤 | |
| projectId | No | 项目 ID（可选，默认使用当前项目） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries full burden for behavioral disclosure. It only states 'search nodes by criteria' without revealing whether the operation is read-only, how results are returned, pagination behavior, or filtering semantics. This leaves critical behavioral aspects unaddressed.
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 states the core purpose. It is concise, but the brevity sacrifices substance—key context about usage and behavior is omitted, making it somewhat under-specified rather than 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 there are 6 parameters, no output schema, and no annotations, the description is incomplete. It does not explain return values, result format, or any behavioral constraints. The agent would need to look elsewhere for essential context, making this insufficient for a tool of this complexity.
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 all parameters have individual descriptions. The tool description adds no additional meaning beyond what is already in the schema, which is acceptable given the high coverage. 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 'Search nodes by criteria' clearly identifies a search operation on nodes with criteria-based filtering. It uses a specific verb and resource, but 'criteria' is vague and it does not differentiate from the sibling tool queryNode, which likely serves a similar purpose.
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 usage guidance is provided. The description does not state when to use this tool versus alternatives like queryNode or listProjects, nor does it mention any prerequisites or exclusions. The agent is left to infer the intended use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a relationship between two nodes
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | 目标节点 ID | |
| from | Yes | 源节点 ID | |
| type | No | 关系类型（可选，不指定则删除所有类型的边） | |
| projectId | No | 项目 ID（可选，默认使用当前项目） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for disclosing behavioral traits. It only states the action without revealing side effects, irreversibility, error handling if the relationship or nodes don't exist, or whether it affects other data. This is insufficient for a mutating 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 direct sentence, front-loaded with the primary action, and contains zero redundant words. It efficiently states the purpose without wasting tokens.
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?
While parameters are fully documented in the schema, the description lacks essential context for a mutating tool such as what happens when no relationship exists, whether deletion is permanent, or what the response is. No annotations or output schema compensate for this gap.
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%, including details like optional 'type' meaning to delete all edge types if unspecified. The description adds no additional parameter context, so it does not exceed the baseline provided by 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 uses a specific verb ('Remove') and identifies the resource ('relationship between two nodes'), clearly distinguishing this from sibling tools like linkNodes (create relationship) and removeNode (delete a node). It leaves no ambiguity about what the tool does.
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 the tool is used to remove relationships, but provides no explicit guidance on when to use it instead of alternatives, nor any prerequisites or exclusions. It relies on the agent's common sense about relationships versus nodes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing node in the knowledge graph
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | 要更新的节点 ID | |
| name | No | 新的节点名称 | |
| tags | No | 新的标签列表 | |
| files | No | 新的文件路径列表 | |
| metadata | No | 新的元数据 | |
| projectId | No | 项目 ID（可选，默认使用当前项目） | |
| description | No | 新的节点描述 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits. It merely states 'update' without explaining whether updates are partial or full replacement, how null fields are handled, what happens if the node doesn't exist, or any permission requirements. This is a significant gap for a mutation tool with 7 parameters.
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, concise sentence that front-loads the core purpose. It contains no filler or redundant information. However, it is so brief that it misses opportunities to add behavioral context, so it doesn't fully earn a 5 for structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an update tool with 7 parameters, no output schema, and no annotations, the description is incomplete. It fails to explain update semantics, parameter interactions, or error cases. The schema provides field names but not the behavioral context needed to 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?
The input schema provides 100% coverage of parameter descriptions, so the baseline is 3. The tool description adds no additional parameter semantics beyond the schema. Since every parameter is already documented with descriptions (e.g., 'new node name', 'new tags list'), the description does not need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: updating an existing node in the knowledge graph. The verb 'update' and resource 'existing node' are specific and differentiate it from sibling tools like addNode and removeNode. However, it lacks detail on what aspects of the node can be updated, so it doesn't fully distinguish from potential variants.
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. It does not mention that addNode is for creating nodes, nor does it discuss any prerequisites or contraindications. The only hint is the tool name itself, which is insufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update project metadata
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | 项目 ID（kebab-case） | |
| name | No | 新的项目名称 | |
| description | No | 新的项目描述 | |
| workspacePath | No | 新的工作区路径 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose mutation side effects, partial update behavior, or error responses. 'Update project metadata' only signals a write operation and fails to clarify whether only provided fields are changed or what happens if the project ID is invalid.
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 gets straight to the point. It is concise and free of fluff, though it is so brief that it omits potentially useful context, which keeps it from being a 5.
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 4 parameters, no output schema, and no annotations. The description is too sparse to be complete: it does not explain update semantics (partial vs full), required permissions, return values, or failure modes, leaving an agent with insufficient context for reliable invocation.
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 input schema has 100% coverage for parameter descriptions, so the baseline is 3. The description itself does not add semantic detail beyond the schema, merely calling everything 'metadata' without explaining individual fields.
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 indicates an update operation targeting project metadata, distinguishing it from createProject, deleteProject, and updateNode. However, it does not enumerate the specific metadata fields, leaving the scope somewhat generic but still recognizable.
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. There is no mention of using createProject for new projects, updateNode for node-level changes, or any prerequisites or context that would help an agent choose this tool appropriately.
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.
v0.1.0addNodecreateProjectdeleteProjectlinkNodeslistProjectsqueryNoderemoveNodesearchNodesunlinkNodesupdateNodeupdateProjectEach tool targets a distinct resource and action: project lifecycle tools (create, update, delete, list) are clearly separate from knowledge graph operations (add, update, remove, link, unlink, query, search). No two tools appear to overlap in purpose.
All tool names follow a consistent verbNoun camelCase pattern: createProject, updateProject, deleteProject, listProjects, addNode, updateNode, removeNode, linkNodes, unlinkNodes, queryNode, searchNodes. The pattern is uniform and predictable.
With 11 tools, the set is well-scoped for a server managing both projects and a knowledge graph. Each tool serves a distinct purpose and the count feels appropriate, not bloated or sparse.
The surface provides full CRUD coverage for projects (create, update, delete, list) and comprehensive graph operations for nodes (add, update, remove, link, unlink, query, search). The lifecycle is complete with no obvious dead ends or missing core functionality.
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.
Deterministic context layer for your codebase: change impact, blast radius, answers with receipts.
Give your AI agent a persistent map of your project's structure, dependencies, and bugs.
AI knowledge graph for architecture, portfolio, and digital strategy management.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Sim-xia/Logic-map-MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
