Skip to main content
Glama

Cloud Team Manage Tool

team_manage

Manage team settings, membership, BYOK credentials, API tokens, notifications, and KMS encryption keys. Write actions require owner or admin role.

Instructions

Caller's team — settings, membership, BYOK provider credentials, API tokens, notifications, and KMS-managed encryption keys. Most write actions require team role owner or admin (HTTP 403 otherwise); viewer and member are limited to read + their own profile-level toggles (notifications). Every write is audit-logged.

When to use: agent or assistant managing the current team's configuration — invite a member, mint an API token, register a BYOK Anthropic key, etc. Do NOT use for cross-team operations — those require admin_manage (super-admin only).

Core team actions:

  • get (read) — returns team object (name, slug, plan, settings, owner_id, member_count).

  • update (write — admin/owner) — optional: name, settings (object). Plan changes happen via Stripe webhook only.

  • members (write — admin/owner) — sub-actions: list, invite (email, role), remove (user_id). Invitations expire after 7 days.

LLM provider config (admin/owner):

  • local_llm (read) — bridge-discovered local LLM agents (Ollama, LM Studio, Codex, Claude Code).

  • byok_credential (write) — sub-actions on BYOK keys (Anthropic, OpenAI, Google, Mistral, Perplexity). Keys encrypted at rest; never echoed back.

  • custom_endpoint (write — plan-enforced; pro/enterprise only) — sub-actions on custom OpenAI-compatible LLM endpoints (vLLM, LiteLLM, custom proxies).

Tokens & access (admin/owner):

  • api_token (write) — sub-actions: create (returns token once), list, revoke. Tokens are team-scoped and inherit the user's role; rotate on suspected leak.

Notifications & system:

  • notification (write — any role) — sub-actions: list, dismiss, dismiss_all on the user's notification inbox.

  • join_request (write — admin/owner) — sub-actions: list, approve, reject pending team join requests.

  • kms (DESTRUCTIVE — owner only) — sub-actions on KMS encryption keys: list, rotate (re-encrypts all team credentials with new key — cannot be undone), revoke.

Errors: 401, 403 (insufficient role), 404, 409 (cannot remove self if last owner), 422, 429.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actionYesAction to perform: get, update, members, local_llm, byok_credential, custom_endpoint, api_token, notification, join_request, kms
deadline_msNoOptional: max wall-clock time (ms) the tool may spend. If exceeded during the call, returns a DEADLINE_EXCEEDED error. Minimum 100 ms. Leave unset for no deadline.
nameNoNew team name
settingsNoTeam settings object (merged with existing settings)
providerNoProvider: ollama | openai_compatible (required for configure/remove/discover)
base_urlNoBase URL of the endpoint (e.g. http://localhost:11434)
api_keyNoOptional API key for authenticated endpoints
modelsNoComma-separated model IDs for openai_compatible endpoints
token_idNoToken ID to revoke (required for revoke action)
notification_idNoRequired for mark_read. The notification UUID to mark as read.
titleNoRequired for send. Notification title.
bodyNoRequired for send. Notification body text.
typeNoFor send. Notification type (e.g. agent_alert, budget_warning, info).
action_urlNoFor send. Optional URL the user can click to navigate.
user_idNoFor send. Target user ID. If omitted, notifies all team members.
preferencesNoFor update_preferences. Map of notification_type => array of channels (in_app, mail, push). E.g. {"experiment.stuck": ["in_app","mail","push"]}
request_idNoJoin request UUID (required for approve/deny)
credentialsNoProvider-specific credentials. Required for test and enable. AWS: {role_arn, key_arn, region}. GCP: {project_id, location, key_ring, key_id, service_account_json}. Azure: {tenant_id, client_id, client_secret, vault_url, key_name, key_version?}.
key_identifierNoThe key identifier (ARN for AWS, resource name for GCP, vault URL + key name for Azure). Required for enable.
forceNoForce removal even if KMS is unreachable. Only for remove action.
Behavior5/5

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

Detailed disclosure of behavioral traits: role-based access (owner/admin for writes, viewer/member for read+notifications), audit logging, destructive nature of KMS rotate/revoke, token rotation advice, and error types. Annotations are absent, so description fully informs the agent.

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?

Well-structured with headers and bullet points, front-loading purpose and role requirements. Though lengthy due to complexity, every sentence adds value without redundancy. Appropriate size for the tool's scope.

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?

Covers almost all necessary context: roles, errors (401,403,404,409,422,429), action details, and return values for key actions like 'get'. Despite no output schema, the description provides sufficient information for correct usage.

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

Parameters5/5

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

Adds significant context beyond the input schema: explains action enum with sub-actions, special notes like 'never echoed back' for BYOK, 'plan-enforced' for custom endpoints, and token creation returning once. Schema coverage is 100%, but description enriches each parameter meaning.

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 explicitly states the tool manages the caller's team with specific verbs (settings, membership, BYOK, tokens, notifications, KMS keys). It distinguishes from sibling 'admin_manage' for cross-team operations, ensuring clear purpose.

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?

Provides explicit when-to-use guidance (agent/assistant managing current team) and when-not (use admin_manage for cross-team). Also clarifies role requirements for different actions, aiding correct invocation.

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/escapeboy/agent-fleet-o'

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