NVIDIA NemoClaw knowledge graph — 55 nodes, F1 0.576 (+269% vs RAG), 11x fewer tokens. MCP-native.
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/5 across 8 of 8 tools scored. Lowest: 3.3/5.
Several tools traverse the knowledge graph (ask_nemoclaw, query_ckg, query_intersect, get_prerequisites), creating potential overlap in purpose. However, each has a distinct focus—Q&A, subgraph extraction, conjunctive queries, and prerequisite chains—and the detailed descriptions help agents choose appropriately.
Tool names follow a consistent verb_noun pattern (ask, get, list, query, route, search, verify). The slight inconsistency lies in the verbs themselves—'ask' vs. 'query' vs. 'route'—which could confuse agents, but the pattern is otherwise uniform.
With 8 tools, the server is well-scoped for a knowledge graph system. Each tool serves a distinct function, and the count is neither too sparse nor overwhelming.
The tool set covers the full range of expected operations for a read-only knowledge graph: search, query, specific traversals, domain listing, and source verification. No obvious gaps exist for the stated purpose.
ask_nemoclawBInspectAnswer a question about NVIDIA NemoClaw by traversing the knowledge graph.
Covers: agent runtimes (OpenClaw/Hermes/Deep Agents), OpenShell platform, inference routing, network policy, security layers, deployment paths, progressive tool disclosure, managed MCP servers, snapshots, shields, FOX Blueprint, Nemotron 3 Ultra ecosystem, and platform support.
Args: question: Your question about NemoClaw concepts or architecture.
| Name | Required | Description | Default |
|---|---|---|---|
| question | 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 carries full burden. It describes knowledge graph traversal but does not disclose error handling, limits, or authentication requirements. Some behavioral context is implied but incomplete.
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 with a clear first sentence, a bullet-like list of covered topics, and an Args section. It is concise and front-loaded, though could be slightly shorter.
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 the presence of an output schema (not shown but indicated), the description covers the tool's purpose and scope adequately. However, it lacks details on behavior for out-of-scope questions, error states, and other edge cases.
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 sole parameter 'question' has 0% schema description coverage, meaning the schema only provides the name and type. The description adds only 'Your question about NemoClaw concepts or architecture,' which does not sufficiently compensate for the lack of schema detail.
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 it answers questions about NVIDIA NemoClaw by traversing the knowledge graph, and lists specific covered topics. This distinguishes it from siblings like search_concepts and query_ckg.
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?
No guidance is provided on when to use this tool versus alternatives, when not to use it, or prerequisites. The description does not mention context or exclusions.
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 upstream prerequisite chain for a NemoClaw concept.
Useful for understanding what a concept depends on end-to-end.
Args: concept: Exact or partial concept label.
| Name | Required | Description | Default |
|---|---|---|---|
| concept | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description lacks behavioral details such as authentication requirements, rate limits, error handling, or what happens if the concept is not found. The description only states the action, not its side effects or constraints.
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 fairly concise with two clear sentences and an informal args line. It is front-loaded with the primary action, but the args section is minimally structured. Still, it avoids unnecessary verbosity.
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 the tool has an output schema (not shown) and only one parameter, the description is minimal but covers the essential purpose. However, it omits behaviors like pagination, ordering, or example usage, leaving some gaps for a complete understanding.
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 zero parameter descriptions, so the description adds crucial meaning: the concept parameter accepts 'Exact or partial concept label'. This clarifies the input format beyond the schema's basic type definition.
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 upstream prerequisite chain for a NemoClaw concept, which is a specific verb-resource pair. It distinguishes itself from siblings like search_concepts and query_ckg by focusing on prerequisites.
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 a use case ('useful for understanding what a concept depends on end-to-end') but does not explicitly state when not to use it or suggest alternative tools. Guidance is implied but incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_domainsAInspectList available domains in this CKG server.
| 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 only says 'List available domains' without disclosing side effects, permissions, or whether it is read-only. For a simple list operation, this is minimal but not sufficient.
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?
Single sentence, zero waste. Every word earns its place.
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 parameters and an output schema exists, the description is nearly complete. However, it could mention that domains are server-specific or that no prerequisites are needed.
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, and schema description coverage is 100%. Baseline 4 is appropriate; the description adds no parameter info because there are none.
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' and the resource 'domains', and distinguishes from sibling tools like search_concepts or query_ckg which have different purposes.
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?
No guidance on when to use this tool versus alternatives, nor any context about prerequisites or exclusions. The description only states what it does, not when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
query_ckgAInspectReturn the typed subgraph around a NemoClaw concept.
Args: concept: Exact or partial concept label (e.g. 'OpenClaw', 'NetworkPolicy', 'L7Proxy'). depth: Traversal hops (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?
No annotations are provided, so the description carries full burden. It describes the input behavior (concept matching, traversal depth), but does not disclose potential side effects, permissions, rate limits, or whether the operation is purely read-only. However, the action of returning a subgraph implies a query, and the description is minimally sufficient.
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: a single sentence stating the purpose followed by a brief Args list. It is front-loaded with the main action, and every sentence adds value. No unnecessary words or repetition.
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 the tool has only two parameters and an output schema exists (reducing need to describe return values), the description is complete enough. It covers input semantics, defaults, and examples. However, it omits potential error conditions or edge cases (e.g., what happens if concept is not found), and does not mention any dependencies or prerequisites.
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 description coverage is 0%, so the description fully explains both parameters. It defines 'concept' as exact or partial with examples, and 'depth' as traversal hops (1–5) with a default of 3. This adds critical meaning beyond the schema's type and title, enabling correct usage.
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 a 'typed subgraph around a NemoClaw concept', specifying the verb ('Return'), resource ('typed subgraph'), and scope ('around a NemoClaw concept'). This differentiates it from siblings like search_concepts (which likely searches for concepts) and get_prerequisites (which retrieves dependencies). The inclusion of example concept labels further clarifies the 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 context on when to use the tool (e.g., to retrieve a subgraph for a concept) and gives parameter examples, but it does not explicitly state when not to use it or compare to alternatives like ask_nemoclaw or route_query. Usage is implied but not explicitly bounded.
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?
No annotations exist, so the description carries full burden. It discloses exact semantics: 'Every branch is an exact set of declared edges, so the intersection is exact,' and describes failure behavior: 'A relation missing from the graph produces an empty result, never a guess.' It also explains return format and empty-branch reporting.
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 structured into clear paragraphs for overview, behavioral guarantees, Args, and Returns. It is long but every sentence earns its place—no fluff, all high-value information. Front-loaded with the essential purpose and comparison.
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 the tool's complexity (5 params, 0% schema coverage), the description is complete: it explains all parameters, edge cases, return format, and failure modes. It even details the returned Markdown structure and empty-result handling, so no gaps remain.
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%, but the description fully compensates with detailed 'Args' section covering every parameter: branch syntax (bare anchor vs '>' path), depth range/default/ignored cases, direction options, mode semantics, and limit behavior (max, default, true count always shown). This goes far 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 opens with a specific verb+resource: 'Answer a conjunctive query: concepts reachable from EVERY anchor at once (A AND B).' It clearly distinguishes itself from sibling query_ckg by contrasting single-anchor walk vs. multi-anchor intersection, and explains the tool's role as 'the shape of most real questions'.
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?
Usage guidelines are explicit: 'query_ckg walks outward from one concept. This intersects the reachable sets of two or more...' and 'Neither anchor alone answers it; the answer lives in the overlap.' This tells the agent exactly when to choose this tool over the sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
route_queryAInspectRoute a NemoClaw question to the optimal model and reasoning approach via graph depth.
The CKG graph IS the router. NemoClaw's dependency chains (e.g. OpenShell → L7Proxy → CorporateCA → mTLS) are deep and typed — hop depth is a deterministic complexity signal. No heuristic: the graph decides which model and reasoning approach to use.
Routing table: hop_depth 1 → haiku · direct (single concept lookup) hop_depth 2 → sonnet · generic_cot (moderate chain) hop_depth 3+ → opus · sparql_cot (deep chain, structured reasoning required)
Args: question: Concept name or natural language question about NemoClaw / OpenShell.
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?
No annotations are provided, so the description carries full burden. It explains the routing logic and returns, but does not mention side effects, authorization needs, or whether the tool is read-only. The description is somewhat transparent but not fully.
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 with a summary, explanatory paragraph, routing table, and Args/Returns. It is generally concise but includes some technical jargon (e.g., 'OpenShell → L7Proxy → CorporateCA → mTLS') that could be minimized.
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 the tool's complexity (routing based on graph depth), the description provides sufficient context: the routing logic, the table, and the return fields. The output schema exists, so the description's return info is a helpful supplement.
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 sole parameter 'question' lacks schema descriptions (0% coverage). The description adds meaningful context: it specifies that the question can be a concept name or natural language query about NemoClaw/OpenShell, which guides the agent.
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 'Route' and the resource 'NemoClaw question', and distinguishes from siblings by explaining the unique graph-depth-based routing approach. The routing table further concretizes the 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 explains the deterministic complexity signal via hop depth, giving context for when to use this tool. However, it does not explicitly state when not to use it or name alternatives, leaving some room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_conceptsAInspectFuzzy search for NemoClaw concepts by name or keyword.
Args: query: Partial name or keyword (e.g. 'policy', 'inference', 'agent').
| 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 exist, so the description must disclose behavior. It only mentions 'fuzzy search' but omits whether the tool is read-only, what happens on no matches, or any side effects. This is insufficient.
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 with two sentences, no redundancy, and the key action is front-loaded. Every word adds value.
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 single-parameter search tool with an output schema, the description covers the basics but lacks details like result limits or the domain of 'concepts'. It is adequate but not thorough.
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 coverage is 0%, but the description explains the parameter 'query' as 'Partial name or keyword' with examples. This adds meaningful context beyond the schema's bare title, helping the agent provide appropriate input.
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 it performs fuzzy search for NemoClaw concepts by name or keyword, with examples. It distinguishes itself from siblings like ask_nemoclaw (for questions) and query_ckg (for knowledge graph) by specifying the resource type.
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?
No guidance is provided on when to use this tool vs alternatives like ask_nemoclaw or query_ckg. The description does not mention exclusions or context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_sourceAInspectReturn the authoritative source URL and content hash for a NemoClaw concept node.
Every node in the CKG was declared from a specific source document. This tool returns the source URL (where the node came from) and the SHA-256 hash of that document's bytes at extraction time. A hash mismatch on re-fetch means either the source has changed (stale edge — re-extract) or the graph was patched without re-fetching (silent edit — investigate).
Audit chain: edge answer → graph commit → source_hash → source_url (fetch hint)
Verification: curl -s | sha256sum # compare output to source_hash
Args: concept: Exact or partial concept label (e.g. 'CorporateCA', 'L7Proxy').
| 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 provided, the description fully discloses the tool's behavior: it returns source URL and SHA-256 hash, and explains implications of hash mismatches. It lacks details on authentication or rate limits, but the read-only nature is clear from context.
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 with a clear purpose statement, audit chain explanation, verification command, and parameter details. It is somewhat verbose but each part adds value; no wasted sentences.
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 the output schema exists, the description appropriately focuses on inputs and usage intent. It explains the return values (source URL and hash) and their interpretation, making the tool fully understandable for an agent.
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 single parameter 'concept' is explained with examples and the note that it can be exact or partial. Since schema coverage is 0%, the description adds necessary meaning beyond the schema definition.
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 authoritative source URL and content hash for a NemoClaw concept node, using specific verbs and resources. It distinguishes itself from siblings by focusing on verification, which is unique among the listed tools.
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 clear context on when to use the tool, explaining the audit chain and verification process. It gives practical interpretation of hash mismatches. However, it does not explicitly state when not to use it or compare it directly to alternatives.
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.