Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
NEXUS_DEBUGNoSet to any value to enable debug logging

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
nexus_askB

Send a prompt to any AI provider (ChatGPT, Gemini, Claude, Ollama, etc.). Uses the active provider/model by default, or specify a different one.

nexus_switch_modelA

Switch the active AI provider and model. After switching, all subsequent nexus_ask calls will use the new provider/model.

nexus_list_modelsA

List all available AI providers and their models, with status indicators. Optionally filter by a specific provider.

nexus_statusB

Health check all configured AI providers. Shows connection status, latency, and any errors.

nexus_configureB

Configure a provider directly from chat — set API keys, base URLs, enable/disable providers. For full management, use the web dashboard.

nexus_reauthA

Open a browser window for re-authentication with a provider. Log into your account, then close the browser. Your session will be saved for future use. Supported providers: openai, gemini, anthropic, perplexity, mistral, cohere, huggingface, deepseek, groq

nexus_subagent_spawnA

Spawn one or more AI subagent tasks for parallel execution. Each task targets a specific provider/model with its own prompt. Returns a batch ID — use nexus_subagent_run to execute.

nexus_subagent_runA

Execute all tasks in a spawned batch in parallel. Waits for all to complete. Returns results from every model with metadata (text, latency, tokens, errors).

nexus_subagent_collabA

Multi-model collaboration pipeline. Models work sequentially: first model produces output, next reviews/refines, optional final model synthesizes. Returns final output plus all intermediate steps showing each model's contribution.

nexus_subagent_statusB

Check status of subagent batches. Shows pending, running, or completed batches with results. Omit batchId to list all recent batches.

nexus_agent_runA

Run an autonomous AI agent that can read files, write code, execute shell commands, search the web, and iterate until the task is complete. The agent uses the specified model (GPT-5.4, Nemotron, Gemini, etc.) and works independently through a ReAct loop. Returns the final answer plus a full trace of every action taken.

nexus_agent_multiA

Run multiple autonomous AI agents IN PARALLEL, each with its own model and task. Each agent independently reads files, writes code, and executes commands. Perfect for divide-and-conquer tasks: one agent codes while another tests, or multiple agents each tackle a different part of a large codebase. All agents run simultaneously and results are returned together.

nexus_plan_executeA

Execute a structured multi-step plan where Claude is the orchestrator and Nexus agents do the work. Independent steps run IN PARALLEL. Dependent steps wait and receive context from prior steps. Use mode="agent" for steps that need file access/code execution. Use mode="prompt" for analysis/review steps. Opus plans, Nexus executes.

nexus_plan_statusB

Check the status of a previously executed plan. Returns per-step results and metadata.

nexus_councilA

Convene a multi-model council where AI agents deliberate in rounds and Opus makes the final decision. DISCUSSION: Models build on each other collaboratively. DEBATE: Models challenge each other adversarially. RESEARCH: Models investigate with tools (file read, web search) and cross-reference findings. All participants respond in parallel each round, seeing all prior contributions. Use this for architecture decisions, code reviews, security audits, complex analysis.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.5/5.0

Scored across 15 tools

Disambiguation3/5

The provider-management tools are clearly distinct, but the orchestration family overlaps: nexus_subagent_spawn/run, nexus_agent_run/multi, nexus_subagent_collab, and nexus_council all involve dispatching model tasks, and the boundaries between subagent, agent, and council workflows are not immediately obvious. The descriptions clarify the different interaction patterns enough to be usable, but an agent could still misselect among them.

Naming Consistency3/5

All tools share the nexus_ prefix and snake_case, but the convention is inconsistent: list_models, switch_model, and reauth use verb-led names, while subagent_spawn, subagent_collab, agent_multi, and council use noun-led or noun-only names. The prefix helps recognition, but an agent cannot reliably predict a tool name from its function.

Tool Count4/5

At 15 tools, this sits at the upper edge of the ideal range but is justifiable for a multi-provider orchestration server covering provider configuration, simple prompts, subagents, autonomous agents, plans, and councils. A few orchestration modes could potentially be consolidated, but the count is not bloated.

Completeness4/5

The surface covers provider health, authentication, configuration, model listing/switching, prompt execution, subagent batches, autonomous agents, plans, and councils, with status/result retrieval for the async workflows. The main gap is the lack of any cancel/abort tool for long-running agents, batches, or councils, which is a notable but non-fatal omission.

Maintenance

ActivityInactive
ResponsivenessNo issues