Skip to main content
Glama
debugg-ai

Debugg AI MCP

Official
by debugg-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Environment

environment
Destructive

Manage project environments and login credentials: create, update, list, delete, inspect or clear authenticated sessions, and handle cross-domain SSO hosts.

Instructions

Manage environments (and their login credentials) under a project. Pass an "action":

  • "get" {uuid, projectUuid?} → one environment with credentials inline (passwords never returned).

  • "list" {projectUuid?, q?, page?, pageSize?} → paginated environments. projectUuid auto-resolves from the git repo if omitted.

  • "create" {name, url, description?, projectUuid?, credentials?, authorizedCredentialHosts?} → create an env, optionally seeding credentials.

  • "update" {uuid, name?, url?, description?, addCredentials?, updateCredentials?, removeCredentialIds?, authorizedCredentialHosts?} → patch env + manage credentials.

  • "delete" {uuid, projectUuid?, confirm?} → delete env (DESTRUCTIVE; requires confirmation).

  • "sessions" {uuid, username?, credentialId?} → captured login sessions this env is holding, and whether each would be reused.

  • "clearSessions" {uuid, username?, credentialId?, confirm?} → invalidate them so the next run logs in for real.

CROSS-DOMAIN SSO: a run only types this environment's credentials on the app's own host (and its subdomains); a login on any other host is refused as offscope_host. If your identity provider lives on a different domain than the app, add the IdP host to authorizedCredentialHosts — bare hostnames like "auth.example.com", no scheme/path/port/wildcard. The response echoes the saved list; if it reports authorizedCredentialHostsWarning, the server did not persist it.

SESSIONS: runs reuse a warm authenticated session per account instead of logging in every time. That is why a check can report "no login form" — it was already signed in. Use "sessions" to see whose session is held, "clearSessions" to drop it, or pass freshSession:true on a single check_app_in_browser call to bypass reuse without clearing anything.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qNo[list] Free-text search over env name.
urlNo[create/update] Base URL.
nameNo[create/update] Environment name.
pageNo[list] Page (1-indexed).
uuidNo[get/update/delete] Environment UUID.
actionYesOperation to perform.
confirmNo[delete/clearSessions] Set true to confirm (when the client cannot prompt). clearSessions only needs it when no username/credentialId narrows it.
pageSizeNo[list] Page size (1..200).
usernameNo[sessions/clearSessions] Narrow to one account. Matched case-insensitively.
credentialsNo[create] Seed login credentials.
descriptionNo[create/update] Free-text description.
projectUuidNoTarget project (defaults to git auto-detect).
credentialIdNo[sessions/clearSessions] Narrow to one stored credential by UUID.
addCredentialsNo[update] Add credentials.
updateCredentialsNo[update] Patch credentials by UUID.
removeCredentialIdsNo[update] Delete credentials by UUID.
authorizedCredentialHostsNo[create/update] Hosts where the run may enter this environment's credentials besides the app's own host, e.g. your identity provider for cross-domain SSO. Bare hostnames only (auth.example.com). On update this REPLACES the list; [] clears it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv4.3.0
    • addedInput schema / properties / authorizedCredentialHosts
      Added value: +{
+  "description": "[create/update] Hosts where the run may enter this environment's credentials besides the app's own host, e.g. your identity provider for cross-domain SSO. Bare hostnames only (auth.example.com). On update this REPLACES the list; [] clears it.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
  2. Changed4 schema fields changedv4.2.2
    • changedInput schema / properties / action / enum
      Previous value: -[
-  "get",
-  "list",
-  "create",
-  "update",
-  "delete"
-]New value: +[
+  "get",
+  "list",
+  "create",
+  "update",
+  "delete",
+  "sessions",
+  "clearSessions"
+]
    • changedInput schema / properties / confirm / description
      Previous value: -"[delete] Set true to confirm deletion (when the client cannot prompt)."New value: +"[delete/clearSessions] Set true to confirm (when the client cannot prompt). clearSessions only needs it when no username/credentialId narrows it."
    • addedInput schema / properties / credentialId
      Added value: +{
+  "description": "[sessions/clearSessions] Narrow to one stored credential by UUID.",
+  "type": "string"
+}
    • addedInput schema / properties / username
      Added value: +{
+  "description": "[sessions/clearSessions] Narrow to one account. Matched case-insensitively.",
+  "type": "string"
+}
  3. Addedv3.10.0
  4. Removedv3.7.4
  5. Addedv3.0.1

TDQS

A5/5.0
Behavior5/5

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

The description goes well beyond the annotations (readOnlyHint=false, destructiveHint=true, openWorldHint=true). It details destructive operations requiring confirmation, that passwords are never returned, that sessions are reused by default, and that a login on offscope hosts is refused. It also notes the authorizedCredentialHostsWarning response behavior. This adds rich behavioral context beyond the structured annotations.

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 long but every sentence earns its place. It is front-loaded with a compact action list, then dives into SSO and session behavior only where needed. The formatting with bullets and bolded sections makes it scannable, and there is no redundant repetition of schema content.

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?

For a tool with 7 actions, 17 parameters, and no output schema, the description is exceptionally complete. It covers all operational aspects, including edge cases like cross-domain SSO, session reuse, confirmation requirements, and response warnings. An agent has everything needed to select and invoke the tool correctly.

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?

Schema coverage is 100%, but the description adds substantial meaning: e.g., 'projectUuid auto-resolves from the git repo if omitted', 'confirm' is only needed when the client cannot prompt, and 'authorizedCredentialHosts' replaces the list on update. These enrich the schema's terse field descriptions and clarify ambiguous cases like clearSessions confirmation.

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 states 'Manage environments (and their login credentials) under a project' and then enumerates seven concrete actions. This is a specific verb+resource pair that clearly differentiates the tool from siblings like 'project' or 'test_case'. The purpose is unmistakable and not a tautology.

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?

The description provides explicit context on when to use each action, including auto-resolution of projectUuid from the git repo, and even cross-references another tool ('pass freshSession:true on a single check_app_in_browser call to bypass reuse'). It explains the SSO domain restriction and when to use authorizedCredentialHosts, giving clear guidance on both usage and alternatives.

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

Deploy Server

Other Tools