Marcora

get_team_info

Read-onlyIdempotent

ALWAYS use this when the user asks what team accounts they have, which teams they belong to / are on, or wants to switch teams — do NOT answer from memory or session context, which knows ONLY the single currently-active team and will undercount (a user can belong to many teams). This tool is the only way to enumerate the full list.

Returns every team you belong to, each with its full member roster. Read-only.

Also use this BEFORE assigning a plan or content to a teammate (to look up their numeric user_id — the value `update_plan.assigned_to` / `create_plan.assigned_to` expect), or to answer questions about the team's members and your role.

Each team includes: team_id, team_name, is_active (exactly one team is your active team — see set_active_team to change it), your_role, and members[]. Each member has: user_id (the numeric id assignment expects; null for a pending invite that hasn't been accepted), name, email, role, and status ("active" or "invited").

Deliberately does NOT include credits or subscription info — call get_current_user_info for those.

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": "get_team_info"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description	Default
`teams`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 4, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the readOnly/idempotent annotations it discloses real behavioral limits: session context undercounts teams, exactly one team is active, user_id is null for pending invites, and credits/subscription info is deliberately excluded. These are non-obvious facts an agent could not infer from annotations or schema.

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 the imperative trigger and well-sectioned, but there is some redundancy — the 'only way to enumerate the full list' claim restates the preceding sentence. The long enumeration of return fields is useful but overlaps with the available output schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is complete for a zero-param read tool: triggers, exclusions, and cross-references are all present. However, since an output schema exists, the block enumerating team_id/team_name/members[] partially duplicates structured data rather than adding pure incremental value.

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?

Zero parameters, so there is nothing to disambiguate and the baseline is 4. The field-level detail about members[] and is_active applies to the response, not inputs, so it does not raise this dimension further.

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?

States a specific verb and resource — enumerate every team the user belongs to, each with its full member roster — and explicitly distinguishes it from get_current_user_info and set_active_team. An agent can tell it apart from siblings without opening any schema.

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?

Gives explicit triggers (user asks what teams they have, which teams they are on, wants to switch teams, needs a teammate's user_id before assignment) plus an explicit anti-pattern: do NOT answer from memory or session context, which knows only the active team. It also names the alternative tools for adjacent needs (set_active_team, get_current_user_info).

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?