Skip to main content
Glama
keshrath

agent-knowledge

by keshrath

knowledge_graph

Create, remove, invalidate, list, or traverse knowledge graph edges with temporal validity and code structure support. Manage relationships between entries.

Instructions

Knowledge graph operations with temporal validity and code structure support. Create/remove edges, traverse via directed BFS, bulk-import code graph edges. Relationship types: related_to, supersedes, depends_on, contradicts, specializes, part_of, alternative_to, builds_on, calls, imports, inherits. Code structure types (calls/imports/inherits) are created by knowledge-ingest and use "code:" prefixed node IDs.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
as_ofNoISO date — only return edges valid at this date (action=list/traverse, optional)
depthNoMax traversal depth in hops (action=traverse, default: 2)
edgesNoArray of edges to create (action=bulk_link). Each: { source, target, rel_type, strength?, origin? }
entryNoEntry path for filtering (action=list) or BFS start (action=traverse)
actionYesAction: link (create edge), unlink (remove edge), invalidate (set valid_to), list (list edges), traverse (directed BFS), bulk_link (batch-create edges), unlink_by_origin (delete all edges from a specific origin)
originNoEdge origin to delete (action=unlink_by_origin). E.g. "tree-sitter" to clear code graph before re-ingest.
sourceNoSource entry path (action=link/unlink/invalidate), e.g. 'projects/my-project.md'
targetNoTarget entry path (action=link/unlink/invalidate), e.g. 'decisions/architecture.md'
rel_typeNoRelationship type (required for link, optional filter for unlink/invalidate/list)
strengthNoEdge strength 0-1 (action=link, default: 0.5)
valid_toNoISO date the fact stopped being true (action=link/invalidate). For invalidate, defaults to today.
directionNoTraversal direction (action=traverse, default: both). outbound: follow source→target (what does X call?). inbound: follow target→source (who calls X?). both: undirected (default, preserves legacy behavior).
valid_fromNoISO date the fact became true (action=link, optional). Null/omitted = unbounded.
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden. It discloses temporal validity and that code structure edges are created by knowledge-ingest, which is useful. However, it does not warn about destructive side effects of unlink/invalidate or the scope of bulk operations, leaving behavioral uncertainty.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is reasonably concise, using three sentences to cover operations, relationship types, and code structure nuance. It could tighten by omitting the redundant relationship list from the enum, but it remains front-loaded and readable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema is present, and the description does not describe return values for actions like list or traverse. It also omits details about state mutations (e.g., irreversibility of unlink). Given the tool's complexity and no annotations, this is a significant gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description adds minimal value: it re-lists relationship types (already in the enum) and notes the 'code:' prefix for node IDs. It does not explain parameter interactions beyond what the schema already states.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool performs knowledge graph operations: create/remove edges, traverse via BFS, bulk-import code edges. It also lists relationship types and code structure specifics. However, it does not explicitly contrast with sibling tools like knowledge_search or knowledge_analyze, so differentiation relies on the implicit 'graph' focus.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus siblings. It does not mention when not to use it, nor does it reference alternative tools. The code structure note implies a use case, but there is no clear routing or exclusion.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/keshrath/agent-knowledge'

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