Supports Markdown as a resource type for knowledge graph nodes, enabling storage and management of Markdown documents within the knowledge graph structure.
Supports SVG as a resource type for knowledge graph nodes, enabling storage and management of SVG visualizations and graphics within the knowledge graph structure.
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., "@Knowledge Graph MCP Server create a timeline graph for our project milestones"
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.
A Model Context Protocol (MCP) service for creating, managing, analyzing, and visualizing knowledge graphs. This service fully complies with the MCP standard and seamlessly integrates with MCP-compatible AI assistants (such as Claude).
Multiple Graph Types: Support for topology structures, timelines, changelogs, requirement documents, knowledge bases, ontologies, and more
Complete Error Handling: Clear error messages and handling suggestions for common issues
Resource Management: Support for SVG and Markdown resource association and management
Version Status: Support for multiple status management including draft, published, and archived
Related MCP server: GID MCP Server
To install knowledge-graph-mcp for Claude Desktop automatically via Smithery:
npx -y @smithery/cli install @aiuluna/knowledge-graph-mcp --client claudeNode.js >= 16.0.0
pnpm >= 7.0.0
Create a directory to store knowledge graph data, for example:
mkdir ~/knowledge_graphAdd the following configuration to your Cursor config file:
{
"mcpServers": {
"knowledge-graph": {
"command": "npx",
"args": [
"-y",
"@aiuluna/knowledge-graph-mcp"
],
"env": {
"KNOWLEDGE_GRAPH_DIR": "/path/to/your/knowledge_graph/dir"
}
}
}
}Note:
Replace KNOWLEDGE_GRAPH_DIR with your actual knowledge graph storage directory path
You can specify a particular version number, such as @0.0.1
Add the following configuration to claude_desktop_config.json:
{
"mcpServers": {
"knowledge-graph": {
"command": "npx",
"args": [
"-y",
"@aiuluna/knowledge-graph-mcp"
],
"env": {
"KNOWLEDGE_GRAPH_DIR": "/path/to/your/knowledge_graph/dir"
}
}
}
}Prompt files are located in the /src/rules/prompts directory. Please copy these files to your Cursor and add them as default rules for Agent mode (refer to Cursor Rules Configuration):
.cursor/
└── rules/
└── graph-query.mdc # Knowledge graph query prompt fileWhen using Agent mode in Cursor, you can trigger knowledge graph queries by:
Type /ck command in the editor
The Agent will automatically invoke the prompt defined in @graph-query.mdc
The prompt will:
Analyze current context
Query relevant knowledge graph nodes
Generate summary content
Integrate query results into the conversation
The project also includes prompts for generating hand-drawn style graphics and Markdown documents as knowledge graph resources. Since Cursor doesn't support the MCP standard for prompts, this project uses tools to obtain these rules. You can also integrate them into Cursor's rules like above and modify them to your desired style for use in Cursor Agent mode.
create_graph
Create a new knowledge graph
Parameters:
name (string): Graph name
description (string, optional): Graph description
type (string): Graph type (topology/timeline/changelog/requirement/kb/ontology)
list_graphs
List all knowledge graphs
Parameters:
status (string, optional): Filter by status (draft/published/archived)
type (string, optional): Filter by type
publish_graph
Publish a knowledge graph
Parameters:
graphId (string): Graph ID
add_node
Add a node to the graph
Parameters:
graphId (string): Graph ID
type (string): Node type
name (string): Node name
description (string, optional): Node description
filePath (string, optional): Associated file path
metadata (object, optional): Node metadata
update_node
Update node information
Parameters:
graphId (string): Graph ID
nodeId (string): Node ID
name (string, optional): New node name
description (string, optional): New node description
filePath (string, optional): New file path
metadata (object, optional): New metadata
delete_node
Delete a node
Parameters:
graphId (string): Graph ID
nodeId (string): Node ID
confirmDelete (boolean): Delete confirmation
get_node_details
Get detailed node information
Parameters:
graphId (string): Graph ID
nodeId (string): Node ID
add_edge
Add an edge
Parameters:
graphId (string): Graph ID
type (string): Edge type
sourceId (string): Source node ID
targetId (string): Target node ID
label (string, optional): Edge label
weight (number, optional): Edge weight
metadata (object, optional): Edge metadata
update_edge
Update edge information
Parameters:
graphId (string): Graph ID
edgeId (string): Edge ID
label (string, optional): New edge label
weight (number, optional): New edge weight
metadata (object, optional): New metadata
delete_edge
Delete an edge
Parameters:
graphId (string): Graph ID
edgeId (string): Edge ID
confirmDelete (boolean): Delete confirmation
get_creation_guidelines
Get resource creation guidelines
Parameters:
type (string): Guideline type (svg/markdown/all)
save_resource
Save a resource
Parameters:
graphId (string): Graph ID
nodeId (string, optional): Associated node ID
resourceType (string): Resource type (svg/markdown)
title (string): Resource title
description (string, optional): Resource description
content (string): Resource content
update_resource
Update resource information
Parameters:
graphId (string): Graph ID
resourceId (string): Resource ID
name (string, optional): New resource name
title (string, optional): New resource title
description (string, optional): New resource description
delete_resource
Delete a resource
Parameters:
graphId (string): Graph ID
resourceId (string): Resource ID
confirmDelete (boolean): Delete confirmation
unlink_resource
Unlink a resource from a node
Parameters:
graphId (string): Graph ID
nodeId (string): Node ID
resourceId (string): Resource ID
# Install dependencies
pnpm install
# Development mode
pnpm dev
# Build project
pnpm build
# Run tests
pnpm test
# Code check
pnpm lintThe service uses a standard error handling mechanism. All errors are logged to the md/error_log.txt file, including timestamps, error messages, and stack traces.
This project is licensed under the MIT License - see the LICENSE file for details.
Add edges in the knowledge graph, connecting two nodes to build a relationship network. Edges represent relationship types between nodes, such as dependencies, containment, associations, etc. Prerequisites:
Must first create a graph (using create_graph)
Source and target nodes must already exist
Edge type must match the graph type
Usage recommendations:
First use list_graphs to get graph and node information
Confirm both source and target nodes exist and their types match
Choose appropriate edge type based on graph type
Add meaningful labels to edges to help understand relationships
If relationships have varying strengths, use the weight parameter
Return data:
data: Newly created edge information
id: Edge ID
type: Edge type
sourceId: Source node ID
targetId: Target node ID
label: Edge label
weight: Edge weight
| Name | Required | Description | Default |
|---|---|---|---|
| graphId | Yes | ||
| type | Yes | Edge type. Topology diagram:depends_on/imports/extends/implements/calls/references/contains/associated_with, Timeline graph:precedes/leads_to/created_by/modified_by, Change log:precedes/transforms_to/created_by/modified_by/part_of, Requirements document:implements_req/depends_on/part_of/created_by/modified_by | |
| sourceId | Yes | ||
| targetId | Yes | ||
| label | No | ||
| weight | No |
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 effectively describes that this is a creation/mutation operation (implied by 'Add edges' and 'Newly created edge information'), specifies prerequisites that constrain usage, and provides context about relationship types and edge properties. However, it doesn't mention potential error conditions, rate limits, or authentication requirements that would be helpful 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 well-structured with clear sections (purpose, prerequisites, usage recommendations, return data) and every sentence adds value. It's appropriately sized for a 6-parameter mutation tool with complex prerequisites, providing necessary information without redundancy. The front-loaded purpose statement immediately communicates the tool's function.
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 mutation tool with 6 parameters, no annotations, and no output schema, the description provides substantial context including prerequisites, usage guidance, and detailed return format. It covers the essential information needed to use the tool correctly. The only minor gap is the lack of explicit error handling information, but overall it's quite complete given the 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?
With only 17% schema description coverage, the description compensates significantly by explaining parameter semantics. It clarifies that sourceId and targetId must refer to existing nodes, edge type must match graph type, labels should be meaningful, and weight represents relationship strength. The description adds substantial value beyond the minimal schema documentation, especially for the type parameter where it provides context about how edge types relate to different graph types.
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: 'Add edges in the knowledge graph, connecting two nodes to build a relationship network.' It specifies the verb ('Add edges'), resource ('knowledge graph'), and distinguishes it from siblings like add_node (which adds nodes rather than edges) and update_edge (which modifies existing edges rather than creating new ones).
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 explicit usage recommendations including prerequisites ('Must first create a graph', 'Source and target nodes must already exist') and specific guidance on when to use ('First use list_graphs to get graph and node information', 'Confirm both source and target nodes exist'). It also distinguishes from alternatives by specifying edge type constraints and recommending meaningful labels and weight parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a node to the knowledge graph. Nodes are the basic units of the graph, and different types of graphs support different types of nodes. Use cases:
Create component or module nodes in topology graphs
Add event or decision nodes in timeline graphs
Create requirement or feature nodes in requirement documents
Build concept hierarchies in knowledge bases
Usage recommendations:
First create the graph using create_graph
Select the appropriate node type based on graph type
Provide meaningful names and descriptions
Link related files when applicable
Add metadata for additional structured information
Return data:
data: Created node information
id: Node ID
type: Node type
name: Node name
description: Node description
createdAt: Creation time
| Name | Required | Description | Default |
|---|---|---|---|
| graphId | Yes | ||
| type | Yes | Node type. Topology graph:component/module/service/data/api/concept/resource, Timeline graph:event/decision/iteration/person, Changelog:change/feature/component/iteration/person, Requirement doc:requirement/feature/component/iteration/person/decision | |
| name | Yes | ||
| description | No | ||
| filePath | No | ||
| metadata | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It clearly indicates this is a creation/mutation operation ('Add a node'), describes the return data structure, and provides context about different graph types. However, it doesn't mention permissions, error conditions, or idempotency behavior that would be helpful 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 well-structured with clear sections (purpose, use cases, recommendations, return data) and each sentence adds value. It could be slightly more concise by integrating some of the use cases into the initial statement, but overall it's efficiently organized.
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 6-parameter mutation tool with no annotations and no output schema, the description provides substantial context: clear purpose, usage guidelines, parameter guidance, and detailed return format. The main gap is lack of error handling or side effect information, but otherwise it's quite comprehensive given the constraints.
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 only 17%, but the description compensates well. It explains the relationship between node types and graph types (mapping to the 'type' enum), provides context for 'filePath' ('Link related files when applicable'), and explains 'metadata' purpose. However, it doesn't explicitly mention 'graphId' or 'name' parameters.
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 a node') and resource ('to the knowledge graph'), with specific examples of different node types for various graph contexts. It distinguishes from siblings like 'create_graph' (which creates the graph itself) and 'update_node' (which modifies existing nodes).
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 explicit usage recommendations including prerequisites ('First create the graph using create_graph'), selection criteria ('Select the appropriate node type based on graph type'), and best practices. It also implicitly distinguishes from alternatives by focusing on node creation rather than modification or deletion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new knowledge graph. Supports multiple graph types such as topology, timeline, changelog, requirement documentation, etc. Design guidelines for each graph type:
topology: Used to represent dependencies between system components and modules. Recommended to first create main module nodes, then add component nodes, and finally represent relationships through edges like calls, dependencies, and containment
timeline: Used to record important project events and decisions. Recommended to add event nodes in chronological order and link related personnel and decisions
changelog: Used to track change history of features and components. Recommended to create nodes for each significant change, marking change types and impact scope
requirement: Used for requirement management and tracking. Recommended to first create high-level requirements, then break down into specific features, and finally link to responsible persons and iterations
knowledge_base: Used to build domain knowledge systems. Recommended to start from core concepts and gradually expand related concepts and relationships
ontology: Used for formal representation of domain concepts and relationships, suitable for building standardized knowledge models
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| description | No | ||
| type | No | Graph type. topology:Component topology diagram, timeline:Timeline graph, changelog:Change log graph, requirement:Requirement documentation graph, knowledge_base:Knowledge base graph, ontology:Ontology graph |
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. While it describes graph types and design guidelines, it does not disclose critical behavioral traits such as whether creation is idempotent, what permissions are required, how errors are handled, or what the response looks like. For a creation tool with zero annotation coverage, this is a significant gap in transparency.
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 appropriately front-loaded with the core purpose, but it becomes lengthy with detailed design guidelines for six graph types. Some sentences, like the repetitive 'Recommended to...' patterns, could be condensed. While informative, the structure could be more concise without losing essential context.
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 creating knowledge graphs with multiple types, no annotations, and no output schema, the description is partially complete. It covers graph types and design guidelines well but lacks details on behavioral aspects, error handling, and response format. For a tool with 3 parameters and no structured safety hints, more comprehensive context would be beneficial.
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 33% (only the 'type' parameter has a description). The description compensates by elaborating on the 'type' parameter with detailed guidelines for each graph type, adding substantial meaning beyond the schema's enum values. However, it does not provide semantics for 'name' or 'description' parameters, leaving them partially undocumented.
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 explicitly states the tool's purpose: 'Create a new knowledge graph.' It distinguishes this tool from siblings like add_node, add_edge, or list_graphs by focusing on initial graph creation rather than modification or querying. The description provides specific details about supported graph types, making the purpose clear and distinct.
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 clear context for when to use this tool by detailing six graph types and their recommended design guidelines. However, it does not explicitly state when not to use this tool or mention alternatives like update_resource or save_resource for modifying existing graphs. The guidelines are helpful but lack explicit exclusions or comparisons to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete edges from the knowledge graph. This tool must be used in conjunction with list_graphs and get_node_details tools, and the operation cannot be undone. Use cases:
Delete incorrectly created relationships
Update relationship structure between nodes
Clean up redundant relationships when restructuring the graph
Usage recommendations:
First call list_graphs to get target graph information
Use get_node_details to get edge details
Confirm deletion won't break important relationship structures
Set confirmDelete to true to confirm deletion
Important notes:
Deleting edges won't affect related nodes
Need to call get_node_details again to view updated relationships
Return data:
data: Deletion result
id: Deleted edge ID
deletedAt: Deletion time
| Name | Required | Description | Default |
|---|---|---|---|
| graphId | Yes | Graph ID, must be obtained from list_graphs return data | |
| edgeId | Yes | Edge ID, must be obtained from relationships array in get_node_details | |
| confirmDelete | Yes | Confirm deletion, must be set to true, this is a safety measure to prevent accidental deletion |
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 and does so comprehensively. It explicitly states the operation 'cannot be undone,' clarifies that 'deleting edges won't affect related nodes,' explains the need to call get_node_details again to view updated relationships, and describes the return data format including specific fields like id and deletedAt.
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 well-structured with clear sections (Use cases, Usage recommendations, Important notes, Return data) and front-loads the core purpose. While comprehensive, some sentences could be more concise, such as the detailed 4-step usage recommendations that partially repeat schema information. Overall, it's appropriately sized for a destructive operation.
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 provides exceptional completeness. It covers irreversible nature, safety measures (confirmDelete), prerequisites (list_graphs, get_node_details), effects on the system, return data format, and specific use cases. This fully compensates for the lack of structured metadata.
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?
With 100% schema description coverage, the baseline is 3. The description doesn't add significant parameter semantics beyond what's already in the schema descriptions, though it does reinforce the confirmDelete safety measure in the usage recommendations. The schema already documents that graphId must come from list_graphs and edgeId from get_node_details relationships.
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 specific action ('Delete edges') and resource ('from the knowledge graph'), distinguishing it from sibling tools like delete_node, delete_resource, and update_edge. It provides a precise verb+resource combination that leaves no ambiguity about the tool's function.
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 explicit guidance on when to use this tool versus alternatives, specifying it 'must be used in conjunction with list_graphs and get_node_details tools' and listing three specific use cases. It also includes detailed usage recommendations with a 4-step process, making it clear how this tool fits into the workflow compared to other graph manipulation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete nodes from the knowledge graph. This tool must be used in conjunction with list_graphs tool, and the operation cannot be undone. Use cases:
Delete incorrectly created nodes
Delete nodes that are no longer needed
Delete redundant nodes when restructuring the graph
Usage recommendations:
First call list_graphs to get target graph and node information
Use get_node_details to check node's associated resources and relationships
Confirm deletion won't affect other important nodes
Set confirmDelete to true to confirm deletion
Recommended to backup important data before deletion
Important notes:
Deleting a node will also delete all edges related to that node
If the node has associated resources, they won't be deleted but will be unlinked
Return data:
data: Deletion result
id: Deleted node ID
name: Node name
type: Node type
deletedAt: Deletion time
| Name | Required | Description | Default |
|---|---|---|---|
| graphId | Yes | Graph ID, must be obtained from list_graphs return data | |
| nodeId | Yes | Node ID, must be obtained from nodes array in list_graphs | |
| confirmDelete | Yes | Confirm deletion, must be set to true, this is a safety measure to prevent accidental deletion |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so comprehensively. It discloses critical behavioral traits: the operation is irreversible, it deletes related edges, it unlinks but doesn't delete associated resources, requires confirmation parameter, and has safety recommendations. This provides rich behavioral context beyond basic parameter documentation.
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 well-structured with clear sections (Use cases, Usage recommendations, Important notes, Return data) and front-loads the core purpose. While comprehensive, some sentences could be more concise, and the return data section might be better placed elsewhere since there's no output schema.
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 mutation tool with no annotations and no output schema, the description provides exceptional completeness. It covers purpose, prerequisites, use cases, behavioral consequences, safety measures, parameter context, and even documents the return format. This gives the agent everything needed to use this tool correctly and safely.
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?
With 100% schema description coverage, the baseline is 3. The description adds meaningful context by explaining why graphId and nodeId must come from list_graphs, emphasizing confirmDelete as a safety measure, and providing the rationale for parameter usage in the usage recommendations section. This adds value beyond the schema's technical documentation.
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 specific action ('Delete nodes') and resource ('from the knowledge graph'), distinguishing it from sibling tools like delete_edge, delete_resource, and unlink_resource. It provides a focused purpose that goes beyond just restating the tool name.
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 explicit guidance on when to use this tool (three specific use cases) and detailed prerequisites (must be used with list_graphs, get_node_details for checking). It also clearly distinguishes this from other deletion tools by specifying it deletes nodes specifically, not edges or resources.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete resources from the knowledge graph. This tool must be used in conjunction with list_graphs and get_node_details tools, and the operation cannot be undone. Use cases:
Delete outdated resource files
Clean up unnecessary documents
Remove incorrectly created resources
Usage recommendations:
First call list_graphs to get target graph information
Use get_node_details to confirm resource associations
Confirm deletion won't affect other nodes
Set confirmDelete to true to confirm deletion
Recommended to backup important resources before deletion
Important notes:
Deleting a resource will also delete the physical file
Will automatically unlink from all nodes
This operation cannot be recovered
Return data:
data: Deletion result
id: Deleted resource ID
type: Resource type
deletedAt: Deletion time
| Name | Required | Description | Default |
|---|---|---|---|
| graphId | Yes | Graph ID, must be obtained from list_graphs return data | |
| resourceId | Yes | Resource ID, must be obtained from resources array in get_node_details | |
| confirmDelete | Yes | Confirm deletion, must be set to true, this is a safety measure to prevent accidental deletion |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and excels at disclosing critical behavioral traits: irreversible nature ('cannot be undone', 'cannot be recovered'), destructive side effects ('will also delete the physical file', 'automatically unlink from all nodes'), safety mechanisms (confirmDelete requirement), and workflow dependencies. It provides comprehensive behavioral context beyond basic function.
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 well-structured with clear sections (Use cases, Usage recommendations, Important notes, Return data) and front-loaded core functionality. While slightly verbose, every sentence earns its place by providing essential guidance for a destructive operation. The structure enhances readability without unnecessary repetition.
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 provides exceptional completeness: it covers purpose, prerequisites, irreversible consequences, safety mechanisms, use cases, step-by-step workflow, side effects, and return format. It addresses all critical aspects needed for safe and correct tool invocation in 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?
With 100% schema description coverage, the baseline is 3, but the description adds significant value by explaining parameter dependencies and semantics: graphId must come from list_graphs, resourceId must come from get_node_details resources array, and confirmDelete is a safety measure. It provides practical context beyond the schema's technical descriptions.
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 specific action ('Delete resources') and target ('from the knowledge graph'), distinguishing it from sibling tools like delete_node, delete_edge, and unlink_resource which target different graph elements. It provides a precise verb+resource combination that leaves no ambiguity about the tool's function.
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 explicit, step-by-step usage recommendations including prerequisite tools (list_graphs, get_node_details), confirmation requirements, and backup advice. It clearly distinguishes when to use this tool versus alternatives by specifying the target (resources) and workflow dependencies, with no misleading guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get creation guidelines and standards for SVG graphics and Markdown documents. This tool is a prerequisite for the save_resource tool and must be called before creating and saving any resources. Use cases:
Get drawing standards before creating SVG visualizations
Get format requirements before creating Markdown documents
Get complete guidelines before batch resource creation
Usage recommendations:
Call this tool before starting any resource creation
Carefully read and follow the naming rules and directory structure
Create resources according to guidelines, then use save_resource tool
Recommended to save guidelines for team reference
Return data:
data: Guidelines content
guidelines: Guidelines text content
File naming rules
Directory structure requirements
Format specifications
Style guide
type: Guidelines type (svg/markdown/all)
version: Guidelines version
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | Guidelines type: - svg: SVG graphics creation guidelines, including drawing style, naming rules, etc. - markdown: Markdown document guidelines, including format requirements, directory structure, etc. - all: Get all guidelines (recommended) |
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 effectively describes the tool's role as a prerequisite for 'save_resource', indicating it's a read-only operation that fetches guidelines before creation actions. It mentions the return data structure and content, which helps the agent understand what to expect. However, it doesn't address potential limitations like rate limits, authentication needs, or error conditions.
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 structured with clear sections (Use cases, Usage recommendations, Return data), which aids readability. However, it includes some redundancy (e.g., repeating 'Get creation guidelines' in different forms) and could be more front-loaded; the core purpose is stated upfront, but the detailed sections add length without always adding proportional value. Some sentences like 'Recommended to save guidelines for team reference' are less critical.
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 low complexity (1 parameter, no output schema, no annotations), the description is quite complete. It explains the purpose, usage context, return data structure, and ties it to sibling tools. The absence of an output schema is compensated by detailing the return format. However, it could briefly mention error handling or confirm it's a safe read operation, though the 'prerequisite' context implies non-destructive behavior.
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% description coverage, with the single parameter 'type' fully documented in the schema (including enum values and descriptions). The description doesn't add any parameter-specific information beyond what's in the schema, so it meets the baseline of 3. It does provide context about when to use specific types (e.g., 'all: Get all guidelines (recommended)'), but this is implied rather than explicit in the description text.
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: 'Get creation guidelines and standards for SVG graphics and Markdown documents.' It specifies the resource (guidelines) and the target domains (SVG graphics, Markdown documents). However, it doesn't explicitly differentiate from sibling tools like 'get_node_details' or 'list_graphs' which might also provide informational content, though those appear to be graph-related rather than guidelines-focused.
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 explicit usage guidance: 'This tool is a prerequisite for the save_resource tool and must be called before creating and saving any resources.' It lists specific use cases (e.g., before creating SVG visualizations, before creating Markdown documents) and gives clear recommendations (e.g., 'Call this tool before starting any resource creation'). It also mentions an alternative/successor tool ('save_resource') for the next step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific node in the graph. This tool must be used in conjunction with the list_graphs tool, as the nodeId must be obtained from the list_graphs response. Use cases:
View complete node attributes
Check associated resources (SVG/Markdown)
Analyze node relationships with others
Check current state before modifying a node
Usage recommendations:
First call list_graphs to get the node list of the target graph
Get the required nodeId from the returned nodes array
Use the obtained graphId and nodeId to call this tool
Check the returned relationship data to determine if further action is needed
Return data:
data: Node details
id: Node ID
name: Node name
type: Node type
description: Node description
filePath: Associated file path
metadata: Node metadata
resources: Associated resource list
id: Resource ID
type: Resource type (svg/markdown)
title: Resource title
relationships: Relationship list
id: Edge ID
type: Edge type
targetNode: Target node information
| Name | Required | Description | Default |
|---|---|---|---|
| graphId | Yes | Graph ID, must be obtained from list_graphs response | |
| nodeId | Yes | Node ID, must be obtained from the nodes array in list_graphs response |
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 effectively describes the tool's dependency on list_graphs, outlines four specific use cases, and details the return data structure. However, it doesn't mention potential error conditions, rate limits, or authentication requirements.
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 well-structured with clear sections (Use cases, Usage recommendations, Return data) and front-loads the core purpose. While comprehensive, some redundancy exists between the initial statement and later sections, preventing a perfect score.
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 complexity (dependency on another tool, detailed return structure) and absence of both annotations and output schema, the description provides complete contextual coverage. It explains prerequisites, use cases, usage workflow, and detailed return format, compensating for the lack of structured metadata.
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 description coverage is 100%, so the schema already documents both parameters thoroughly. The description reinforces that parameters 'must be obtained from list_graphs response' but doesn't add significant semantic value beyond what's in the schema descriptions. This meets the baseline expectation for high schema 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 tool's purpose with a specific verb ('Get detailed information') and resource ('about a specific node in the graph'). It distinguishes this read operation from sibling tools like update_node, delete_node, and add_node by focusing on retrieval rather than modification.
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 explicit usage recommendations with step-by-step instructions, including when to use this tool ('First call list_graphs to get the node list') and how to obtain required parameters. It clearly positions this tool as dependent on list_graphs for parameter acquisition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all knowledge graphs with support for filtering by status and type. This is the main tool for getting information about existing graphs and an important path for obtaining node IDs. Use cases:
View all available graphs and their basic information
Get the node list of a specific graph for subsequent edge addition or node detail queries
Filter graphs by status, such as viewing all drafts or published graphs
Filter graphs by type, such as viewing only topology or timeline graphs
Usage recommendations:
First call this tool to get the graph list and node information
Get the required graph ID and node ID from the returned data
Use these IDs to call other tools (like add_edge, get_node_details)
Recommended to use this tool to confirm the target graph's status before performing any node or edge operations
Return data:
data: List of graphs, each graph contains:
id: Graph ID (used for graphId parameter in other tools)
name: Graph name
description: Graph description
type: Graph type
status: Graph status
nodesCount: Number of nodes
edgesCount: Number of edges
createdAt: Creation time
updatedAt: Update time
publishedAt: Publication time (if published)
nodes: Node list, each node contains:
id: Node ID (used for add_edge and get_node_details tools)
name: Node name
type: Node type
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Graph status filter: - draft: Draft status, can be freely modified - published: Published status, recommended to track changes through version management - archived: Archived status, modifications not recommended | |
| type | No | Graph type filter: - topology: Component topology diagram - timeline: Timeline graph - changelog: Change log graph - requirement: Requirement documentation graph - knowledge_base: Knowledge base graph - ontology: Ontology graph |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's behavior by explaining its role as the 'main tool for getting information about existing graphs' and detailing return data structure, including nested nodes. However, it lacks information on potential side effects, rate limits, or error handling, which are important for a tool with no annotations, preventing a perfect score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (e.g., Use cases, Usage recommendations, Return data), making it easy to scan. It is appropriately sized for the tool's complexity, but some redundancy exists (e.g., repeating filtering concepts in multiple sections), which slightly reduces efficiency. Overall, it's front-loaded with key information and avoids unnecessary fluff.
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 complexity (listing with filtering), lack of annotations, and no output schema, the description provides comprehensive context. It covers purpose, usage guidelines, behavioral aspects, and detailed return data, compensating for the absence of structured output schema. This makes it complete enough for an AI agent to understand and invoke the tool correctly without gaps.
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% description coverage, so the baseline is 3. The description adds value by explaining the purpose of filtering ('Filter graphs by status, such as viewing all drafts or published graphs') and linking parameters to use cases, which enhances understanding beyond the schema's enum descriptions. However, it doesn't provide additional syntax or format details, so it doesn't fully maximize the potential for parameter semantics.
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 explicitly states the tool's purpose as 'List all knowledge graphs with support for filtering by status and type,' which is a specific verb+resource combination. It distinguishes itself from sibling tools like 'create_graph' or 'get_node_details' by focusing on listing existing graphs rather than creating new ones or querying specific nodes. The description clearly articulates what the tool does without being tautological.
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 explicit usage recommendations, including when to use this tool (e.g., 'First call this tool to get the graph list and node information') and how it integrates with sibling tools (e.g., 'Use these IDs to call other tools like add_edge, get_node_details'). It also offers context on when to use it, such as confirming a graph's status before operations, making it clear when this tool is appropriate versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Publish a knowledge graph, changing its status from draft to published. Published graphs can still be modified, but it's recommended to track important changes through version management. Prerequisites:
Graph must exist and be in draft status
Recommended to ensure graph content is complete before publishing
Ensure all necessary nodes and edges have been added
Usage recommendations:
First use list_graphs to check the current status of the graph
Use get_node_details to check the completeness of key nodes
Review the graph structure before publishing
Record publication time for version management
Notify relevant team members after publication
Return data:
data: Published graph information
id: Graph ID
name: Graph name
type: Graph type
status: Published
publishedAt: Publication time
| Name | Required | Description | Default |
|---|---|---|---|
| graphId | 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 behavioral disclosure. It effectively describes key behavioral traits: the tool changes graph status, published graphs can still be modified, and version management is recommended. However, it doesn't mention error conditions (e.g., what happens if graph is already published) or rate limits, leaving some gaps.
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 appropriately front-loaded with the core purpose, but it includes extensive sections (Prerequisites, Usage recommendations, Return data) that, while helpful, make it somewhat verbose. Some sentences in the usage recommendations could be condensed without losing value, affecting efficiency.
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 (status-changing operation), no annotations, and no output schema, the description does a good job covering purpose, prerequisites, usage, and return values. However, it lacks details on error handling or side effects (e.g., impact on related resources), which would enhance completeness for this type of 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 has 0% description coverage and only one parameter (graphId). The description doesn't explicitly mention parameters, but it strongly implies the graphId parameter through context (e.g., 'Graph must exist and be in draft status'). Given the low schema coverage and single parameter, the description compensates well by clarifying what the parameter represents.
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 specific action ('Publish a knowledge graph') and the effect ('changing its status from draft to published'), distinguishing it from sibling tools like create_graph (creation) or list_graphs (listing). It provides a precise verb+resource combination with explicit outcome.
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 explicit guidance on when to use this tool (when a graph exists in draft status) and includes detailed prerequisites (graph must be in draft, content should be complete) and usage recommendations (e.g., first use list_graphs to check status). It clearly distinguishes this from other tools by focusing on status transition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save AI-generated SVG graphics or Markdown documents to the knowledge graph. This tool must be used in conjunction with get_creation_guidelines and list_graphs tools. Use cases:
Save SVG visualization representation of the graph
Save Markdown documents related to nodes
Batch save multiple resource files
Usage recommendations:
First call get_creation_guidelines to get resource creation standards
Use list_graphs to get target graph ID and node ID (if needed)
Create resource content according to standards
Use this tool to save the resource
After saving, use get_node_details to check resource association status
Return data:
data: Saved resource information
id: Resource ID
type: Resource type (svg/markdown)
title: Resource title
description: Resource description
nodeId: Associated node ID (if any)
createdAt: Creation time
| Name | Required | Description | Default |
|---|---|---|---|
| graphId | Yes | Graph ID, must be obtained from list_graphs return data | |
| resourceType | Yes | Resource type: - svg: SVG graphics file - markdown: Markdown document | |
| title | Yes | Resource title, must comply with naming rules in get_creation_guidelines | |
| content | Yes | Resource content, must comply with format specifications in get_creation_guidelines | |
| description | No | Resource description (optional) | |
| nodeId | No | Associated node ID (optional), if provided must be obtained from nodes array in list_graphs |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by explaining the tool's role in a workflow, mentioning batch saving capability, and detailing the return data structure. However, it doesn't explicitly state that this is a write/mutation operation (though implied by 'save'), nor does it mention error conditions or permissions required.
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 well-structured with clear sections (purpose, use cases, usage recommendations, return data) and every sentence adds value. It's appropriately sized for a complex tool with workflow dependencies, with no redundant or unnecessary 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?
For a mutation tool with no annotations and no output schema, the description provides excellent completeness. It explains the tool's purpose, workflow dependencies, use cases, and detailed return data structure, giving the agent sufficient context to use the tool correctly despite the lack of structured metadata.
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?
With 100% schema description coverage, the baseline is 3. The description adds value by explaining how parameters relate to other tools (graphId from list_graphs, title/content rules from get_creation_guidelines) and clarifying the optional nature of nodeId association. However, it doesn't provide additional semantic context beyond what's in the schema descriptions.
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 with specific verbs ('save AI-generated SVG graphics or Markdown documents') and resources ('to the knowledge graph'). It distinguishes from siblings by focusing on saving resources rather than creating/deleting graphs/nodes/edges or updating existing resources.
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 explicit usage recommendations with a numbered workflow, naming specific sibling tools (get_creation_guidelines, list_graphs, get_node_details) for prerequisites and follow-up actions. It also lists three specific use cases, giving clear context for when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Unlink resource associations from nodes. This tool must be used in conjunction with list_graphs and get_node_details tools. Use cases:
Adjust resource associations
Remove incorrect resource associations
Reorganize node resource structure
Usage recommendations:
First call list_graphs to get target graph information
Use get_node_details to view node's resource associations
Confirm unlinking won't affect other functionality
Record changes for potential re-association
Important notes:
Only removes association, does not delete resource
Resource can still be used by other nodes
Association can be re-established at any time
Return data:
data: Operation result
resourceId: Resource ID
nodeId: Node ID
unlinkedAt: Time when association was removed
| Name | Required | Description | Default |
|---|---|---|---|
| graphId | Yes | Graph ID, must be obtained from list_graphs return data | |
| nodeId | Yes | Node ID, must be obtained from nodes array in list_graphs | |
| resourceId | Yes | Resource ID to unlink, must be obtained from resources array in get_node_details |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and excels. It discloses critical behavioral traits: the tool only removes associations without deleting resources, resources remain usable by other nodes, associations can be re-established, and it includes important safety recommendations about confirming impacts and recording changes.
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 well-structured with clear sections (Use cases, Usage recommendations, Important notes, Return data) and every sentence adds value. It could be slightly more front-loaded by moving the core purpose statement earlier, but overall it's efficient and organized.
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 mutation tool with no annotations and no output schema, the description provides excellent completeness. It covers purpose, workflow integration, behavioral implications, parameter context, and even documents the return data structure, compensating fully for the lack of structured metadata.
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 description coverage is 100%, so the baseline is 3. The description adds value by explaining the parameter sources (e.g., 'must be obtained from list_graphs return data' is implied in the usage recommendations), but doesn't provide additional syntax or format details beyond what the schema already documents. It earns a 4 for contextual integration.
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 specific action ('unlink resource associations from nodes') and distinguishes it from sibling tools like 'delete_resource' by emphasizing it only removes associations, not the resource itself. The verb+resource combination is precise 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 explicit guidance on when to use this tool, including a prerequisite workflow (use with 'list_graphs' and 'get_node_details'), specific use cases (adjust, remove incorrect, reorganize), and recommendations for confirmation and recording changes. It clearly distinguishes from deletion operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Modify edges in the knowledge graph. This tool must be used in conjunction with list_graphs and get_node_details tools. Use cases:
Update edge label information
Adjust edge weight values
Update edge metadata information
Usage recommendations:
First call list_graphs to get target graph information
Use get_node_details to view edge list of related nodes
Only update fields that need to be modified, keep others unchanged
After updating, call get_node_details again to confirm changes
Return data:
data: Updated edge information
id: Edge ID
type: Edge type
sourceId: Source node ID
targetId: Target node ID
label: Edge label
weight: Edge weight
metadata: Edge metadata
updatedAt: Update time
| Name | Required | Description | Default |
|---|---|---|---|
| graphId | Yes | Graph ID, must be obtained from list_graphs return data | |
| edgeId | Yes | Edge ID, must be obtained from relationships array in get_node_details | |
| label | No | New edge label (optional) | |
| weight | No | New edge weight (optional), used to represent relationship strength | |
| metadata | No | New edge metadata (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well: it discloses that this is a mutation tool ('Modify edges'), specifies required companion tools, advises partial updates ('Only update fields that need to be modified'), and describes the return data structure. It doesn't mention permissions, rate limits, or error conditions, but covers core behavioral aspects.
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 well-structured with clear sections (purpose, use cases, recommendations, return data). It's appropriately sized for a mutation tool with complex prerequisites. Some redundancy exists between 'use cases' and parameter descriptions, but overall it's efficient and front-loaded with essential 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?
For a mutation tool with no annotations and no output schema, the description provides substantial context: clear purpose, detailed usage workflow, partial update guidance, and full return data specification. It doesn't cover error cases or side effects, but given the schema richness and workflow guidance, it's mostly 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 100%, so the schema already documents all 5 parameters thoroughly. The description adds minimal parameter semantics beyond the schema - it lists use cases that map to parameters but doesn't provide additional syntax, format, or constraint details. Baseline 3 is appropriate when schema does the heavy lifting.
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: 'Modify edges in the knowledge graph.' It specifies the resource (edges) and action (modify/update). However, it doesn't explicitly differentiate from sibling tools like 'update_node' or 'update_resource' beyond the edge focus.
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 explicit usage recommendations with numbered steps, including prerequisites ('First call list_graphs...'), companion tools ('get_node_details'), and post-update verification ('call get_node_details again to confirm'). It clearly guides when and how to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Modify nodes in the knowledge graph. This tool must be used in conjunction with list_graphs and get_node_details tools. Use cases:
Update basic node information (name, description, etc.)
Update file paths associated with nodes
Update node metadata information
Usage recommendations:
First call list_graphs to get target graph and node ID
Use get_node_details to check current node status
Only update fields that need to be modified, keep others unchanged
After updating, call get_node_details again to confirm changes
Return data:
data: Updated node information
id: Node ID
name: Node name
type: Node type
description: Node description
filePath: Associated file path
metadata: Node metadata
updatedAt: Update time
| Name | Required | Description | Default |
|---|---|---|---|
| graphId | Yes | Graph ID, must be obtained from list_graphs return data | |
| nodeId | Yes | Node ID, must be obtained from nodes array in list_graphs | |
| name | No | New node name (optional) | |
| description | No | New node description (optional) | |
| filePath | No | New associated file path (optional) | |
| metadata | No | New node metadata (optional) |
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 effectively describes the mutation nature ('Modify'), outlines a multi-step workflow with prerequisites, specifies that only certain fields should be changed, and details the return data structure. However, it lacks information on error conditions, permissions, or rate limits.
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 well-structured with clear sections (purpose, use cases, usage recommendations, return data) and uses bullet points for readability. It is appropriately sized but includes some redundancy, such as listing return data fields that could be inferred from context, slightly reducing efficiency.
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 a mutation tool with no annotations or output schema, the description provides substantial context: purpose, prerequisites, workflow, and return data. It covers key aspects but omits details like error handling or side effects, which would enhance completeness for a high-risk 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 100% description coverage, so the baseline is 3. The description does not add significant parameter-specific information beyond what's in the schema, though it contextualizes parameters by mentioning use cases like 'Update basic node information' and 'Update file paths,' which loosely map to the optional 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 states the specific action ('Modify nodes') and resource ('in the knowledge graph'), distinguishing it from sibling tools like add_node (creation) or delete_node (removal). It provides concrete use cases that illustrate the scope of modifications possible.
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 explicitly names prerequisite tools (list_graphs and get_node_details) and provides a step-by-step workflow for proper usage. It includes specific recommendations like 'Only update fields that need to be modified' and 'After updating, call get_node_details again to confirm changes,' offering clear guidance on when and how to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update resource information in the knowledge graph. This tool must be used in conjunction with list_graphs and get_node_details tools. Use cases:
Modify resource title or description
Update resource metadata information
Improve resource documentation
Usage recommendations:
First call list_graphs to get target graph information
Use get_node_details to check current resource information
Only update fields that need to be modified
Maintain consistency in resource naming
Return data:
data: Updated resource information
id: Resource ID
name: Resource name
title: Resource title
description: Resource description
updatedAt: Update time
| Name | Required | Description | Default |
|---|---|---|---|
| graphId | Yes | Graph ID, must be obtained from list_graphs return data | |
| resourceId | Yes | Resource ID, must be obtained from resources array in get_node_details | |
| name | No | New resource name (optional) | |
| title | No | New resource title (optional) | |
| description | No | New resource description (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by specifying the mutation nature ('update'), prerequisites (must use other tools first), and operational constraints ('maintain consistency'). It also describes return data format. However, it doesn't mention potential side effects, error conditions, or permission requirements that would be helpful 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 well-structured with clear sections (purpose, use cases, usage recommendations, return data) and each sentence adds value. It's appropriately sized for a mutation tool with prerequisites. Some minor redundancy exists between 'use cases' and the purpose statement, but overall it's efficiently organized.
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 mutation tool with no annotations and no output schema, the description does well by explaining prerequisites, usage patterns, and return format. It provides operational context missing from structured fields. The main gap is lack of error handling or side effect information, but given the comprehensive usage guidance and return data description, it's mostly 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 100%, so the schema already documents all 5 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema descriptions. It mentions what fields can be updated but doesn't provide additional semantic context about parameter usage or constraints.
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 as 'Update resource information in the knowledge graph' with specific mention of what can be modified (title, description, metadata, documentation). It distinguishes from siblings like 'update_node' and 'update_edge' by focusing specifically on resources. However, it doesn't explicitly contrast with 'save_resource' which might have overlapping functionality.
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 explicit, step-by-step usage recommendations including prerequisites (must use list_graphs and get_node_details first), specific sequencing instructions, and guidance on what to update ('only update fields that need to be modified'). It also mentions maintaining consistency in naming, giving clear operational context.
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.0add_edgeadd_nodecreate_graphdelete_edgedelete_nodedelete_resourceget_creation_guidelinesget_node_detailslist_graphspublish_graphsave_resourceunlink_resourceupdate_edgeupdate_nodeupdate_resourceEach tool has a clearly distinct purpose targeting specific graph elements (nodes, edges, graphs, resources) with precise actions (add, delete, update, list, get). No overlap exists; for example, delete_edge, delete_node, and delete_resource handle different entities, and update tools are clearly separated by target. The descriptions reinforce these distinctions, making misselection unlikely.
All tool names follow a consistent verb_noun pattern with snake_case throughout, such as add_edge, list_graphs, update_node, and get_node_details. The verbs (add, create, delete, get, list, publish, save, unlink, update) are used predictably across similar operations, enhancing readability and predictability for agents.
With 15 tools, the count is well-scoped for a knowledge graph management server, covering CRUD operations for graphs, nodes, edges, and resources, plus auxiliary tools like publish_graph and get_creation_guidelines. Each tool earns its place by addressing specific needs in graph lifecycle management, avoiding redundancy while ensuring comprehensive coverage.
The tool set provides complete CRUD/lifecycle coverage for knowledge graphs, including creation (create_graph), modification (add/update/delete for nodes, edges, resources), querying (list_graphs, get_node_details), and publishing (publish_graph). No obvious gaps exist; tools like get_creation_guidelines and unlink_resource address nuanced needs, ensuring agents can handle all typical workflows without dead ends.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
AI knowledge graph for architecture, portfolio, and digital strategy management.
Knowledge graph ingestion, entity search, ontology analysis, and CoSync scoring.
Knowledge coverage map and health score. Ingest docs into a governed knowledge graph via MCP.
Knowledge graph for AI agents. Query concepts, walk edges, get advisories.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/aiuluna/knowledge-graph-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
