Marcora

set_active_team

Idempotent

Set your active team — the team all subsequent Marcora tool calls operate against. Input: team_id (the numeric id from get_team_info).

⚠️ GLOBAL EFFECT: switching your active team changes it EVERYWHERE for your account — open Marcora app tabs, any running Marcora sessions, and every other connected MCP client — because it writes the same active-team setting the in-app team switcher uses. Tell the user before you switch, and do NOT switch while other work is mid-flight for them.

The response includes previous_team_id so you can restore their original team when you're done: switch → do the work → set_active_team back to previous_team_id.

Rejects a team you don't belong to with a readable error (use get_team_info to see your teams).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "team_id": "<team_id>"
    },
    "name": "set_active_team"
  }
}

Input Schema

Name	Required	Description	Default
`team_id`	Yes	The numeric team_id (from get_team_info) to switch to. Must be a team you belong to.

Output Schema

Name	Required	Description	Default
`active_team`	Yes
`previous_team_id`	Yes	The team that was active before this call. Pass it back to set_active_team to restore.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 4, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond the annotations: it discloses that the write is GLOBAL, touching the in-app team switcher, open app tabs, running sessions, and other MCP clients. It also documents the rejection behavior for unauthorized teams and the previous_team_id field that enables restoration — none of which the annotations convey.

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?

Front-loaded with purpose, then the warning, then the restore workflow, then error behavior — a sensible priority order. It is slightly long and the restore instruction is stated twice (once as a pattern, once as a caution), but every paragraph carries real signal.

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?

This is a low-complexity, single-parameter mutation, yet the description covers side effects, safety protocol, failure mode, and even the relevant response field. With an output schema present, no further return-value detail is required.

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 coverage is 100% and the schema already states the parameter is a numeric team_id from get_team_info that must be a team you belong to. The description repeats essentially the same information without adding format, constraint, or edge-case detail, so the baseline 3 applies.

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?

Names a specific verb and resource ('Set your active team') and immediately defines scope: 'the team all subsequent Marcora tool calls operate against.' This distinguishes it cleanly from get_team_info, which is named as the read-side counterpart.

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?

Explicit guidance on when to use (switch → do the work → restore) and when not to ('do NOT switch while other work is mid-flight'), plus the prerequisite of telling the user first. It also routes to get_team_info for discovering valid team ids, leaving little to inference.

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

All Marcora tools Inspect

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

Need Help?