Skip to main content
Glama

Nebelus

by ai.nebelus.api
OverviewDiscussionsAdmin

Attach sub-agent

attach_sub_agent

Bind another of this org's agents to this one, as a callable tool or a handoff target.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNoHow the sub-agent is wired: 'as_tool' (parent calls it like a tool) or 'handoff' (control transfers to it).
agent_idYesTarget agent's id (from list_agents / create_agent / get_catalog view=agents).
instructionNoOptional guidance for the parent on when/how to use the sub-agent.
sub_agent_idYesId of the org agent to bind (cannot be this agent itself or a platform agent).
stream_to_clientNoWhether the sub-agent's output streams to the end user (default off).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • addedInput schema / properties / agent_id / description
      Added value: +"Target agent's id (from list_agents / create_agent / get_catalog view=agents)."
    • addedInput schema / properties / instruction
      Added value: +{
+  "description": "Optional guidance for the parent on when/how to use the sub-agent.",
+  "type": "string"
+}
    • addedInput schema / properties / mode
      Added value: +{
+  "description": "How the sub-agent is wired: 'as_tool' (parent calls it like a tool) or 'handoff' (control transfers to it).",
+  "enum": [
+    "as_tool",
+    "handoff"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / stream_to_client
      Added value: +{
+  "description": "Whether the sub-agent's output streams to the end user (default off).",
+  "type": "boolean"
+}
    • addedInput schema / properties / sub_agent_id / description
      Added value: +"Id of the org agent to bind (cannot be this agent itself or a platform agent)."
  2. First observed

TDQS

B3.4/5.0
Behavior3/5

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

Annotations declare readOnlyHint=false and destructiveHint=false, but they do not fully convey the mutating nature. The description clarifies that this is a binding action that changes the parent agent's wiring, which is useful. However, it does not disclose side effects such as whether previous bindings are overwritten, whether the operation is reversible (detach_sub_agent exists), or whether permissions are required. Given that annotations are present but sparse, this is adequate but not comprehensive.

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 a single, concise sentence that front-loads the core action and purpose. It avoids redundancy with the schema, states the two binding modes, and stays within reasonable length. It could potentially mention the sibling detach tool, but that's not essential for conciseness.

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

Completeness3/5

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

Given that this is a binding operation with five parameters and no output schema, the description is relatively complete. It tells the agent the purpose and modes, and the schema handles parameter semantics. However, it lacks guidance on when to choose 'as_tool' vs 'handoff' and does not mention potential constraints (e.g., cannot bind to itself) that are already in the schema. For a moderately complex tool, this is acceptable but not exhaustive.

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

Parameters3/5

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

Schema description coverage is 100%, so all five parameters (agent_id, sub_agent_id, mode, instruction, stream_to_client) are already documented in the schema with descriptions. The tool description itself adds no new information about parameters, so the baseline of 3 applies. It correctly does not repeat schema details, but it also does not add extra context about parameter relationships (e.g., mode requires certain combinations).

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 begins with a clear verb ('Bind') and resource ('another of this org's agents to this one'), and it specifies the two binding modes (callable tool or handoff target). This distinguishes it from attach_ai_tool and attach_mcp_server, which are about external resources. However, it could be more explicit that it is specifically about agent-to-agent wiring, but the first sentence is 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 implies when to use it (when you want to attach one agent to another) but does not explicitly state when NOT to use it or mention alternatives like detach_sub_agent for removal. The input schema's required fields imply the context, but there's no direct guidance on selecting this over sibling attach_* tools beyond the resource type.

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

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

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources