Skip to main content
Glama
Sign In
Orchestrator Python MCP Server

Orchestrator Python MCP Server

by eustin
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

orchestrate_get_agents

List all specialized orchestrator agent persona names, allowing you to spawn any of them by name through the subagent tool even if hidden from the catalog.

Instructions

List all specialized orchestrator agent personas. Each name is a registered OpenCode subagent ID, spawnable by name via the subagent tool even if hidden from the advertised subagent catalog.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "orchestrate_get_agents"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault
errorNo
agentsNo
successYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations, the description carries the behavioral burden and does well by disclosing that names are registered OpenCode subagent IDs, spawnable via the subagent tool even if hidden. It adds meaningful insight beyond 'list agents', though it omits non-critical details like pagination or ordering.

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?

Two tight sentences with no filler. The first states the primary purpose, and the second adds high-value operational nuance about spawnability and catalog visibility.

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?

For a zero-parameter listing tool with an output schema present, this description is fully sufficient. It tells the agent what is returned, that names are usable IDs, and that the list may include hidden agents, leaving no essential gap for invocation.

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

Parameters4/5

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

The tool has zero parameters and the schema coverage is effectively complete, so the baseline of 4 applies. No parameter documentation is needed, and the description correctly avoids inventing parameter details.

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?

Description clearly states a specific verb ('List') and resource ('all specialized orchestrator agent personas'). It also differentiates from siblings by explaining these are registered subagent IDs, distinct from tools like orchestrate_init or orchestrate_get_dag_batches.

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

Usage Guidelines4/5

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

The description gives clear functional context: the returned names are usable as subagent IDs even when hidden from the catalog, which implies when to use this tool. It does not explicitly name alternatives or exclusion criteria, so it stops short of a 5.

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

Deploy Server

Other Tools