Which integrations are available for this server?

Includes MuleSoft Action as one of the four AgentForce action types, supporting integration with MuleSoft's platform for action execution. Integrates with NVIDIA NIM as an implementation of the Reasoning Engine, allowing queries about the agent's AI model integration path and dependency chain. Provides an auditable knowledge graph for Salesforce AgentForce, enabling deterministic answers with full source traceability for declared relationships among AgentForce components.

ckg-agentforce

by Yarmoluk

Overview Schema Source Related Servers Discussions Admin

Python

Hybrid

ckg-agentforce

ckg-agentforce — AgentForce as a traversable knowledge graph

PyPI version Python Data: ELv2 Code: MIT ckg-agentforce MCP server F1: 0.471 · 4× RAG

An auditable knowledge graph for Salesforce AgentForce — deterministic agent answers with full source traceability.

AgentForce charges $2 per autonomous resolution. Every failed resolution is a retry, a CSAT hit, and $2 with no outcome. Wrong inference is expensive here. The graph declares what the agent should already know — so it doesn't have to infer it.

Every edge traces to a declared relationship and a SHA-256-pinned source document. Built for Salesforce architects, platform engineers, and agent developers who need verifiable answers about AgentForce dependencies, billing paths, trust layer policy, and deployment patterns — not model inference.

Not a general-purpose semantic search layer. If it's not a declared edge, the graph doesn't return it.

pip install ckg-agentforce
# or: uvx ckg-agentforce

PyPI · GitHub · Benchmark paper · graphifymd.com

What it is

40 nodes · 52 edges · the full AgentForce stack as a typed dependency graph. Pre-structured, traversable, deterministic. Served over MCP. No inference at query time.

get_prerequisites("Autonomous Resolution")

→ Autonomous Resolution          ← $2/event billing trigger
  ├─ [REQUIRES] Resolution Criteria
  ├─ [REQUIRES] Audit Trail
  │    └─ [REQUIRES] Einstein Trust Layer
  │         ├─ [REQUIRES] AgentForce Platform
  │         └─ [REQUIRES] Reasoning Engine
  └─ [REQUIRES] Policy Enforcement
       └─ [REQUIRES] Einstein Trust Layer

  269 tokens · declared edges only · no inference
  RAG equivalent: ~2,982 tokens · probabilistic

query_ckg("Einstein Trust Layer")

→ Dependents (what it gates):
  ← [REQUIRES] Data Masking
  ← [REQUIRES] Audit Trail
  ← [REQUIRES] Zero Data Retention
  ← [REQUIRES] Grounding
  ← [REQUIRES] Einstein Agent
  ← [REQUIRES] Policy Enforcement

Six capabilities gate on this one node. RAG returns six separate docs.
The graph knows — it's a declared edge.

Related MCP server: RAG Knowledge Graph MCP

Source provenance — verifiable to the byte

Every node carries a source_url and a source_hash (SHA-256 of the source document's bytes at extraction time). An edge isn't just asserted from a source — it's pinned to a specific version of it.

# Verify any node's source hasn't changed since extraction
curl -s https://help.salesforce.com/s/articleView?id=sf.einstein_ai_trust_layer.htm | sha256sum
# expected: cc11eedeee761e083a591cd20bbbdf46d2942906519dc5f8e51e617857118cda

The full audit chain:

edge answer
  → graph commit hash       (git log -- agentforce.csv)
  → source_content_hash     (sha256 of page bytes at extraction time)
  → knowledge_source_ref    (URL — fetch hint, not trust anchor)

A hash mismatch means either the source changed (stale edge → re-extract) or the graph was patched without re-fetching (silent edit → investigate). No judgment required. Run scripts/refresh_hashes.py to recompute.

Via MCP — verify_source("Einstein Trust Layer"):

source_url:  https://help.salesforce.com/s/articleView?id=sf.einstein_ai_trust_layer.htm
source_hash: sha256:cc11eedeee761e083a591cd20bbbdf46d2942906519dc5f8e51e617857118cda
verify:      curl -s '<url>' | sha256sum

Reference implementation of knowledge_source_ref + source_content_hash from GuardrailDecisionV1.

What developers are actually hitting

Signal from Salesforce developer forums, Trailblazer Community, and hands-on deployments.

01 — The $2 retry problem. An agent misidentifies the resolution path. It attempts resolution, fails criteria, retries — $4 spent, zero outcome. The billing trigger lives four hops from Einstein Agent. Agents that don't traverse the full chain get it wrong.

02 — "Which policy tier is blocking my agent?" Einstein Trust Layer gates six downstream capabilities. Architects can't tell whether a blocked agent is hitting Data Masking, Zero Data Retention, or Policy Enforcement without traversing the dependency chain manually. The graph makes it a one-hop query.

03 — The Grounding Source Gap. AgentForce Grounding REQUIRES Knowledge Base, which REQUIRES Data Cloud. Most implementations skip Data Cloud and wonder why Grounding is unreliable. The graph shows the prerequisite chain; RAG returns the docs separately.

04 — NVIDIA NIM integration path. AgentForce Model Selection ENABLES Reasoning Engine, which has an IMPLEMENTS edge to NVIDIA NIM. Developers searching for the NIM integration path get inconsistent Salesforce docs. The declared edge makes it deterministic.

Declared relationships, not confidence scores

Every edge was extracted from a Salesforce source document and given a type. No probabilistic weights, no cosine similarity scores, no confidence intervals. An edge either exists — declared, typed, sourced — or it doesn't. When the answer isn't in the graph, the traversal returns nothing rather than a hallucinated approximation.

Edge types:

Type	Meaning	Example
REQUIRES	Hard prerequisite — A cannot function without B	Einstein Trust Layer REQUIRES AgentForce Platform
ENABLES	Capability unlock — A makes B possible	Model Selection ENABLES Reasoning Engine
IMPLEMENTS	Concrete instantiation of an abstract concept	NVIDIA NIM IMPLEMENTS Reasoning Engine
RELATES_TO	Conceptual proximity, no dependency direction	Data Masking RELATES_TO Zero Data Retention

Why no confidence levels? The edge type is the confidence signal. REQUIRES means load-bearing and sourced; RELATES_TO means real but weaker. A missing edge is silence from a source-grounded system — not a soft no, not a low-confidence guess.

✗ RAG:  "Einstein Trust Layer probably governs data access... (similarity: 0.79)"
        Score is on the chunk, not the claim. The claim itself is unverified.

✓ CKG:  "Einstein Trust Layer REQUIRES AgentForce Platform and gates six capabilities:
         Data Masking · Audit Trail · Zero Data Retention · Grounding · Einstein Agent · Policy Enforcement"
        No score. Declared edge. Traces to trust layer source doc.

A/B — AgentForce domain, local models, no GPU

30 questions on the $2/resolution billing path, trust layer, and action types · CPU only · Ollama · temperature 0

Category	Bare model	+ CKG	Lift
Billing path F1	0.091	0.201	+121%
Trust layer F1	0.063	0.134	+113%
Prereq-chain F1	0.058	0.142	+145%
Key-fact accuracy	8.1%	19.4%	+11pp

Example — P01 (billing prereq chain):

Q: What must resolve before AgentForce charges the $2 resolution fee?
✗ Bare: "The agent completes the customer's request successfully..." [vague, misses billing trigger]
✓ CKG:  "Resolution Criteria must be satisfied, Audit Trail must log the event,
         and Policy Enforcement must clear — all gated by Einstein Trust Layer." [exact chain]

Example — L03 (action type lookup):

Q: What are the four AgentForce action types?
✗ Bare: "AgentForce supports Standard Actions, Custom Actions, and API Actions..." [misses MuleSoft]
✓ CKG:  "Flow Action · Apex Action · MuleSoft Action · External Action" [declared edges, correct]

Install

Add to claude.ai (no install required):

https://ckg-agentforce.onrender.com/mcp

Settings → Connectors → Add connector → paste URL.

Local — Claude Desktop / Claude Code:

pip install ckg-agentforce
# or
uvx ckg-agentforce

{
  "mcpServers": {
    "agentforce": {
      "command": "uvx",
      "args": ["ckg-agentforce"]
    }
  }
}

Tools

list_concepts — List all 40 AgentForce concepts grouped by type
search_concepts — Fuzzy search across all concepts by keyword
query_ckg — Typed subgraph around any concept (1–5 hops)
get_prerequisites — Full upstream prerequisite chain for any concept
resolution_path — The exact $2/resolution billing traversal — every hop declared
verify_source — Source URL + SHA-256 hash for any concept (GuardrailDecisionV1)

Tool	Args	Description
`list_concepts()`	—	All 40 AgentForce concepts grouped by type
`search_concepts(query)`	query: str	Fuzzy search across all concepts
`query_ckg(concept, depth)`	concept: str, depth: int 1–5	Typed subgraph around any concept
`get_prerequisites(concept)`	concept: str	Full upstream prerequisite chain
`resolution_path()`	—	The $2/resolution billing traversal — every hop declared
`verify_source(concept)`	concept: str	Source URL + SHA-256 hash · full audit chain
`route_query(question)`	question: str	CKG Router — optimal model tier + reasoning approach from graph depth

`route_query(question)` — CKG Router

The graph depth IS the routing signal. AgentForce dependency chains (Einstein Trust Layer → Data Cloud → NVIDIA NIM → Resolution Criteria) signal reasoning complexity deterministically. No heuristic: the graph decides.

Hop depth	Model	Reasoning
1	haiku	direct
2	sonnet	generic_cot
3+	opus	sparql_cot

A/B — before vs after routing:

# Baseline (no routing)
query_ckg("Einstein Trust Layer", depth=3)
→ subgraph returned, caller guesses model...
→ calls GPT-4o on everything, $0.072/query

# Treatment (route_query)
route_query("Einstein Trust Layer")
→ model_tier: sonnet
→ reasoning_approach: generic_cot
→ why: 2-hop chain, 3 parallel branches — moderate complexity
→ ~480 tokens, $0.0014/query

Same answer. 98% cheaper. Graph depth made the decision.

Works with any LLM — Claude, GPT-4o, Gemini, Llama. Model-agnostic by design.

What's in the graph

40 nodes · 52 edges · 4 edge types: REQUIRES · ENABLES · IMPLEMENTS · RELATES_TO

Layer	Concepts
Agents	Einstein Agent · Service Agent · Sales Agent · Marketing Agent
Actions	Flow Action · Apex Action · MuleSoft Action · External Action · Standard Action · Custom Action
Platform	AgentForce Platform · Data Cloud · Salesforce CRM · Knowledge Base
Reasoning	Reasoning Engine · Model Selection · NVIDIA NIM · Token Budget · Context Window
Trust	Einstein Trust Layer · Data Masking · Zero Data Retention · Policy Enforcement · Compliance Rules
Workflow	Agent Topic · Agent Instruction · Resolution Criteria · Conversation State · Grounding
Billing	Autonomous Resolution ($2/event) · Audit Trail · Agent Metrics · Handoff to Human
Routing	Omni-Channel Routing · Multi-Agent Orchestration · Prompt Template

Every node traces to an authoritative Salesforce source document. Every source is SHA-256 pinned.

Pro access — all 97 domains

Remote MCP connector · no install · paste one URL into claude.ai or Cursor
97 domains: NVIDIA · Finance · Healthcare · Regulatory · Enterprise AI
graphifymd.com/pro/

Sources

Every node and edge traces to one of these. No probabilistic inference — declared relationships only.

Type	Source	Coverage
Official	developer.salesforce.com/docs/einstein/genai/guide/agentforce-overview.html	Platform, agents, actions, grounding
Official	Salesforce Einstein Trust Layer docs	Trust, Data Masking, ZDR, Policy Enforcement
Official	AgentForce billing and resolution docs	Autonomous Resolution, $2/event trigger, Audit Trail
Official	Data Cloud integration guide	Data Cloud, Knowledge Base, Grounding chain
Official	Model selection and NIM integration	Reasoning Engine, NVIDIA NIM, Model Selection
Dataset	huggingface.co/datasets/danyarm/ckg-benchmark	KRB v0.6.2 — 7,928 queries
Benchmark	github.com/Yarmoluk/ckg-benchmark/paper/main.pdf	Full methodology, F1 0.471

Benchmark (KRB v0.6.2 locked)

System	Macro F1	Mean tokens	Cost / 1k queries
CKG	0.471	269	$7.81
RAG	0.123	2,982	$76.23
GraphRAG	0.120	~3,000	~$76

7,928 queries · 5-hop F1: 0.772 (CKG) vs 0.170 (RAG) · dataset · full paper

Licensing

Layer	License	Plain English
Server code — server.py, graph.py, serve.py, scripts/	MIT	Do anything. Fork it, embed it, sell products built on it.
Graph data — domains/agentforce.csv + source hashes	Elastic License 2.0	Free for all internal and commercial use. Cannot offer this graph as a competing hosted service.
Extraction pipeline + benchmark harness	Proprietary — Graphify.md	Not in this repo. How 97 domains get built and maintained.

Can I build an agent or product using this CKG? Yes. No restrictions.
Can I run this inside my company's infrastructure? Yes. ELv2 allows all internal commercial use.
Can I offer "AgentForce CKG as a Service" commercially? No. That's the one thing ELv2 blocks.

EVAL

benchmark: ckg-benchmark v0.6.2
dataset: huggingface.co/datasets/danyarm/ckg-benchmark
benchmarked: false
rag_baseline_f1: 0.123
graphrag_baseline_f1: 0.120
mean_tokens: 269
paper: github.com/Yarmoluk/ckg-benchmark/blob/main/paper/main.pdf

Want this for your domain?

Graphify.md builds CKGs for enterprise domains — AgentForce, NVIDIA, finance, healthcare, and custom stacks. If you need a knowledge graph for your platform, product, or internal knowledge base:

Try the hosted endpoint: ckg-agentforce.onrender.com — 50 free calls/day, then $29/mo
Enterprise / custom domains: graphifymd.com or email daniel.yarmoluk@gmail.com
Benchmark paper: F1 0.471 · 11× fewer tokens than RAG
97 domains available: graphifymd.com/pro

Built by Graphify.md · 97 domains · PyPI · patent pending

Community-built. Not affiliated with, endorsed by, or sponsored by Salesforce, Inc. AgentForce and Einstein are trademarks of Salesforce, Inc. All referenced trademarks belong to their respective owners.

Available Tools

9 tools

evaluate_trust_chainAInspect

Return a machine-readable JSON trust chain + ROI analysis + payment recommendation.

Designed for autonomous agent consumption. The agent reads the JSON, evaluates the ROI gate, selects the cheapest positive-ROI payment option, and purchases autonomously if budget is pre-authorized.

Trust chain closes the audit gap that RAG cannot: source_hashes → SHA-256 of source docs (what was known at extraction time) graph_hash → SHA-256 of the installed graph file (what is declared now) signer_key_id → Ed25519 public key fingerprint (who is attesting) benchmark_receipt → BoundaryAttest-signed F1 claim (cryptographic performance proof) scitt_status → SCITT ledger submission status (public audit anchor)

ROI gate: if total_value_per_call_usd > payment_option.price_per_call_usd → autonomous_pay = true.

Returns: JSON string (schema: ckg-trust-chain-v1).

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

Behavior4/5

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

No annotations provided, so description carries full burden. Explains return format, trust chain components, and ROI logic. Lacks details on side effects or state changes, but tool is read-only.

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?

Well-structured with main purpose followed by bullet details. Slightly verbose in explaining agent behavior, but overall concise and front-loaded.

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

Completeness5/5

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

Given zero parameters, output schema exists, and description explains return content and logic comprehensively. No gaps remain for correct invocation.

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

Parameters4/5

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

Tool has zero parameters; schema coverage is 100%. Baseline of 4 applies as description adds no parameter info beyond schema.

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

Purpose5/5

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

Clearly states the tool returns a machine-readable JSON trust chain, ROI analysis, and payment recommendation. Distinct from sibling tools like export_benchmark_receipt which only exports, or query_ckg which lacks ROI analysis.

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

Usage Guidelines4/5

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

Provides explicit guidance for autonomous agent consumption, including how to interpret ROI and proceed with payment. Does not explicitly mention alternatives or exclusions, but context is clear.

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

export_benchmark_receiptAInspect

Generate a signed BoundaryAttest receipt for the agentforce CKG benchmark result.

Produces a ckg.benchmark_result.exported claim signed with this server's Ed25519 session key. Any party holding the public key can verify the signature over the canonical JSON claim. Implements GuardrailDecisionV1 · experimental-interop-v0.1.

Result: F1 0.471 over 30 queries · ckg-benchmark v0.6.2 · 4× over RAG baseline (0.123).

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/5.0

Behavior4/5

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

Discloses key behavioral traits: generates a signed receipt using Ed25519 key, describes claim format and verifiability. No annotations provided, but the description is informative. Lacks mention of side effects or permissions.

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

Conciseness4/5

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

Four sentences, each adding value: purpose, cryptographic details, standards, example output. Efficient and well-structured, though the example result sentence is a bit technical.

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

Completeness4/5

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

Complete for a parameterless tool with output schema. Explains what the receipt is, how it is signed, and includes an example. Could note when the tool is relevant, but overall sufficient.

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

Parameters4/5

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

No parameters exist, so schema coverage is 100%. The description focuses on output instead, which is appropriate. No additional parameter meaning needed.

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

Purpose5/5

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

Clearly states the verb 'Generate' and the resource 'signed BoundaryAttest receipt' for benchmark results. The description explains the purpose and distinguishes from sibling tools like query_ckg and verify_source.

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

Usage Guidelines3/5

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

Does not explicitly state when to use versus alternatives. Mentions implementation details (GuardrailDecisionV1) but no guidance on when to avoid or prefer other tools.

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

get_prerequisitesAInspect

Return the full ordered prerequisite chain for an AgentForce concept.

Shows everything the concept depends on — the complete upstream path.

Args: concept: Target concept — e.g. 'Autonomous Resolution', 'Multi-LoRA Serving', 'Custom Actions', 'Semantic Retrieval'.

ParametersJSON Schema

Name	Required	Description	Default
`concept`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It indicates the output is an ordered chain and is read-only by nature, but it does not disclose error handling, performance, or what happens if the concept does not exist.

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

Conciseness5/5

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

The description is very concise with three sentences plus the Args block, all front-loaded. Every sentence adds value without repetition or waste.

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

Completeness4/5

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

For a simple one-parameter tool with an output schema, the description adequately covers what it does and what the parameter is. It could mention the ordering or structure of the returned chain, but it is largely complete.

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

Parameters5/5

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

The schema has 0% coverage, but the description compensates with an Args section that explains the 'concept' parameter with concrete examples, adding significant meaning beyond the bare schema.

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

Purpose5/5

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

The description clearly states the tool returns the 'full ordered prerequisite chain' for an AgentForce concept, using a specific verb and resource. It distinguishes from siblings like 'list_concepts' and 'search_concepts' by focusing on dependencies.

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

Usage Guidelines3/5

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

The description explains the tool shows the upstream path of dependencies, which implies when to use it, but it does not explicitly compare to siblings or mention when not to use it.

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

list_conceptsAInspect

List all 40 AgentForce concepts in this knowledge graph.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.6/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It does not disclose any behavioral traits such as being read-only, potential performance implications, or any side effects. The action 'List' implies reading, but this is not explicitly stated.

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

Conciseness5/5

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

The description is a single sentence of 8 words, front-loaded with the key information. No unnecessary words or details.

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

Completeness4/5

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

For a simple list tool with no parameters and an output schema present, the description adequately states the action and scope. However, it could mention that it returns the full list without any filtering, which would further distinguish it from similar tools.

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

Parameters4/5

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

There are zero parameters, and the input schema coverage is 100% (vacuously). According to guidelines, 0 parameters gives a baseline of 4. The description doesn't need to add parameter info, so this is appropriate.

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

Purpose5/5

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

The description clearly states the verb 'List', the resource 'concepts', and the scope 'all 40 AgentForce concepts in this knowledge graph'. It is specific and distinguishes itself from sibling tools like search_concepts, which implies a different purpose.

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?

The description provides no guidance on when to use this tool versus alternatives such as search_concepts or query_ckg. There is no mention of when not to use it or context about prerequisites.

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

query_ckgAInspect

Traverse the AgentForce knowledge graph from any concept.

Returns prerequisites (what this concept needs) and dependents (what it enables). Every relationship traces to an authoritative Salesforce doc URL.

Args: concept: Concept name — e.g. 'Autonomous Resolution', 'Einstein Trust Layer', 'Service Agent', 'Grounding', 'NVIDIA NIM'. depth: Traversal depth 1–5 (default 3).

ParametersJSON Schema

Name	Required	Description	Default
`depth`	No
`concept`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, the description carries full burden. It discloses that the tool is read-only (no mention of side effects), returns prerequisites and dependents, and links to Salesforce docs. It could mention error handling or existence guarantees, but overall is transparent.

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

Conciseness5/5

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

The description is extremely concise (4 sentences plus args list) with no redundant information. Key points are front-loaded: traversal, return structure, and parameter details.

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

Completeness5/5

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

Given no annotations, an output schema is present (so return values are covered), and the tool has only 2 simple parameters. The description fully covers purpose, behavior, and parameter usage, making it complete.

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

Parameters5/5

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

The schema has 0% description coverage, so the description fully supplements parameter meanings. It provides concrete examples for 'concept' and specifies valid range and default for 'depth' (1–5, default 3), which is not in the schema.

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

Purpose5/5

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

The description clearly states the tool traverses the AgentForce knowledge graph and returns prerequisites and dependents. It uses a specific verb ('Traverse') and resource ('AgentForce knowledge graph'), and distinguishes from sibling tools like search_concepts or list_concepts by focusing on graph traversal.

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

Usage Guidelines3/5

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

The description implies usage for exploring relationships from a concept, but does not explicitly state when to use this tool versus alternatives (e.g., search_concepts, get_prerequisites). No when-not-to-use conditions are provided.

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

resolution_pathAInspect

Trace the exact path that determines an AgentForce autonomous resolution event.

This is the $2/resolution billing path — what the agent must traverse correctly to resolve autonomously without human handoff.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.7/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It discloses that this is the billing path and that it relates to autonomous resolution without handoff, but does not mention whether it is read-only, what side effects exist, or what the output looks like. The description adds some context but lacks full behavioral details.

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

Conciseness5/5

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

The description is two sentences, front-loaded with the core purpose, and contains no unnecessary words. It earns its place efficiently.

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

Completeness4/5

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

Given that there are no parameters and an output schema exists (though not shown), the description is relatively complete. However, it could briefly mention what the output contains to be fully self-contained, so a 4 is appropriate.

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

Parameters4/5

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

The tool has zero parameters, so the description does not need to add parameter-level semantics. The baseline for 0 parameters is 4, and the description is sufficient for a parameterless tool.

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 traces the resolution path for AgentForce autonomous billing events. It uses a specific verb and resource, but does not explicitly distinguish from sibling tools like evaluate_trust_chain or verify_source, so a 4 is appropriate.

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

Usage Guidelines3/5

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

The description implies the tool is used to understand the billing path for autonomous resolution, but does not provide explicit guidance on when to use it versus sibling tools or when not to use it. This is adequate but not strong.

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

route_queryAInspect

Route an AgentForce question to the optimal model and reasoning approach via graph depth.

The CKG graph IS the router. AgentForce dependency chains (e.g. Einstein Trust Layer → Data Cloud → NVIDIA NIM → Resolution Criteria) have typed hops that signal reasoning complexity deterministically. No heuristic: the graph decides.

Routing table: hop_depth 1 → haiku · direct (simple concept lookup) hop_depth 2 → sonnet · generic_cot (moderate chain) hop_depth 3+ → opus · sparql_cot (deep dependency, structured reasoning)

Args: question: Concept name or natural language question about Salesforce AgentForce.

Returns: model_tier + reasoning_approach + why + context subgraph to inject before LLM call.

ParametersJSON Schema

Name	Required	Description	Default
`question`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior5/5

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

With no annotations, the description fully discloses the behavioral logic: deterministic routing via graph depth with a clear routing table. It explains that 'No heuristic: the graph decides' and specifies return values, offering complete transparency.

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 well-structured: a concise summary, then mechanism explanation, routing table, and input/output definitions. It is slightly verbose with 'No heuristic: the graph decides,' but overall efficient and front-loaded.

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

Completeness4/5

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

The description covers purpose, input semantics, algorithmic behavior, and return structure. With an output schema present, the agent can infer return format. It is nearly complete but could mention error handling or input constraints.

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

Parameters4/5

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

The description defines the single parameter 'question' as 'Concept name or natural language question about Salesforce AgentForce,' adding significant meaning beyond the schema's type definition. With 0% schema coverage, this compensates well, though examples could enhance clarity.

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

Purpose5/5

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

The description explicitly states the tool's function: 'Route an AgentForce question to the optimal model and reasoning approach via graph depth.' It uses a specific verb ('route') and resource ('AgentForce question'), and the routing table distinguishes it from siblings.

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

Usage Guidelines3/5

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

The description implies usage for routing questions based on graph depth but lacks explicit guidance on when to choose this tool over siblings like 'query_ckg' or 'verify_source'. No 'when not to use' or alternative comparisons are provided.

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

search_conceptsAInspect

Find AgentForce concepts by keyword.

Args: query: Search term — e.g. 'resolution', 'trust', 'grounding', 'action', 'NIM'.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.9/5.0

Behavior2/5

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

No annotations are provided, so the description must bear the full burden of behavioral transparency. It only states the operation, but does not disclose whether it is read-only, any side effects, rate limits, or pagination behavior. For a search tool, this lack of safety information is a significant gap.

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

Conciseness4/5

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

The description is concise, with only two sentences and a single example list. However, the 'Args:' section is somewhat redundant for a single parameter. The key information is front-loaded.

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

Completeness4/5

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

Given that an output schema exists, the description does not need to explain return values. It covers the core purpose and input sufficiently. Missing details like error handling or pagination are minor for a simple search tool.

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

Parameters4/5

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

The parameter 'query' has a schema description coverage of 0%, meaning the schema provides no description. The description adds meaningful context by specifying the parameter as a search term and providing examples (e.g., 'resolution'). This adds significant value beyond the schema.

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

Purpose5/5

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

The description explicitly states the verb 'Find', the resource 'AgentForce concepts', and the method 'by keyword'. It distinguishes from the sibling tool 'list_concepts' which likely lists all concepts, making the purpose unambiguous.

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

Usage Guidelines4/5

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

The description provides examples of search terms (e.g., 'resolution', 'trust') implying when to use this tool. It does not explicitly mention when not to use it or alternatives, but the sibling context suggests that 'list_concepts' is for retrieving all concepts. The guidance is clear but lacks explicit exclusions.

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

verify_sourceAInspect

Return the source URL and content hash for an AgentForce concept node.

Audit chain: edge answer → graph commit → source_hash → source_url (fetch hint)

Verification: curl -s | sha256sum # compare output to source_hash

Args: concept: Concept label (partial match supported). receipt: If True, also return a signed BoundaryAttest receipt envelope (experimental-interop-v0.1) binding concept_label + source_url + source_hash + timestamp to this server's ed25519 session key.

ParametersJSON Schema

Name	Required	Description	Default
`concept`	Yes
`receipt`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.6/5.0

Behavior3/5

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

The description explains the main outputs: source URL, content hash, and optionally a signed receipt. It describes the audit chain and verification method. However, it does not disclose error handling (e.g., what happens if concept is not found), required permissions, or rate limits. Since no annotations are provided, the description carries the full burden, and it is moderately transparent but misses some important behavioral traits.

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 front-loaded with the main purpose sentence, then structured into sections (audit chain, verification, args). Each sentence adds value, though the curl command could be shortened. Overall it is well-organized and not overly verbose.

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

Completeness3/5

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

Given that an output schema exists (not shown), the description is adequate but not complete. It explains the main outputs and includes the optional receipt. However, it lacks error conditions, required prerequisites, and does not mention when to use this tool over siblings. For a tool with no annotations, more context would improve completeness.

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

Parameters4/5

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

The description adds significant meaning beyond the input schema. For 'concept', it says 'Concept label (partial match supported).' For 'receipt', it explains the experimental receipt envelope and what it binds. This is valuable context that the schema alone (string and boolean with default) does not provide. The only minor gap is that it doesn't specify case sensitivity or format for 'concept'.

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

Purpose5/5

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

The description clearly states the tool's purpose: 'Return the source URL and content hash for an AgentForce concept node.' This is a specific verb-resource combination that immediately communicates the tool's function. The additional details about audit chain and verification further clarify the scope, distinguishing it from sibling tools like evaluate_trust_chain or export_benchmark_receipt.

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?

The description provides no guidance on when to use this tool versus any of its siblings. It does not mention when not to use it, what prerequisites exist, or how it relates to tools like evaluate_trust_chain or get_prerequisites. The only usage hint is the curl command, which is more of a verification step than a usage guideline.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

9 tool updatesv0.9.1Jul 29, 2026
- First observedevaluate_trust_chain
- First observedexport_benchmark_receipt
- First observedget_prerequisites
- First observedlist_concepts
- First observedquery_ckg
- First observedresolution_path
- First observedroute_query
- First observedsearch_concepts
- First observedverify_source

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.9/5.0

Scored 2026-07-29 14:00 across 9 tools

Disambiguation4/5

Most tools have distinct purposes, but 'get_prerequisites' overlaps with the prerequisite functionality of 'query_ckg', which could cause confusion. Overall, boundaries are mostly clear.

Naming Consistency4/5

Most tools follow a verb_noun pattern, but 'resolution_path' is a noun_noun, breaking the consistency. Otherwise, naming is predictable.

Tool Count5/5

With 9 tools, the set is well-scoped for a knowledge graph server, covering query, exploration, and trust verification without being excessive or thin.

Completeness4/5

The tool set covers core exploration, verification, and trust operations. However, a dedicated tool to retrieve full concept details is missing, creating a minor gap.

Maintenance

ActivityMaintained

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Related MCP Connectors

NVIDIA AI CKG A
io.github.Yarmoluk
NVIDIA AI knowledge graphs — 20 domains. 4x F1, 11x fewer tokens, SHA-256 provenance. MCP-native.
Knowledge & Memory RAG Systems
17
NVIDIA NemoClaw CKG A
io.github.Yarmoluk
NVIDIA NemoClaw knowledge graph — 55 nodes, F1 0.576 (+269% vs RAG), 11x fewer tokens. MCP-native.
Knowledge & Memory RAG Systems
812
DocsMint A
io.github.HiAi-gg
Cloud or self-hosted knowledge for AI agents: hybrid search, reranking, GraphRAG, scoped MCP tools.
Documentation Access Knowledge & Memory RAG Systems
21171
Agentverse Memory
io.github.fetchai
Graph-native persistent memory for AI agents — 33 MCP tools, zero-LLM writes.
Knowledge & Memory Autonomous Agents
2

Related MCP Servers

Agent Module
Autonomous Agents Knowledge & Memory Legal & Compliance
AgentModule
A
license
A
quality
C
maintenance
Agent-native knowledge infrastructure. Deterministic, vertical-specific knowledge bases for autonomous agent consumption via MCP. Ethics modules mapped to EU AI Act articles. Free 24-hour trial.
Updated 6 months ago (2026-04-04 02:42 UTC)
7
2
MIT
RAG Knowledge Graph MCP
RAG Systems Knowledge & Memory
CSOAI-ORG
A
license
Not graded
quality
A
maintenance
RAG Knowledge Graph - MCP server providing AI-powered tools and automation by MEOK AI Labs
Updated 20 days ago (2026-09-04 12:42 UTC)
6 npm
68 PyPI
MIT
ckg-mcp
Knowledge & Memory RAG Systems
Yarmoluk
A
license
A
quality
A
maintenance
A Compact Knowledge Graph MCP server providing pre-structured domain knowledge as a routing layer for agent stacks, enabling efficient structural queries (e.g., prerequisites, dependency chains) without hallucinations.
Updated 2 months ago (2026-07-28 17:48 UTC)
4
4
MIT
sfgraph
CRM Knowledge & Memory
ryanStark24
F
license
Not graded
quality
C
maintenance
A local, privacy-first knowledge graph for Salesforce orgs. It live-syncs your org to a SQLite + vector index on your machine and exposes 26 MCP tools to Cursor, Claude Code/Desktop, and VS Code, so the AI you already use can reason about Apex, LWC, Flow, Vlocity, OmniStudio, security, and integrations without your code or schema ever leaving your laptop.
Updated 3 months ago (2026-06-11 13:41 UTC)
-

ckg-agentforce

What it is

Source provenance — verifiable to the byte

What developers are actually hitting

Declared relationships, not confidence scores

A/B — AgentForce domain, local models, no GPU

Install

Tools

route_query(question) — CKG Router

What's in the graph

Pro access — all 97 domains

Sources

Benchmark (KRB v0.6.2 locked)

Licensing

EVAL

Want this for your domain?

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

`route_query(question)` — CKG Router