Return 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 | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
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.