How Agents Discover and Use Wiki and CodeGraph Capabilities in TencentDB Agent Memory

Agents dynamically discover and access Wiki and CodeGraph capabilities through a two-step self-discovery process using HTTP endpoints. The Knowledge Tools Injector enables this by injecting resource metadata into agent prompts, allowing any agent to retrieve team knowledge assets without hardcoded configurations.

The TencentDB-Agent-Memory project implements a knowledge-as-a-service architecture where agents treat Wiki documentation and CodeGraph indexes as discoverable tools. This design decouples agents from specific knowledge sources while maintaining security through capability-based access control.

The Two-Step Discovery and Execution Flow

Agents never hardcode knowledge service URLs. Instead, they follow a standardized discovery-then-call workflow defined by the Knowledge Tools Injector.

Step 1: Discovery via /v3/tools/list

When an agent starts a turn, the proxy injects a <knowledge_tools> XML block into the prompt. This block informs the LLM that two HTTP tools are available:

• tools/list — fetch the catalogue of available resources
• tools/call — execute a specific knowledge operation

The agent first invokes POST /v3/tools/list to retrieve the complete inventory:

POST /v3/tools/list
{
  "service_id": "team-1"
}

The response catalogue contains each Wiki or CodeGraph item's metadata:

• knowledge_id — unique resource identifier
• type — wiki or codegraph
• name — human-readable resource name
• service_url — endpoint for execution calls

Step 2: Execution via /v3/tools/call

After identifying the needed resource, the agent calls POST /v3/tools/call with the selected knowledge_id:

POST /v3/tools/call
{
  "knowledge_id": "wiki-42",
  "tool_name": "read_page",
  "params": { "page_id": "introduction" }
}

For CodeGraph structural queries:

POST /v3/tools/call
{
  "knowledge_id": "codegraph-7",
  "tool_name": "search",
  "params": { "query": "function initSession" }
}

The knowledge service returns data with code: 0 on success. Errors are indicated by data.isError === true rather than HTTP status codes.

How the Knowledge Tools Injector Builds the Discovery Block

The injector in MemoryProxy/src/injection/injectors/knowledge-tools-injector.ts performs three critical operations to prepare agent-accessible knowledge:

Capability-Based Resource Filtering (Lines 87-96)

Resources are filtered according to the agent's AssetCapabilityFlags. This ensures agents only see Wiki capabilities, CodeGraph capabilities, or both—based on their assigned permissions:

// From knowledge-tools-injector.ts
const flags = context.agent.capabilities.assetFlags;
const hasWiki = flags.includes('WIKI');
const hasCodeGraph = flags.includes('CODEGRAPH');
// Filters applied to KnowledgeItem[] before rendering

XML Tag Generation (Lines 61-73)

Each KnowledgeItem transforms into a <knowledge /> XML tag encoding:

• Resource type (wiki | codegraph)
• knowledge_id for call routing
• name and service_url
• Optional matching attributes (repository slug, branch, or other qualifiers for CodeGraph scoping)

Telemetry Header Injection (Lines 46-53)

The injector appends tracking headers without exposing secrets:

• x-tdai-user-id — calling user identity
• x-tdai-team-id — team context for multi-tenant isolation

These headers enable the knowledge service to attribute calls for usage analytics and access auditing.

Prompt Guidance for Capability Selection

The rendered <knowledge_tools> block includes contextual guidance telling agents when to prefer each capability type, as implemented in knowledge-tools-injector.ts (lines 74-99):

Capability	Use Case	Query Characteristics
Wiki	Design-oriented questions	Architecture decisions, API conventions, onboarding docs
CodeGraph	Structural and impact-analysis queries	Cross-file dependencies, call hierarchies, refactoring scope

This guidance ensures agents select the appropriate knowledge source without exhaustive trial-and-error.

Core Implementation Files

File	Purpose
MemoryProxy/src/injection/injectors/knowledge-tools-injector.ts	Renders <knowledge_tools> block, filters by capabilities, generates XML
MemoryProxy/src/knowledge/core-client.ts	Retrieves KnowledgeItem[] from Knowledge service
MemoryProxy/src/types.ts	Defines KnowledgeItem interface (type, id, name, URLs, metadata)
MemoryKnowledge/v3-api-memoryknowledge-doc.md	Documents POST /v3/tools/list and POST /v3/tools/call contracts

Summary

• Agents discover Wiki and CodeGraph capabilities through a dynamically injected <knowledge_tools> block at turn start.
• The Knowledge Tools Injector filters resources by AssetCapabilityFlags, converts items to XML tags, and adds telemetry headers.
• Two HTTP endpoints—/v3/tools/list and /v3/tools/call—enable self-service knowledge retrieval without hardcoded URLs.
• Built-in prompt guidance directs agents toward Wiki for documentation and CodeGraph for structural code analysis.

Frequently Asked Questions

How does an agent know which knowledge resources it can access?

The Knowledge Tools Injector examines the agent's AssetCapabilityFlags and filters the available KnowledgeItem list before rendering the prompt. Only resources matching the agent's Wiki and/or CodeGraph permissions appear in the <knowledge_tools> block, as implemented in knowledge-tools-injector.ts lines 87-96.

What distinguishes the two knowledge capability types?

Wiki provides design-oriented, narrative documentation suited for questions about architecture, conventions, and procedures. CodeGraph exposes structural code relationships—call hierarchies, cross-file dependencies, and impact analysis—derived from repository indexing. The injector includes explicit guidance in the prompt to help agents select appropriately.

Why use a two-step discovery process instead of direct invocation?

Separating discovery (/v3/tools/list) from execution (/v3/tools/call) eliminates hardcoded dependencies between agents and knowledge services. Teams can add, remove, or reconfigure knowledge resources without redeploying agents. The LLM reasons over available tools at runtime, making the system adaptable to evolving team assets.

How are knowledge service calls authenticated without exposing secrets?

The Knowledge Tools Injector injects telemetry headers (x-tdai-user-id, x-tdai-team-id) into the request configuration. These headers enable the knowledge service to validate and attribute calls using proxy-managed identity tokens, keeping actual credentials out of agent prompts and LLM context windows.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}