ckg-agentforce

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.9.1
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.
Average 4.1/5 across 9 of 9 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 1 community issues answered or closed in the last 6 months
- 93 commits in the last 12 weeks
- Last stable release on July 22, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behaviors. It only states it lists concepts, but does not mention read-only nature, performance characteristics, or result format. Minimal transparency.
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, front-loaded sentence with no wasted words. It efficiently conveys the core purpose.
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, the description is largely complete. It could mention if pagination or rate limits exist, but given the simplicity, it is adequate.
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 no parameters, so the description does not need to add parameter info. Since schema coverage is 100% (vacuously), and the description adds no parameter details, baseline 4 is appropriate.
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 specifies the action ('List') and the resource ('all 40 AgentForce concepts'), making it distinct from sibling tools like search_concepts which implies filtering. However, it does not explicitly differentiate itself in the text.
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 guidance is provided on when to use this tool versus alternatives (e.g., search_concepts for filtered queries). The description lacks context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 only states basic functionality (find by keyword) without disclosing behaviors such as case sensitivity, pagination, result limits, or whether it's read-only. The output schema exists but the description does not hint at what is returned.
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 very concise with a main sentence and a single parameter explanation. It is front-loaded with the core action. A slightly more structured format with explicit sections could improve scannability, but it remains efficient and to the point.
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 the tool has only one required parameter and an output schema, the description is minimal but sufficient for basic understanding. However, it lacks details on output format, maximum results, or any constraints, which would enhance completeness for an agent.
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?
With 0% schema description coverage, the description adds critical meaning to the sole parameter 'query' by providing examples ('resolution', 'trust', 'grounding', 'action', 'NIM') and clarifying it is a free-text search term. This significantly aids correct invocation.
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 'Find', the resource 'AgentForce concepts', and the method 'by keyword'. It distinguishes itself from the sibling 'list_concepts' which likely lists all concepts. The purpose is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an example of query terms but does not explicitly state when to use this tool versus alternatives like 'list_concepts' or 'query_ckg'. There is no guidance on when not to use it or prerequisites, leaving the context implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides some behavioral context by noting it is a billing path and that the agent must traverse it correctly. However, it lacks details on whether it is read-only, what happens if the path does not exist, or any side effects.
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?
Two concise sentences with no redundancy. The first sentence states the core function, the second adds meaningful billing context. Every word earns its place.
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 tool with no parameters and an existing output schema, the description sufficiently explains what the tool does and its significance. It could be more complete by mentioning typical use cases or output format, but that is partially covered by the output schema.
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, so the baseline is 4 per instructions. The description does not need to add parameter details, and the schema coverage is trivially 100%.
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 specifies a clear verb ('trace') and a unique resource ('exact path that determines an AgentForce autonomous resolution event'). It distinguishes from siblings (e.g., search_concepts, query_ckg) by focusing on a billing-specific resolution path.
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 or prerequisites. The description implies it is for tracing the resolution path but does not specify contexts that would make it the correct choice (e.g., after a resolution event).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully describes the tool's behavior: it returns a JSON with specific fields (source_hashes, graph_hash, etc.) and explains the ROI gate logic. It does not disclose side effects or state changes, but the tool appears to be read-only. No contradictions.
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 with bullet points for trust chain components, front-loading the purpose. It is moderately long but each sentence adds value. Could be slightly more concise but overall appropriate.
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 the complexity of trust chain evaluation and ROI analysis, and the presence of an output schema (ckg-trust-chain-v1), the description covers the key aspects: return format, decision rule, and trust chain fields. It is complete enough for an autonomous agent, though the output schema details are not elaborated.
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 schema coverage is 100%. Per the rubric, 0 parameters gives a baseline of 4. No additional parameter information is 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?
The description clearly states the tool returns a machine-readable JSON trust chain with ROI analysis and payment recommendation, specifying it's for autonomous agent consumption. It distinguishes itself by listing unique trust chain components that close the audit gap, differentiating from sibling tools like list_concepts or search_concepts.
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 explicit guidance on when to use this tool: for autonomous agents to evaluate trust, compare ROI, and autonomously purchase. It explains the decision rule (ROI gate) and mentions budget pre-authorization. However, it does not explicitly state when not to use it or compare to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden of behavioral disclosure. It explains that the tool generates a signed claim using an Ed25519 session key, that the signature is verifiable, and includes implementation references (GuardrailDecisionV1). It does not mention destructive behavior, rate limits, or idempotency, but the described action is inherently non-destructive.
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 three sentences: the first clearly states the tool's purpose, the second adds technical detail about the signature mechanism, and the third provides a concrete example. Every sentence earns its place, with no redundancy or fluff.
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 the tool has no parameters and an expected output, the description fully covers what the agent needs to know: the nature of the receipt, the signing key, verifiability, and a sample output. The presence of an output schema (true) reduces the need to describe return values, but the description still provides valuable context.
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 input schema has no parameters, so the description does not need to elaborate on parameter meanings. It adds context by explaining what the tool produces and including an example result, which is sufficient beyond baseline for zero-parameter tools.
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 uses a specific verb ('Generate') and resource ('signed BoundaryAttest receipt') clearly indicating the tool's output. It explicitly names the benchmark context ('agentforce CKG benchmark result'), distinguishing it from sibling tools like list_concepts or query_ckg.
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 does not provide explicit guidance on when to use this tool vs. alternatives or when not to use it. However, the context of exporting a signed receipt is narrow enough that the usage scenario is implicitly clear. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It clearly states the tool returns an ordered prerequisite chain, implying a read-only, non-destructive operation. It does not mention any side effects or special requirements, but the behavior is transparent enough.
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 concise: two sentences and an Args section. Every sentence adds value, and the structure is clean with front-loaded purpose.
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 the simple single-parameter input and the presence of an output schema, the description is complete. It does not need to explain return values since the output schema covers that.
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?
Schema description coverage is 0%, but the description adds meaning by specifying 'Target concept' and providing examples like 'Autonomous Resolution'. This compensates for the lack of schema property descriptions.
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 full ordered prerequisite chain for an AgentForce concept. Shows everything the concept depends on — the complete upstream path.' This distinguishes it from siblings like list_concepts and search_concepts.
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 implicitly indicates usage by showing concept examples, but it does not provide explicit when-to-use or when-not-to-use guidance compared to alternatives like resolution_path or evaluate_trust_chain.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, but description discloses query-only behavior, output structure (prerequisites, dependents, doc URLs), and depth limits. Adequate for a read-only graph traversal tool.
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?
Four concise sentences plus a clear Args block. Front-loaded purpose, no redundancy, every sentence adds value.
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?
Output schema exists, so return values may be documented there. Description covers relationship types and source URLs. Very good but could mention if traversal is bidirectional or depth scope more precisely.
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?
Schema coverage is 0%, but description thoroughly explains both parameters: concept with explicit examples, depth with range and default. Adds significant meaning 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?
Clear verb 'Traverse' with specific resource 'AgentForce knowledge graph' and result 'prerequisites and dependents'. Distinguishes from siblings like list_concepts and search_concepts by emphasizing relationship 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?
Implied usage via example concepts and explicit depth parameter, but no comparison to siblings like get_prerequisites or resolution_path. Lacks when-to-use vs alternatives context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the tool as deterministic based on graph depth, and lists return fields (model_tier, reasoning_approach, why, context subgraph). No annotations are provided, so the description carries the full burden. It is fairly transparent, though it does not mention error handling or auth requirements.
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: purpose, mechanism, routing table, args, returns. It is detailed but not excessively long. Some sentences are slightly verbose but add clarity.
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 single-parameter tool with an output schema, the description sufficiently covers input type and return fields. It lacks details on error scenarios or performance, but overall is complete enough for an AI agent to use.
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 explains that the 'question' parameter can be a 'Concept name or natural language question about Salesforce AgentForce,' adding meaningful context beyond the schema's title 'Question.' With schema description coverage at 0%, this compensates well.
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 action ('Route') and the target ('AgentForce question to optimal model and reasoning approach'). It distinguishes itself from sibling tools like list_concepts, search_concepts, and query_ckg by focusing on routing to models rather than querying or listing concepts.
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 routing logic with a table mapping hop depths to models and reasoning approaches. It explains that the CKG graph decides deterministically. However, it does not explicitly state when to avoid this tool or compare it with alternatives like query_ckg.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses behavior: returns URL and hash, optional receipt, and hints at network call (curl). Good transparency for a read-like operation, though could mention if side effects exist.
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 clear sections (audit chain, verification, args), but the code block and step-by-step instructions could be more concise. Still effective and not overly long.
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 the presence of an output schema (as per context signals), the description sufficiently covers what the tool does, what inputs are needed, and what behavior to expect. No gaps identified.
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?
Schema coverage is 0%, but description fully compensates. 'concept' is explained as label with partial match support. 'receipt' is explained as experimental interop envelope with details. Adds significant meaning 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?
The description clearly states the tool returns source URL and content hash for a concept node, with specific actions like audit chain and verification. It is distinct from sibling tools like search_concepts or list_concepts, which do not perform verification.
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 verifying source integrity via audit chain and curl/sha256sum, but does not explicitly state when to use this tool versus alternatives or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![ckg-agentforce MCP server](https://glama.ai/mcp/servers/Yarmoluk/ckg-agentforce/badges/card.svg)](https://glama.ai/mcp/servers/Yarmoluk/ckg-agentforce)

Score Badge

Copy to your README.md:

[![ckg-agentforce MCP server](https://glama.ai/mcp/servers/Yarmoluk/ckg-agentforce/badges/score.svg)](https://glama.ai/mcp/servers/Yarmoluk/ckg-agentforce)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/Yarmoluk/ckg-agentforce'

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