Skip to main content
Glama

mavis_session_new

Create a new standalone Mavis session for isolated tasks. Use --from root to ensure independence from any parent session.

Instructions

Create a new standalone Mavis session (use --from root for isolated, independent session). For child sessions linked to a parent, use mavis_spawn_worker instead.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
agentYesAgent name (e.g. mavis, coder, general, verifier)
promptNoInitial prompt to send to the new session
titleNoOptional session title
workspaceNoSession workspace directory path
modelNoOverride LLM model (providerID/modelID format)

Implementation Reference

  • src/index.js:142-159 (registration)
    Tool registration entry in the tools array. Defines name, description, inputSchema (zod validation), and buildArgs for the mavis_session_new tool.
    {
      name: 'mavis_session_new',
      description: 'Create a new standalone Mavis session (use --from root for isolated, independent session). For child sessions linked to a parent, use mavis_spawn_worker instead.',
      inputSchema: z.object({
        agent: z.string().describe('Agent name (e.g. mavis, coder, general, verifier)'),
        prompt: z.string().optional().describe('Initial prompt to send to the new session'),
        title: z.string().optional().describe('Optional session title'),
        workspace: z.string().optional().describe('Session workspace directory path'),
        model: z.string().optional().describe('Override LLM model (providerID/modelID format)')
      }),
      buildArgs: ({ agent, prompt, title, workspace, model }) => {
        const args = ['session', 'new', agent, '--from', 'root', '--prompt', prompt || 'hello'];
        if (title) args.push('--title', title);
        if (workspace) args.push('--workspace', workspace);
        if (model) args.push('--model', model);
        return args;
      }
    },
  • Input validation schema using zod for mavis_session_new. Validates: agent (required string), prompt (optional string), title (optional string), workspace (optional string), model (optional string).
    inputSchema: z.object({
      agent: z.string().describe('Agent name (e.g. mavis, coder, general, verifier)'),
      prompt: z.string().optional().describe('Initial prompt to send to the new session'),
      title: z.string().optional().describe('Optional session title'),
      workspace: z.string().optional().describe('Session workspace directory path'),
      model: z.string().optional().describe('Override LLM model (providerID/modelID format)')
    }),
  • buildArgs function that constructs CLI arguments for the Mavis CLI binary. Calls `session new <agent> --from root --prompt <prompt>` with optional --title, --workspace, --model flags. Default prompt is 'hello'.
    buildArgs: ({ agent, prompt, title, workspace, model }) => {
      const args = ['session', 'new', agent, '--from', 'root', '--prompt', prompt || 'hello'];
      if (title) args.push('--title', title);
      if (workspace) args.push('--workspace', workspace);
      if (model) args.push('--model', model);
      return args;
    }
  • runTool function — the generic handler runner that uses buildArgs from the tool spec, calls execMavis or execMavisJSON, formats output as text or raw.
    function runTool(spec, parsedArgs) {
      const { execFn, outputMode, stdin, buildArgs } = spec;
      const args = buildArgs(parsedArgs);
      const input = typeof stdin === 'function' ? stdin(parsedArgs) : stdin;
    
      const execPromise = execFn
        ? execMavis(args, input || '')
        : execMavisJSON(args);
    
      return execPromise.then(result => {
        const text = outputMode === OUTPUT_RAW
          ? (result || '')
          : JSON.stringify(result, null, 2);
        return [{ type: 'text', text }];
      });
    }
  • execMavis helper — spawns the Mavis CLI binary with given args, optionally injecting parent session ID via --session flag.
    function execMavis(args, input = '') {
      return new Promise((resolve, reject) => {
        const SESSION_COMMANDS = new Set(['communication', 'session', 'spawn']);
        const sessionId = process.env.__MAVIS_PARENT_SESSION_ID;
        const subcmd = args[0];
        const needsSession = SESSION_COMMANDS.has(subcmd) && sessionId;
        const finalArgs = needsSession ? [...args, '--session', sessionId] : args;
        const proc = spawn(MAVIS_BIN, finalArgs, { stdio: ['pipe', 'pipe', 'pipe'] });
        let stdout = '';
        let stderr = '';
    
        proc.stdout.on('data', d => stdout += d.toString());
        proc.stderr.on('data', d => stderr += d.toString());
        proc.on('close', code => {
          if (code === 0) resolve(stdout.trim());
          else reject(new Error(stderr.split('\n')[0] || `exit code ${code}`));
        });
        proc.on('error', reject);
    
        if (input) proc.stdin.write(input), proc.stdin.end();
      });
    }
Behavior2/5

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

No annotations are provided, so the description bears the full burden. It lacks details on behavioral traits such as creation behavior (synchronous/asynchronous), required permissions, side effects, or return value. Minimal transparency beyond the core action.

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 two concise sentences with zero wasted words. It front-loads the purpose and immediately provides usage differentiation.

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?

The description covers purpose, usage, and sibling differentiation adequately, but lacks behavioral transparency and does not mention the return value or what the tool produces (no output schema). For a creation tool, more context about post-creation state would be beneficial.

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 baseline is 3. The tool description does not add any extra meaning to the parameters; it focuses on the tool's purpose rather than parameter details. The schema already documents each parameter.

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 clearly states the tool creates a standalone Mavis session, specifies the --from root flag for isolation, and explicitly differentiates from mavis_spawn_worker for child sessions, providing a specific verb-resource pair with sibling distinction.

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?

Explicitly states when to use this tool (standalone sessions, possibly with --from root) and when to use the alternative mavis_spawn_worker (for child sessions linked to a parent), giving clear guidance.

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/Cunning-Kang/mavis-mcp-server'

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