Skip to main content
Glama

delegate

Offload large, mechanical, or exploratory coding work to a sandboxed sub-agent that reads the repository and returns a written report, saving your context.

Instructions

Run a bounded sub-agent on the user's NVIDIA NIM account and return its written report.

Reach for this to keep large, mechanical, or exploratory work out of your own context: tracing how a feature flows across many files, auditing a directory for a pattern, summarising an unfamiliar module or dependency, drafting a migration plan, reviewing a diff. The sub-agent reads the repository itself and spends NIM tokens doing it; you only receive the finished report.

task must stand on its own. The sub-agent cannot see this conversation, your open files, the user's last message, or anything you have already worked out - it starts cold at the repo root. Spell out what to look at, what to produce, and what "done" means. Good: "Find every call site of load_config under submcp/ and list each as path:line with one line on how the result is used; answer as a markdown list." Bad: "look into that config thing we discussed".

Parameters: task - self-contained instructions, including the output format you want back. profile - "general" (default), "researcher", "coder", or "reviewer". Researcher for read-and-explain sweeps, coder for focused edits, reviewer for critique. files - paths to hand over up front so the sub-agent doesn't waste steps hunting. write - allow file edits. Off by default, and ignored entirely unless the server was started with SUBMCP_ALLOW_WRITE=1. Leave it off for investigation. model - override the NIM model for this run (default stepfun-ai/step-3.7-flash). max_steps - tool-call budget for this run (default 12).

Returns a markdown report: the sub-agent's findings, plus the model used, how many steps it took, which tools it called, and any files it changed. The sub-agent is sandboxed to the server's root directory, is read-only unless write=True, cannot run shell commands unless the operator enabled SUBMCP_ALLOW_SHELL, and refuses to read secrets (.env, private keys, credentials files).

For several independent subtasks, call delegate_parallel once instead of calling this tool repeatedly - it runs them concurrently over one connection.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
taskYes
filesNo
modelNo
writeNo
profileNogeneral
max_stepsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

No annotations are provided, so the description fully bears the burden of behavioral disclosure. It details that the sub-agent starts cold with no conversation context, is sandboxed to the root, is read-only unless `write=True`, requires SUBMCP_ALLOW_WRITE for write to take effect, cannot run shell commands without SUBMCP_ALLOW_SHELL, and refuses to read secrets. It also explains the return format and steps taken. This is comprehensive and adds far beyond any annotations.

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 long but well-structured with clear sections: purpose, usage, task requirements, parameter list, return value, and safety constraints. Every sentence adds valuable information, from examples of good and bad tasks to the explicit mention of the parallel sibling. It is dense and efficient despite its length.

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's complexity (6 parameters, sub-agent execution, environment-dependent behavior, permissions, and sandboxing), the description covers all essential aspects: when to use, how to construct the task, parameter nuances, return value, safety/read-only guarantees, and pointer to the parallel variant. The output schema is optionally present, but the description even describes the markdown report contents, so no gaps remain.

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 description coverage is 0%, so the description must fully compensate, and it does. Each parameter is explained with its purpose, default, and guidance (e.g., `profile` options with what each is for, `files` as upfront path hints, `write` with environment caveat, `model` with default, `max_steps` as tool-call budget). The `task` parameter also includes a good/bad example, adding rich semantics beyond the 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 opens with a specific verb+resource: 'Run a bounded sub-agent on the user's NVIDIA NIM account and return its written report.' This clearly identifies what the tool does and its output. It further distinguishes itself from the sibling `delegate_parallel` by specifying it is for a single delegation, not parallel subtasks.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage guidance is explicit: 'Reach for this to keep large, mechanical, or exploratory work out of your own context' followed by concrete example use cases. It also provides an exclusion: 'For several independent subtasks, call `delegate_parallel` once instead.' This tells agents exactly when to use this tool vs. alternatives.

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

Install Server

Other Tools

Latest Blog Posts

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/Animuni-Express/SubMCP'

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