Salesforce AgentForce knowledge graph — 40 nodes, Einstein Trust Layer, 11x fewer tokens than RAG.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.1/5 across 10 of 10 tools scored.
Most tools serve clearly distinct roles: querying, searching, routing, and verification are separate concerns. However, query_ckg and get_prerequisites both return prerequisite information, which could cause an agent to select the wrong tool when a simple prerequisite list is needed. The descriptions do clarify the difference (generic traversal vs. full ordered chain), but some ambiguity remains.
The vast majority of tools follow a consistent snake_case verb_noun pattern, such as evaluate_trust_chain, list_concepts, and route_query. The only exception is resolution_path, which is a noun phrase rather than a verb_noun, making it slightly less predictable. This is a minor deviation from an otherwise strong pattern.
With 10 tools, the server has a well-scoped surface area for a knowledge graph that requires discovery, traversal, routing, and audit capabilities. Each tool represents a distinct operation, and there are no redundant or unnecessary entries. This falls comfortably within the ideal range for a domain-specific server.
The toolset covers the full read-side lifecycle of the knowledge graph: discovery, traversal, path analysis, routing, and trust verification. It also includes specialized tools for benchmarking and source verification, which are unusual but valuable additions. No obvious critical gaps exist, such as missing search or traversal capabilities.
evaluate_trust_chainAInspectReturn 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).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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_receiptAInspectGenerate 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).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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_prerequisitesAInspectReturn 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'.
| Name | Required | Description | Default |
|---|---|---|---|
| concept | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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_conceptsAInspectList all 40 AgentForce concepts in this knowledge graph.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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_ckgAInspectTraverse 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).
| Name | Required | Description | Default |
|---|---|---|---|
| depth | No | ||
| concept | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
query_intersectAInspectAnswer a conjunctive query: concepts reachable from EVERY anchor at once (A AND B).
query_ckg walks outward from one concept. This intersects the reachable sets of two or more, which is the shape of most real questions — "the component that satisfies A AND applies to B". Neither anchor alone answers it; the answer lives in the overlap.
Every branch is an exact set of declared edges, so the intersection is exact. A concept appears only if a declared path reaches it from each anchor. A relation missing from the graph produces an empty result, never a guess.
Args:
branches: Two or more branches. Either a bare anchor ("TensorRT-LLM"), which takes
everything within depth hops, or an anchor plus an explicit relation path using
'>' ("TensorRT-LLM > REQUIRES > ENABLES"), where each relation replaces the
frontier. '*' matches any relation. Mix both forms freely.
depth: Hops for bare-anchor branches, 1-5 (default 2). Ignored for explicit paths.
direction: 'out' follows dependencies, 'in' follows them backwards, 'both' (default).
mode: 'AND' (default) intersects branches; 'OR' unions them.
limit: Max concepts listed, 1-200 (default 40). The true count is always shown.
Returns: Markdown with the query plan and its per-step set sizes, then the answer set with taxonomy tags. Reports which branch was empty when the intersection is empty.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | AND | |
| depth | No | ||
| limit | No | ||
| branches | Yes | ||
| direction | No | both |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so thoroughly. It states that every branch is an exact set of declared edges, so intersection is exact, that a missing relation produces an empty result (never a guess), that the true count is always shown, and that empty branches are reported. These are meaningful behavioral guarantees beyond the basic schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose, then flows into usage guidance, behavior, and concise parameter explanations. Every sentence adds value, with no fluff or repetition. Despite its length, it is efficiently packed with necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no schema descriptions, and a complex branching syntax, the description covers all needed aspects: when to use, parameter semantics, edge cases (empty results), and return format (Markdown with query plan, per-step sizes, and answer set). It is fully sufficient for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description is the only source of parameter meaning. It explains branches syntax in detail (bare anchor vs explicit path with '>', wildcard '*'), depth range (1-5, default 2, ignored for explicit paths), direction ('out', 'in', 'both'), mode ('AND' vs 'OR'), and limit (1-200, default 40, with true count always shown). This far exceeds what the raw schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific, actionable purpose: "Answer a conjunctive query: concepts reachable from EVERY anchor at once (A AND B)." It then explicitly contrasts with the sibling tool query_ckg, making it clear this tool handles multi-anchor intersections rather than single-concept traversal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description identifies the exact use case: "the shape of most real questions — the component that satisfies A AND applies to B" and notes that "Neither anchor alone answers it; the answer lives in the overlap." It also names the alternative query_ckg, providing explicit guidance on when to use this tool versus that one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
resolution_pathAInspectTrace 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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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_queryAInspectRoute 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.
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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_conceptsAInspectFind AgentForce concepts by keyword.
Args: query: Search term — e.g. 'resolution', 'trust', 'grounding', 'action', 'NIM'.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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_sourceAInspectReturn 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.
| Name | Required | Description | Default |
|---|---|---|---|
| concept | Yes | ||
| receipt | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Sign in to create a connector for this server.