Which integrations are available for this server?

Enables importing and browsing OpenAPI/Swagger specifications to explore API endpoints, request schemas, and parameter details for local testing and documentation.

How do I use API Testing MCP?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@API Testing MCP test the /api/users endpoint using the dev environment" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

de en es ja ko ru zh

API Testing MCP

by cocaxcode

Overview Schema Related Servers Score Discussions

TypeScript

Local

Quick Overview

The most complete MCP server for API testing — 42 tools, zero config, nothing else comes close. This is not just a request sender. It is a full testing workbench: HTTP requests with assertions, multi-step flows with variable extraction, OpenAPI import with schema-aware mock data, load testing with percentile metrics, response diffing across environments, bulk test runners, reusable collections, environment groups with directory scoping and persistent defaults, Postman import/export, and cURL export. All from natural conversation. No accounts, no cloud, no generated files. Everything runs inline and stores as plain JSON you own.

Related MCP server: Postman MCP Generator

Just Talk to It

You don't need to learn tool names or parameters. Describe what you want and the AI picks the right tool.

"Create a group called my-project and add this directory as scope"
"Set up a dev environment with BASE_URL http://localhost:3000"
"Switch to prod for this session"
"Set dev as the default environment"
"Import my API spec from /api-docs-json"
"Show me all user endpoints"
"GET /users"
"Create a user with random data"
"Verify that DELETE /users/5 returns 204"
"Login as admin, extract the token, then fetch dashboard stats"
"How fast is /health with 50 concurrent requests?"
"Run all my saved smoke tests"
"Compare the users endpoint between dev and prod"
"Export the create-user request as curl"
"Export my collection to Postman"

If you've imported an OpenAPI spec, the AI already knows every endpoint, every required field, every valid enum value. When you say "create a blog post", it reads the schema and builds the request correctly — no guessing.

Installation

Claude Code

claude mcp add --scope user api-testing -- npx -y @cocaxcode/api-testing-mcp@latest

Claude Desktop

Add to your config file (~/Library/Application Support/Claude/claude_desktop_config.json on macOS, %APPDATA%\Claude\claude_desktop_config.json on Windows):

{
  "mcpServers": {
    "api-testing": {
      "command": "npx",
      "args": ["-y", "@cocaxcode/api-testing-mcp@latest"]
    }
  }
}

Cursor / Windsurf

Add to .cursor/mcp.json or .windsurf/mcp.json in your project root:

{
  "mcpServers": {
    "api-testing": {
      "command": "npx",
      "args": ["-y", "@cocaxcode/api-testing-mcp@latest"]
    }
  }
}

VS Code — add to .vscode/mcp.json:

{
  "servers": {
    "api-testing": {
      "command": "npx",
      "args": ["-y", "@cocaxcode/api-testing-mcp@latest"]
    }
  }
}

Codex CLI (OpenAI):

codex mcp add api-testing -- npx -y @cocaxcode/api-testing-mcp@latest

Or add to ~/.codex/config.toml:

[mcp_servers.api-testing]
command = "npx"
args = ["-y", "@cocaxcode/api-testing-mcp@latest"]

Gemini CLI — add to ~/.gemini/settings.json:

{
  "mcpServers": {
    "api-testing": {
      "command": "npx",
      "args": ["-y", "@cocaxcode/api-testing-mcp@latest"]
    }
  }
}

Quick Start

Once installed, set up an environment so relative paths resolve automatically:

"Create an environment called dev with BASE_URL http://localhost:3000"

If your API has a Swagger/OpenAPI spec, import it:

"Import my API spec from http://localhost:3000/api-docs-json"

Verify with: "List my environments" — you should see the one you just created.

Features

HTTP Requests

Send any HTTP method with headers, query params, JSON body, auth, and {{variable}} interpolation. Relative URLs auto-resolve against BASE_URL.

"POST to /api/users with name Jane and email jane@company.com using my bearer token"

Supports: GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS — Bearer / API Key / Basic auth — custom timeouts.

Compression modes (v0.13+)

AI agents pay for every byte that lands in their context window. By default, request now returns a compressed response that cuts 70-95% of those tokens without losing debugging value. Three optional parameters control it:

Param	Values	What it does
`verbosity`	`'minimal'` / `'normal'` (default) / `'full'`	Controls detail level
`only_fields`	`['user.id', 'items[*].name']`	Returns only these body paths (dot-notation + wildcards)
`max_body_bytes`	number (default `2048`)	Body size cap for `'normal'`

Modes:

minimal — only status, timing, size_bytes, first 200 chars of body. Perfect for health checks, polling loops, or fire-and-forget calls. Saves ~95% tokens.
normal (default) — filtered headers (drops Date, Server, CF-*, Set-Cookie, etc.) + body truncated to max_body_bytes. Covers ~80% of debugging use cases. Saves ~75% tokens.
full — complete response untouched. Use when you explicitly need every header or the full body.

Typical savings on a 5 KB JSON response (≈1,500 tokens):

Mode	Tokens consumed	Savings
`full`	~1,500	0% (baseline)
`normal`	~300-400	~75%
`minimal`	~50-80	~95%
`only_fields: ['data.id']`	~30	~98%

For a head-to-head comparison against curl, WebFetch and other native alternatives with measured numbers, see Native alternatives below.

Recovering full responses: every compressed response includes a call_id. If you need the full body later, call inspect_last_response({ call_id }) — no need to re-execute the request. This works for request, assert, and each step of flow_run. Responses are kept in a 20-slot ring buffer and persisted to .api-testing/last-responses/ with a 1-hour TTL.

// Example: normal (default) response
{
  "call_id": "k3m9a2xp",
  "status": 200,
  "statusText": "OK",
  "method": "GET",
  "url": "https://api.example.com/users/1",
  "timing": { "total_ms": 142 },
  "size_bytes": 5324,
  "headers": { "content-type": "application/json" },
  "body": { "id": 1, "email": "...", "...": "..." },
  "body_truncated": true,
  "hint": "Body truncated to 2048 bytes (full size: 5324B). Call inspect_last_response({ call_id: \"k3m9a2xp\" }) for the full body.",
  "tokens_saved_estimate": 820
}

Native alternatives: real token cost

How this MCP compares against the native options Claude Code has when api-testing is not available (Bash + curl, WebFetch, etc.).

TL;DR: compared to raw curl, request saves between 65% and 97% of context tokens depending on the mode, with no loss of debugging information. Measured on a real call to GET /api/v1/blog returning 8 posts (~8.7 KB of JSON, 19 response headers):

How the agent calls it	Uses MCP?	Tokens consumed	Delta vs curl
`Bash` + `curl` (raw stdout)	❌ native	~2,170	baseline
`WebFetch` (LLM summary)	❌ native	~400-800	−65%, but no auth / no envs / no inspect
`request` verbosity=`full`	✅ MCP	~2,170	0% (same as curl, no compression)
`request` verbosity=`normal` (default)	✅ MCP	~750	−65%
`request` verbosity=`minimal`	✅ MCP	~50	−97%
`request` with `only_fields: ["data[].id","data[].title"]`	✅ MCP	~190	−91%

Why this table's numbers differ slightly from the "Compression modes" section above: these come from a single real-world response, while the previous table shows typical savings on a synthetic 5 KB response. Trend and order of magnitude are the same.

Notes:

The default mode (normal) already saves 65% without any configuration: it filters out noisy headers (Date, Server, CF-*, Set-Cookie…) and caps the body at 2048 bytes.
only_fields accepts dot-paths with array index and wildcard support (items[*].name) — returns only the fields you ask for.
The MCP also adds features that have no direct native equivalent: {{variable}} interpolation, stored environments, auth schemas, flows, Postman import/export, and inspect_last_response to recover the full body without re-hitting the server.
Every registered MCP adds a fixed overhead of ~300-600 tokens per session (its instructions block + tool names). Typical break-even: 1-2 real calls per session.

Assertions

Validate responses with structured pass/fail results:

"Verify that GET /api/health returns 200, body.status is ok, and responds in under 500ms"

PASS — 3/3 assertions passed
  status === 200
  body.status === "ok"
  timing.total_ms < 500

10 operators: eq, neq, gt, gte, lt, lte, contains, not_contains, exists, type

Request Flows

Chain requests with variable extraction between steps. Perfect for auth flows and CRUD sequences.

"Login as admin@test.com, extract the access token, then use it to fetch all users"

flow_run({
  steps: [
    {
      name: "login",
      method: "POST",
      url: "/auth/login",
      body: { email: "admin@test.com", password: "SecurePass#99" },
      extract: { "TOKEN": "body.access_token" }
    },
    {
      name: "get-users",
      method: "GET",
      url: "/api/users",
      headers: { "Authorization": "Bearer {{TOKEN}}" }
    }
  ]
})

OpenAPI Import

Import specs from a URL or local file (JSON and YAML). Once imported, the AI knows every endpoint, parameter, and schema.

"Import my API spec from http://localhost:3000/api-docs-json"
"Import the spec from ./openapi.yaml"
"What parameters does POST /users expect?"

Supports OpenAPI 3.x with full $ref resolution, allOf, oneOf, anyOf. OpenAPI 2.0 partially supported.

Mock Data Generation

Generate realistic fake data from your OpenAPI schemas. Respects types, formats (email, uuid, date-time), enums, and required fields.

"Generate mock data for creating a user"

{
  "email": "user42@example.com",
  "name": "Test User 73",
  "password": "TestPass123!",
  "role": "admin"
}

Load Testing

Fire N concurrent requests and get performance metrics:

"How fast is the health endpoint with 50 concurrent requests?"

LOAD TEST — GET /api/health
Requests:    50 concurrent
Successful:  50 | Failed: 0
Req/sec:     23.31

  Min: 45ms | Avg: 187ms
  p50: 156ms | p95: 412ms | p99: 523ms
  Max: 567ms

Response Diffing

Execute two requests and compare their responses field by field. Detect regressions or compare environments.

"Compare the users endpoint between dev and prod"

Bulk Testing

Run every saved request in a collection (or filter by tag) and get a summary:

"Run all my saved smoke tests"

BULK TEST — 8/8 passed | 1.2s total
  health       — GET  /health      → 200 (45ms)
  list-users   — GET  /users       → 200 (123ms)
  create-post  — POST /blog        → 201 (89ms)
  login        — POST /auth/login  → 200 (156ms)

Collections

Save requests for reuse with tags. Build regression suites.

"Save this request as create-user with tags auth, smoke"
"List all requests tagged smoke"

Environments

Environments hold your variables — BASE_URL, tokens, API keys — and keep them separated by context. The system has three core concepts:

Group. A group organizes environments and binds them to directories. A group has N scopes (directories) that share its environments, and exactly one default environment. When you create an environment inside a group, it belongs to that group. When you cd into a directory that is a scope of a group, its environments become available automatically.

Default. The default environment activates automatically when you enter a scope of its group. It persists between sessions — restart your editor, reopen your terminal, and the default is still there. Set it once and forget about it.

Active. The active environment is what is being used right now for variable resolution. It starts as the default when you enter a scope, but you can switch it at any time. The active selection is session-only — it resets to the default on restart.

Global environments (not associated with any group) still exist. They require explicit activation with env_switch and do not persist between sessions.

Practical example:

"Create a group called my-api"
"Add this directory as scope to my-api"
"Create a dev environment with BASE_URL http://localhost:3000"   <- auto-joins group, auto-default
"Create a prod environment with BASE_URL https://api.example.com"
"List environments"                                              <- shows dev (active, default) and prod
"Switch to prod"                                                 <- session only
"Set prod as default"                                            <- persists

Automatic interpolation. Any {{variable}} in URLs, headers, query params, or request bodies is resolved against the active environment before the request fires. Set BASE_URL once and every relative path just works.

Your credentials never leave your machine. Environment files are plain JSON stored in ~/.api-testing/. Nothing syncs to any cloud. Nothing gets embedded in exports. Nothing gets tracked by git. Your tokens and secrets stay exactly where they should: on your disk, under your control.

Postman Import & Export

Bidirectional Postman support. Migrate seamlessly between Postman and your AI workflow.

"Import my Postman collection from ./exported.postman_collection.json"
"Export my collection to Postman"
"Export the dev environment for Postman"

Collection: Postman v2.1 format. Folders become tags. Auth inherited from folders/collection level. Supports raw JSON, x-www-form-urlencoded, form-data bodies.

Environment: Prefers currentValue over value. Skips disabled variables. Optional activate flag.

Collection: Requests grouped in folders by tag. Auth mapped to Postman's native format. {{variables}} preserved as-is.

Environment: All variables exported as enabled: true in Postman-compatible format.

Native Export & Import

Export collections and environments to a portable .atm/ folder. Share with your team or copy between projects.

"Export my collection and dev environment"

your-project/
└── .atm/
    ├── collection.json
    └── dev.env.json

Note: .atm/ is automatically added to .gitignore on first export.

cURL Export

Convert any saved request into a ready-to-paste cURL command with resolved variables.

"Export the create-user request as curl"

curl -X POST \
  'https://api.example.com/users' \
  -H 'Authorization: Bearer eyJhbGci...' \
  -H 'Content-Type: application/json' \
  -d '{"name":"Jane","email":"jane@company.com"}'

Tool Reference

42 tools across 10 categories:

Category	Tools	Count
Requests	`request`	1
Inspect	`inspect_last_response`	1
Testing	`assert`	1
Flows	`flow_run`	1
Collections	`collection_save`, `collection_list`, `collection_get`, `collection_delete`	4
Environments	`env_create`, `env_list`, `env_set`, `env_get`, `env_switch`, `env_rename`, `env_delete`, `env_spec`, `env_project_clear`, `env_project_list`	10
Groups	`env_group_create`, `env_group_list`, `env_group_delete`, `env_group_add_scope`, `env_group_remove_scope`, `env_set_default`, `env_set_group`	7
API Specs	`api_import`, `api_spec_list`, `api_endpoints`, `api_endpoint_detail`	4
Mock	`mock`	1
Utilities	`load_test`, `export_curl`, `diff_responses`, `bulk_test`, `export_collection`, `import_collection`, `export_environment`, `import_environment`, `export_postman_collection`, `import_postman_collection`, `export_postman_environment`, `import_postman_environment`	12

Tip: You don't need to call tools directly. Describe what you want and the AI picks the right one.

Storage

Everything is local. No database, no cloud sync, no telemetry. All data lives in ~/.api-testing/ as plain JSON files you can read, back up, or delete at any time.

~/.api-testing/
├── groups/               # Environment groups with scopes and defaults
├── environments/         # Environment variables — tokens, keys, passwords
├── collections/          # Saved requests (shareable, no secrets)
├── specs/                # Imported OpenAPI specs
└── project-envs.json     # Session-only active environments (cleared on restart)

Global storage vs project exports. The ~/.api-testing/ directory is your private, global store — this is where credentials live and they never leave. When you export a collection or environment, it goes to .atm/ in your project root. That folder is auto-added to .gitignore on first export, but even if you choose to commit it, your credentials stay in ~/.api-testing/ and are never copied into .atm/. You can safely share .atm/ exports with your team without leaking secrets.

Override the default storage path:

{
  "env": { "API_TESTING_DIR": "/path/to/custom/.api-testing" }
}

Warning: If you override API_TESTING_DIR to a path inside a git repository, add .api-testing/ to your .gitignore to avoid pushing credentials.

Architecture

src/
├── index.ts              # Entry point (shebang + StdioServerTransport)
├── server.ts             # createServer() factory
├── tools/                # 42 tool handlers (one file per category)
│   ├── request.ts        # HTTP request (1)
│   ├── inspect.ts        # inspect_last_response (1)
│   ├── assert.ts         # Assertions (1)
│   ├── flow.ts           # Request chaining (1)
│   ├── collection.ts     # Collection CRUD (4)
│   ├── environment.ts    # Environments + groups (17)
│   ├── api-spec.ts       # OpenAPI import/browse (4)
│   ├── mock.ts           # Mock data generation (1)
│   ├── load-test.ts      # Load testing (1)
│   └── utilities.ts      # curl, diff, bulk, import/export (11)
├── lib/                  # Business logic (no MCP dependency)
│   ├── http-client.ts    # fetch wrapper with timing
│   ├── storage.ts        # JSON file storage engine (atomic writes)
│   ├── compress.ts       # Response compression + verbosity modes
│   ├── response-cache.ts # Ring buffer + disk cache for inspect
│   ├── schemas.ts        # Shared Zod schemas (HttpMethodSchema, AuthSchema)
│   ├── url.ts            # BASE_URL resolution
│   ├── path.ts           # Dot-notation accessor (body.data.0.id)
│   ├── interpolation.ts  # {{variable}} resolver
│   └── openapi-parser.ts # $ref + allOf/oneOf/anyOf resolution
└── __tests__/            # 10+ test suites, 171 tests

Stack: TypeScript (strict) · MCP SDK · Zod · Vitest · tsup

MIT · Built by cocaxcode

Available Tools

42 tools

api_endpoint_detailA

Muestra el detalle completo de un endpoint: parámetros, body schema, y respuestas. Útil para saber qué datos enviar.

ParametersJSON Schema

Name	Required	Description
`name`	No	Nombre del API importada. Si se omite y solo hay un spec, lo usa automáticamente
`method`	Yes	Método HTTP del endpoint
`path`	Yes	Path exacto del endpoint (ej: "/blog", "/auth/login")

TDQS

A3.8/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It discloses that the tool returns parameters, body schema, and responses, which is adequate. However, it does not mention authentication requirements, rate limits, or any side effects beyond this read operation.

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 sentences, each providing essential information without redundancy. It is well-structured and concise.

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?

Given there is no output schema, the description adequately lists the components returned (parameters, body schema, responses). It is complete for a detail-viewing tool, though it could mention the response format or if it returns a JSON object.

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% with good descriptions for each parameter. The description adds no additional meaning beyond the schema, so baseline 3 is appropriate.

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 that the tool shows complete details of an endpoint, including parameters, body schema, and responses. It is specific about the resource (endpoint) and the verb (show detail). It distinguishes from sibling 'api_endpoints' which likely lists endpoints.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description says it's useful for knowing what data to send, implying when to use. However, it does not explicitly state when not to use or provide alternatives among siblings. The usage context is implied but not thoroughly clarified.

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

api_endpointsA

Lista los endpoints de un API importada. Filtra por tag, método o path. Si no se especifica nombre y solo hay un spec importado, lo usa automáticamente.

ParametersJSON Schema

Name	Required	Description
`name`	No	Nombre del API importada. Si se omite y solo hay un spec, lo usa automáticamente
`tag`	No	Filtrar por tag (ej: "blog", "auth", "users")
`method`	No	Filtrar por método HTTP
`path`	No	Filtrar por path (búsqueda parcial, ej: "/blog" muestra todos los que contienen /blog)

TDQS

A3.5/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. It states the tool lists and filters endpoints, but does not disclose any behavioral traits like read-onlyness, authentication requirements, rate limits, or side effects.

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?

Two sentences, no fluff. The purpose and key functionality are front-loaded. Every sentence adds value.

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?

For a simple listing tool with 4 optional parameters and no output schema, the description adequately covers purpose and filtering. However, it lacks information on return format, pagination, or what fields are included in the endpoint list.

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 description adds the auto-selection behavior for the 'name' parameter when omitted, which provides meaning beyond the schema. No further parameter details.

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?

Description clearly states it lists endpoints of an imported API, with explicit verb 'lista' and resource 'endpoints'. It also mentions filtering by tag, method, or path, differentiating it from sibling tools like api_endpoint_detail (likely details on a single endpoint) and api_spec_list (lists specs).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit when-to-use or when-not-to-use guidance against siblings. It does mention auto-selection of the spec if only one is imported and name omitted, which is a usage hint, but lacks alternatives or exclusions.

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

api_importA

Importa un spec OpenAPI/Swagger desde una URL o archivo local (JSON o YAML). Guarda los endpoints y schemas para consulta.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	Nombre para identificar este API (ej: "mi-backend", "cocaxcode-api")
`source`	Yes	URL o ruta a archivo local del spec OpenAPI (JSON o YAML, ej: http://localhost:3001/api-docs-json, ./openapi.yaml)

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, so the description must carry full behavioral transparency. It states that endpoints and schemas are saved for querying, but misses side effects (e.g., overwriting existing data), authorization requirements, or error conditions. The description is too brief for a mutation tool.

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 a single, concise sentence that front-loads the primary purpose. It wastes no words and is easy to scan.

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?

Given no annotations and no output schema, the description is somewhat adequate for a simple import tool with two well-documented parameters. However, it lacks context about expected behavior (e.g., validation, persistence) and how it fits with sibling tools.

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?

Input schema covers 100% of parameters with descriptions, so the schema already provides meaning. The description adds that source can be a URL or local file and mentions JSON or YAML formats, but this duplicates what the schema already implies. Baseline 3 is appropriate.

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 action ('Importa' / imports), the resource (OpenAPI/Swagger spec), and the input sources (URL or local file). It distinguishes this tool from siblings like import_collection or import_environment by specifying the spec type.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies that this tool is used for importing OpenAPI/Swagger specs, but it does not explicitly state when to use it versus other import tools, nor does it mention prerequisites or when not to use it. The guidance is minimal.

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

api_spec_listA

Lista todos los specs de API importados. Úsalo para descubrir qué APIs están disponibles.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior2/5

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

With no annotations, the description carries the full burden but only states the action. It lacks details on response format, side effects (none expected), or any constraints beyond listing.

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?

Two concise sentences, front-loaded with the core action and purpose. No wasted words.

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?

For a simple listing tool with no parameters, the description is mostly complete: it states what it lists and why. It could mention the output format (e.g., returns names) but is sufficient.

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?

The input schema has zero parameters, so baseline score is 4. The description adds no parameter info because none exist, and schema coverage is 100%.

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 lists all imported API specs, using a specific verb and resource, and distinguishes it from sibling listing tools like env_list or collection_list.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says to use it to discover available APIs, providing clear context. However, it does not specify when not to use it or compare to alternatives.

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

assertB

Ejecuta un request y valida la respuesta con assertions. Retorna resultado pass/fail por cada assertion.

ParametersJSON Schema

Name	Required	Description
`method`	Yes	HTTP method
`url`	Yes	URL del endpoint (soporta /relativa y {{variables}})
`headers`	No	Headers HTTP
`body`	No	Body del request (JSON)
`query`	No	Query parameters
`auth`	No	Autenticación
`assertions`	Yes	Lista de assertions a validar contra la respuesta

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations, the description must fully disclose behavioral traits. It mentions executing a request and returning pass/fail but fails to warn about potential side effects (e.g., mutable HTTP methods like POST, DELETE) or state that the request is actually sent. This could lead an agent to use it destructively without caution.

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?

The description is a single short sentence, which is efficient, but it lacks structure such as bullet points or separation of key points. It conveys the core idea without unnecessary words.

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

Completeness2/5

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

Given the tool's complexity (7 parameters, nested objects, no output schema), the description is insufficient. It does not explain how assertions work, the output format, or the implications of executing requests (e.g., costs, side effects). The agent would need to rely heavily on schema details alone.

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% with already descriptive parameter descriptions. The tool description adds no extra semantic information beyond what the schema provides, meeting the baseline for high coverage.

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 executes a request and validates the response using assertions, returning pass/fail per assertion. This is specific and distinguishes it from sibling tools like 'request' (no assertions) and 'inspect_last_response' (inspects only).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description offers no guidance on when to use this tool versus alternatives. It does not mention prerequisites, when not to use it, or mention any sibling tools, leaving the agent to infer appropriate usage from context.

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

bulk_testB

Ejecuta todos los requests guardados en la colección y reporta resultados. Filtrable por tag.

ParametersJSON Schema

Name	Required	Description	Default
`tag`	No	Filtrar por tag
`expected_status`	No	Status HTTP esperado para todos (default: cualquier 2xx)

TDQS

B3.2/5.0

Behavior2/5

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

With no annotations, the description carries full burden. It states execution and result reporting but omits behavioral details like auth requirements, whether execution is safe (read-only vs. destructive), or potential side effects. This is insufficient for an agent to assess impact.

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?

The description is a single concise sentence that front-loads the action and resource. However, it could be slightly more informative without becoming verbose, hence not a 5.

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?

For a simple tool with two optional parameters and no output schema, the description adequately covers its basic function. However, it misses context about what 'ejecuta' entails (e.g., does it make real HTTP calls?) and the scope of 'collection' (which one?). More details would improve completeness.

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 the schema itself documents both parameters. The description adds 'Filtrable por tag' which duplicates the schema's tag description, but does not provide deeper semantics or examples. 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?

The description clearly states the tool executes all saved requests in the collection and reports results, with filtering by tag. This distinguishes it from siblings like request (single request) or load_test (performance testing).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no explicit guidance on when to use this tool versus alternatives. It mentions filtering but does not explain use cases or exclusions relative to other collection tools.

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

collection_deleteC

Elimina un request guardado de la colección.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	Nombre del request a eliminar

TDQS

C2.9/5.0

Behavior2/5

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

The description implies a destructive action but provides no behavioral details such as permanence, authorization requirements, or side effects. Since no annotations are available, the description must bear the full burden, which it fails to do.

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?

The description is a single sentence, concise and front-loaded. However, it is so brief that it borders on under-specification, but for a simple delete tool it is acceptable.

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

Completeness2/5

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

Given the lack of annotations and the simple one-parameter schema, the description should have provided more context about the deletion behavior, such as whether it is reversible or if it requires special permissions. It is insufficiently complete.

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?

The schema description coverage is 100%, and the parameter 'name' is described in the schema. The tool description adds no extra meaning beyond the schema, so a baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action: deleting a saved request from the collection. It distinguishes from sibling tools like collection_get, collection_list, collection_save by specifying deletion. However, it does not specify which collection context applies.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives (e.g., when not to delete, prerequisites like having saved a request first). The agent must infer usage from context and sibling names.

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

collection_getA

Obtiene los detalles completos de un request guardado por su nombre.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	Nombre del request guardado

TDQS

A3.8/5.0

Behavior3/5

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

No annotations are provided, so the description must carry the burden. It states 'detalles completos' (complete details) but does not explicitly mention read-only nature, side effects, or authentication needs. Annotations would have helped, but the description is minimally adequate.

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?

Single sentence with no unnecessary words, efficiently conveying the core action and resource.

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?

For a simple retrieval tool with one parameter and no output schema, the description is mostly complete. However, it does not specify the format of the details returned or any limitations, leaving minor gaps.

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?

The schema covers 100% of parameters with a clear description for 'name'. The tool description adds that it retrieves 'complete details,' which provides additional context beyond the schema's param description. Baseline score is appropriate.

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 uses a clear verb ('Obtiene' meaning 'gets') and specific resource ('detalles completos de un request guardado'), distinguishing it from sibling tools like collection_list (lists all collections) and collection_save (saves collections).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives. The description only implies usage for retrieving saved request details without providing context or exclusions.

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

collection_listB

Lista todos los requests guardados en la colección. Opcionalmente filtra por tag.

ParametersJSON Schema

Name	Required	Description	Default
`tag`	No	Filtrar por tag

TDQS

B3.2/5.0

Behavior3/5

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

The description implies a read operation through the word 'lista' (list) and optional filtering, but it does not explicitly confirm read-only status, permissions, or side effects. Since no annotations are provided, the description carries the burden and offers only basic behavioral clues.

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 a single sentence that immediately conveys the main action and the optional filter. It is concise and front-loaded, with no unnecessary words or information.

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

Completeness2/5

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

Given the absence of an output schema, the description should explain what is returned (e.g., a list of request objects with properties). It does not, leaving the agent unaware of the structure or fields of the result, which is a significant gap for a simple tool.

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?

The input schema already describes the 'tag' parameter with 100% coverage, and the tool description merely repeats 'Opcionalmente filtra por tag' without adding any new meaning or format expectations. This meets the baseline but adds no value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists all requests in the collection, which is a specific action. However, it does not differentiate itself from sibling tools like 'collection_get' or 'api_endpoints', which might also list items.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives such as 'collection_get' or 'request'. The description only mentions an optional filter, without explaining why one would choose this over other listing tools.

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

collection_saveA

Guarda un request en la colección local. Si ya existe un request con el mismo nombre, lo sobreescribe.

ParametersJSON Schema

Name	Required	Description
`name`	Yes	Nombre único del request guardado
`request`	Yes	Configuración del request a guardar
`tags`	No	Tags para organizar (ej: ["auth", "users"])

TDQS

A3.6/5.0

Behavior2/5

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

With no annotations, the description carries full burden. It mentions overwrite behavior but lacks details on side effects, return values, or error conditions. Incomplete disclosure for a mutation tool.

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?

Two sentences, front-loaded with the main action and overwrite caveat. No wasted words.

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?

For a simple save tool, the description covers key behavior (overwrite). Lacks detail on output/response but acceptable given tool type and schema richness.

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% with existing descriptions. The description adds no extra meaning beyond what the schema already provides for the three parameters.

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 action ('Guarda un request') and the resource ('en la colección local'), plus the overwrite behavior. It distinguishes well from siblings like collection_get or collection_delete.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage (saving a request) but does not explicitly state when to use this tool versus alternatives or any prerequisites. No guidance on when not to use.

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

diff_responsesB

Ejecuta dos requests y compara sus respuestas. Útil para detectar regresiones o comparar entornos.

ParametersJSON Schema

Name	Required	Description	Default
`request_a`	Yes	Primer request
`request_b`	Yes	Segundo request

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are provided, and the description fails to disclose behavioral traits: whether it modifies state, if it sends actual HTTP requests (which could be destructive), or if responses are persisted. Minimal transparency beyond stating it executes requests.

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?

Two sentences, front-loaded with action, second sentence adds use cases. No redundant information; every sentence earns its place.

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

Completeness2/5

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

Despite complex nested parameters (two request objects with multiple subfields) and no output schema, the description omits crucial details: what the comparison output looks like, ordering of requests, and any limitations. Incomplete for a comparison tool handling possibly destructive operations.

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% with detailed property descriptions (labels, methods, auth types). The description adds no extra meaning beyond the schema, so baseline score of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it executes two requests and compares their responses, with specific use cases (detecting regressions, comparing environments). This distinguishes it from sibling tools like 'request' (single request) and 'assert' (assertions), but doesn't detail the comparison output format.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for regression detection and environment comparison but provides no explicit when-to-use vs. alternatives (e.g., 'request', 'bulk_test', 'assert'). No guidance on when not to use this tool.

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

env_createB

Crea un nuevo entorno. PREGUNTA al usuario: nombre, grupo (o global) y variables. Si el grupo no existe, se crea automaticamente.

ParametersJSON Schema

Name	Required	Description
`name`	Yes	Nombre del entorno (ej: dev, staging, prod)
`group`	No	Nombre del grupo (ej: "cocaxcode"). Si se omite, auto-detecta por CWD. Para global: pasar cadena vacía ""
`variables`	No	Variables iniciales como key-value
`spec`	No	Nombre del spec API asociado (ej: "cocaxcode-api")

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations, the description carries the full burden. It discloses automatic group creation but omits critical behaviors like overwrite behavior if an environment with the same name exists, or the implications of 'PREGUNTA al usuario' (ask the user) which suggests interactivity not suitable for an AI agent.

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?

The description is short (two sentences) and front-loaded with the main verb 'creates'. However, it could be improved by explicitly listing all parameters and clarifying the interactive directive for agent use.

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

Completeness2/5

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

Given the complexity (4 parameters, no output schema, no annotations), the description is incomplete: it misses the 'spec' parameter, does not mention return values, and the 'ASK the user' instruction is problematic for an autonomous agent. Important behavioral details are absent.

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 description adds minimal value beyond the schema: it lists three parameters but omits 'spec'. It does not provide additional context for parameter usage beyond what is already in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'creates a new environment' and lists key parameters (name, group, variables). However, it does not distinguish it from sibling tools like 'env_set' or 'env_group_create', which are related but different operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage by mentioning asking for name, group, and variables, and notes automatic group creation. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., when to use 'env_set' for updates or 'env_group_create' for group creation).

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

env_deleteA

Elimina un entorno y todas sus variables. Si es el entorno activo, lo desactiva.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	Nombre del entorno a eliminar

TDQS

A4/5.0

Behavior4/5

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

The description adds behavioral details beyond the schema: it specifies that deleting an environment removes all its variables and deactivates it if it is active. This context is valuable given the absence of 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 concise (two sentences in Spanish) and front-loaded with the main action. Every part is relevant and adds value.

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 adequately covers the deletion of the environment and its variables, plus special handling of the active environment. However, it could mention that the action is irreversible or that no confirmation is required, which would be useful for a delete operation.

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% with a description for the 'name' parameter. The tool description does not add new information about the parameter's format or constraints; it only reiterates the purpose.

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 'Elimina un entorno y todas sus variables' (deletes an environment and all its variables), which is a specific verb and resource. It differentiates from sibling tools like env_get (retrieve) and env_create (create) by focusing on deletion.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not provide guidance on when to use this tool vs alternatives like env_switch or env_rename. Usage is implied (when deletion is needed), but no exclusions or alternative references are given.

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

env_getA

Obtiene una variable específica o todas las variables de un entorno. Los valores sensibles (token, password, secret, api_key...) se enmascaran por defecto. Pide una variable por nombre para ver su valor completo.

ParametersJSON Schema

Name	Required	Description	Default
`key`	No	Variable específica. Si se omite, retorna todas
`environment`	No	Entorno a consultar (default: entorno activo)

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations provided, the description carries full burden; it discloses that sensitive values are masked by default and that specifying a variable shows the full value, though it omits details like authentication or rate limits.

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?

Two sentences that are front-loaded with purpose and behavioral nuance, with no wasted words.

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?

For a simple read tool with two parameters and no output schema, the description covers core functionality and key behavioral trait (masking), but could add return value details.

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?

Schema coverage is 100%, baseline 3; description adds value by explaining masking behavior and reinforcing the semantic of the 'key' parameter's optionality.

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 retrieves a specific variable or all variables from an environment, with a distinct read-only purpose compared to sibling tools like env_set or env_delete.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explains when to request a specific variable to see its full value, and the context implies read-only use, but it does not explicitly exclude other scenarios or name alternatives.

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

env_group_add_scopeB

Añade un directorio (scope) a un grupo. Los entornos del grupo seran accesibles desde ese directorio.

ParametersJSON Schema

Name	Required	Description	Default
`group`	Yes	Nombre del grupo
`scope`	No	Ruta del directorio. Si se omite, usa el directorio actual

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, so the description bears full responsibility. It only states the basic effect (environments become accessible) but omits side effects, error conditions, or reversibility. For a mutation tool, this is insufficient.

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 short sentences that efficiently convey the core functionality. No unnecessary words.

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 tool is simple with 2 parameters, but the description lacks usage context, error scenarios, or clarification about duplicate additions. It is minimally complete but not robust.

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?

Input schema coverage is 100% with both parameters described. The description adds no extra meaning to the parameters beyond what the schema already provides. Baseline 3 is appropriate.

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 action ('adds a directory/scope to a group') and the resource involved. It distinguishes from the sibling tool 'env_group_remove_scope' which performs the inverse operation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives, nor any when-not or prerequisite conditions. The sibling 'env_group_remove_scope' exists but is not mentioned.

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

env_group_createA

Crea un nuevo grupo de entornos. Luego añade scopes (directorios) con env_group_add_scope.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	Nombre del grupo (ej: cocaxcode, optimizatusol)

TDQS

A3.8/5.0

Behavior2/5

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

No annotations are provided, so the description must cover behavioral traits. It only states what the tool does, without mentioning idempotency, side effects, permissions, or error conditions (e.g., duplicate name). This is a significant gap.

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?

Two concise sentences, front-loaded with the core action, and zero wasted words. Every sentence serves a purpose.

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?

Given the low complexity (1 parameter, no output schema), the description adequately covers the purpose and follow-up step. It is complete for its scope, though it could benefit from stating whether the group is created empty or with default settings.

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?

The input schema has 100% description coverage for the single parameter 'name', including an example. The description adds no additional semantic value beyond restating the context, so baseline 3 is appropriate.

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 action ('Crea un nuevo grupo de entornos') with a specific verb and resource, and distinguishes from siblings by noting the subsequent step with env_group_add_scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit context for post-creation action ('Luego añade scopes con env_group_add_scope'), guiding the agent to use another tool next. Does not include when-not-to-use or alternatives, but the context is clear.

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

env_group_deleteA

Elimina un grupo. Los entornos del grupo quedan como globales.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	Nombre del grupo a eliminar

TDQS

A4.2/5.0

Behavior4/5

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

The description goes beyond the simple deletion action by stating 'Los entornos del grupo quedan como globales' (The group's environments become global), which is a key behavioral consequence. No annotations are provided, so the description carries full burden, and it delivers relevant side-effect information.

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 a single, well-structured sentence that immediately states the action and the side effect. Every part adds value; no redundancy.

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?

For a simple delete tool with one parameter and no output schema, the description adequately covers the primary action and its main consequence. It could mention if the group must be empty or if the operation is reversible, but the current information is sufficient for basic use.

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% with one parameter described ('Nombre del grupo a eliminar'). The description adds no further meaning to the parameter beyond what the schema provides, meeting the baseline expectation for high coverage.

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?

Description clearly states 'Elimina un grupo' (Deletes a group), a specific verb and resource. It distinguishes from sibling tools like env_group_create, env_group_list, env_group_add_scope, which have different actions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage by stating the deletion and its effect on environments. While no explicit alternatives or exclusions are given, the context is clear that this tool is for deleting a group, and the side effect is mentioned.

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

env_group_listB

Lista todos los grupos con sus scopes, default y entornos.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, and the description does not disclose behavioral traits such as authentication requirements, rate limits, side effects, or pagination. It only states a read action, which is minimally transparent.

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 a single, clear sentence that conveys the essential information without any extraneous words. It is front-loaded with the action.

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?

For a simple parameterless list operation, the description adequately explains what is returned (groups with scopes, default, and environments). No output schema exists, but the description covers the output fields. Some details like ordering or sorting are missing, but not critical for this tool.

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?

The tool has zero parameters, so schema coverage is 100%. The description adds no parameter information, but none is needed. Per the baseline rule for 0 parameters, a score of 4 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (list) and resource (all groups) with specific attributes (scopes, default, environments). However, it does not explicitly differentiate from sibling tools like env_group_create or env_group_delete, though the context of siblings implies it is a read operation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. The description only states what it does, without mentioning prerequisites, exclusions, or when not to use it.

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

env_group_remove_scopeC

Quita un directorio (scope) de un grupo.

ParametersJSON Schema

Name	Required	Description	Default
`group`	Yes	Nombre del grupo
`scope`	No	Ruta del directorio a quitar. Si se omite, usa el directorio actual

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description carries full burden for behavioral traits. It implies a destructive action (removing a scope) but does not disclose side effects, permissions needed, or whether changes are reversible. The description is minimal and insufficient for an agent to fully understand the impact.

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?

The description is a single sentence, concise and front-loaded with the core action. It wastes no words, but its brevity may sacrifice completeness. Still, it earns a 4 for efficiency.

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

Completeness2/5

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

Given the simplicity of the tool (two parameters, no output schema, no annotations) and the presence of sibling tools (env_group_add_scope, env_group_create, etc.), the description is incomplete. It lacks information on error cases, group existence requirements, and differentiation from similar operations. An agent cannot reliably decide when to invoke this tool based solely on the description.

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%, so the input schema already provides descriptions for both parameters (group name, scope path with default behavior). The tool description adds no additional semantic value beyond restating the action. Baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: removing a scope (directory) from a group. The verb 'quitar' (remove) and resource 'directorio (scope) de un grupo' are specific. However, it does not explicitly differentiate from sibling tools like env_group_add_scope, which is the inverse operation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives, such as env_group_add_scope or env_group_delete. There is no mention of prerequisites, context, or when removal is appropriate.

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

env_listA

Lista todos los entornos disponibles e indica cuál está activo.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.9/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. It correctly describes a read-only operation listing environments, but adds no extra behavioral details like authentication or side effects.

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?

Single sentence, concise, and immediately conveys the purpose. No wasted words.

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?

Sufficient for a simple list tool with no parameters. No output schema needed; the description covers the core functionality.

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?

No parameters in the schema (100% coverage), so description doesn't need to compensate. Baseline score of 4 is appropriate.

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 verb 'List' and resource 'environments', and specifies it indicates the active one. It distinguishes itself from sibling tools like env_create or env_delete.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives like env_list or env_spec. The description only states what it does, not context or exclusions.

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

env_project_clearA

Elimina la asociación de entorno específico de un proyecto. El proyecto no tendrá entorno activo hasta que se asigne uno.

ParametersJSON Schema

Name	Required	Description	Default
`project`	Yes	Ruta del proyecto del que eliminar la asociación

TDQS

A4.1/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden. It clearly states the immediate effect of removing the association and the consequence that the project will have no active environment until one is assigned. This adds behavioral insight beyond the name, though it omits details like idempotency or error handling.

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?

Two short sentences, 22 words total, front-loaded with the key action. Every word is necessary and no redundant information. Efficient and to the point.

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 simple, one-parameter tool with no output schema, the description is fully complete: it describes the action, the consequence, and the required input. No additional context is needed for correct invocation.

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?

The input schema already provides a description for the single parameter 'project'. The tool description adds no additional semantic meaning beyond what the schema states, so the baseline of 3 applies given 100% schema coverage.

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 uses a specific verb 'Elimina' (removes) and clearly identifies the resource as the environment association of a project. It distinguishes from siblings like env_delete (removes entire environment) and env_set (assigns environment) by focusing on clearing the association, and includes a clear consequence statement.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not explicitly state when to use this tool versus alternatives like env_delete or env_set. It implies usage context (clearing an association) but lacks direct comparisons or exclusion criteria, leaving the agent to infer from sibling names.

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

env_project_listC

Lista todos los proyectos con entornos específicos asignados.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are present, so the description carries the full burden. It only states the purpose, without disclosing side effects (e.g., read-only), required permissions, or any behavioral traits. For a listing operation, it is acceptable but leaves the agent without safety guarantees.

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 a single, front-loaded sentence that conveys the core purpose with no unnecessary words. It is concise and easy to parse.

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

Completeness2/5

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

Given no output schema and no annotations, the description should provide more context. It does not define 'proyecto' or 'entornos específicos asignados', nor does it hint at the output format or typical usage. An agent may not know what to expect from the response.

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?

There are zero parameters, so the schema provides no constraints. The description adds minimal meaning beyond the name—it explains that the list is filtered to projects with 'specific environments assigned', but does not elaborate on what 'specific environments' means or how the results are structured. Baseline for 0 params is 4 but lack of detail justifies 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it lists projects ('Lista todos los proyectos') with a specific condition regarding environments. It is distinct from sibling tools like 'env_list' (lists environments) and 'env_project_clear' (clears assignments), but the phrase 'con entornos específicos asignados' is slightly ambiguous—it could mean projects that have environments assigned or projects with their assigned environments.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, typical scenarios, or when not to use it. For example, it does not clarify whether this tool should be used before 'env_set' or 'env_project_clear'.

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

env_renameB

Renombra un entorno existente. Si es el entorno activo, actualiza la referencia.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	Nombre actual del entorno
`new_name`	Yes	Nuevo nombre para el entorno

TDQS

B3.4/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden. It discloses a key behavioral trait: updating the reference if it's the active environment. However, it omits other potential side effects (e.g., cascading updates to groups or projects) or permission requirements, making it moderately transparent.

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?

The description is concise with two sentences, no filler. It is front-loaded with the main action and ends with a specific condition. It could be slightly improved by separating the condition, but overall it is well-structured.

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?

Given the absence of an output schema, the description could mention what the tool returns. The operation is simple, and the description covers the core behavior, but lacks return value details. It is adequate but not fully complete.

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 both parameters have descriptions in the schema. The description does not add any additional meaning beyond what the schema already provides. Therefore, the baseline score of 3 is appropriate.

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 verb 'renombra' (rename) and the resource 'entorno existente' (existing environment). It also adds a specific behavioral note about updating the reference if it is the active environment, which distinguishes it from sibling tools like env_create or env_delete.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not provide any guidance on when to use this tool versus alternatives (e.g., env_set or env_create for renaming). No when-not-to-use or context is given, leaving the agent without direction.

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

env_setA

Establece una variable en un entorno. Si no se especifica entorno, usa el activo.

ParametersJSON Schema

Name	Required	Description
`key`	Yes	Nombre de la variable
`value`	Yes	Valor de la variable
`environment`	No	Entorno destino (default: entorno activo)

TDQS

A3.6/5.0

Behavior2/5

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

The description discloses default environment behavior, but no annotations exist. It does not mention whether the operation is idempotent, overwrites existing values, or any side effects.

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?

Single, focused sentence with no superfluous words. Ideal conciseness for a simple tool.

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?

For a simple variable setter, the description covers the essential behavior (default environment). It could mention overwriting behavior, but adequate for the tool's complexity.

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% with descriptions for all three parameters; the description adds no additional parameter meaning beyond what's in the schema.

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 action ('Establece una variable en un entorno') and distinguishes from sibling tools like env_create, env_delete, etc. It also notes the default environment behavior.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is for setting variable values, but does not explicitly state when to use it vs alternatives or mention any prerequisites or constraints.

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

env_set_defaultA

Marca un entorno como el default de su grupo. El default se activa automaticamente al entrar al proyecto.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	Nombre del entorno a marcar como default

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, so the description must carry the full burden. It describes the core behavior (marking as default and auto-activation) but omits side effects, prerequisites, error handling, or return value information.

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 consists of two concise sentences, front-loaded with the main action. No unnecessary words or repetition.

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?

For a simple, single-parameter tool with no output schema, the description covers purpose and effect. However, it lacks behavioral details (e.g., reversibility, permissions) that would be helpful given no annotations.

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% (the single parameter has a description). The tool description does not add additional meaning beyond what the schema already provides, so a baseline score of 3 is appropriate.

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 marks an environment as the default of its group, with a specific verb ('Marca') and resource ('entorno'). It also explains the consequence (automatic activation), making it distinct from siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies a use case (setting a default that activates automatically), but does not explicitly compare to alternatives like env_set or env_switch, nor state when not to use this tool.

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

env_set_groupA

Asigna o cambia el grupo de un entorno existente. Para sacarlo a global, pasar group vacío "".

ParametersJSON Schema

Name	Required	Description	Default
`environment`	Yes	Nombre del entorno
`group`	Yes	Nombre del grupo. Cadena vacía "" para hacerlo global

TDQS

A3.8/5.0

Behavior2/5

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

No annotations are provided, so the description must carry the full burden. It discloses the core action and the empty string behavior, but lacks information on side effects (e.g., overwriting existing group, required permissions, error conditions). This is insufficient for a mutation tool.

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 a single sentence that efficiently conveys the core functionality and a key usage note. No redundant or unnecessary text.

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?

Considering the tool has only two parameters and no output schema, the description covers the main use case and an important special case. However, it could mention prerequisites (e.g., environment must exist) or error handling. Still, for a simple tool, it is fairly complete.

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?

The input schema already has descriptions for both parameters (100% coverage), so the baseline is 3. The description adds value by explaining the special case of passing an empty string for 'group' to make the environment global, which is not fully captured in the schema description. This provides additional 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 clearly states the verb 'asigna o cambia' (assigns or changes) and resource 'grupo de un entorno existente' (group of an existing environment). It also explains the special case of making an environment global. The purpose is distinct from sibling tools like env_group_create or env_set.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use this tool (to set/change the group of an environment) but does not explicitly state when not to use it or provide alternatives. The special case for making global is mentioned, but no comparison with other group-related tools is given.

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

env_specA

Asocia o desasocia un spec API a un entorno. Si no se especifica entorno, usa el activo.

ParametersJSON Schema

Name	Required	Description	Default
`spec`	No	Nombre del spec a asociar. Si se omite, desasocia el spec actual
`environment`	No	Entorno destino (default: entorno activo)

TDQS

A3.6/5.0

Behavior3/5

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

With no annotations, the description carries full burden. It mentions the dual action (associate/disassociate) and default environment, which aligns with the parameter descriptions. However, it does not disclose additional behavioral traits like side effects or required permissions.

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 very concise with two sentences, front-loaded with the action verb. Every word is necessary and no redundant information.

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?

Given the tool's simplicity and full schema coverage, the description is nearly complete. It lacks information about return values or error states, but for a basic association tool this is acceptable.

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%, so baseline is 3. The description adds no extra meaning beyond the schema; it merely paraphrases the default environment behavior already in the parameter description.

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 verb 'asocia o desasocia' with the resources 'spec API' and 'entorno', and specifies the default behavior when environment is omitted. It distinguishes itself from sibling tools like env_set or api_spec_list.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites, restrictions, or contrast with similar tools like env_set_default or api_import.

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

env_switchA

Cambia el entorno activo. Sin project cambia el global. Con project, solo aplica a ese directorio.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	Nombre del entorno a activar
`project`	No	Ruta del proyecto (ej: C:/cocaxcode). Si se omite, cambia el entorno global

TDQS

A3.9/5.0

Behavior2/5

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

With no annotations, the description carries full burden but only states the basic function. No disclosure of side effects, authorization needs, or what state changes occur.

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?

Two sentences with no superfluous words. The first sentence states the core purpose, the second clarifies parameter usage. Extremely efficient.

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?

Covers the main behavior and parameter usage, but lacks details on return value or error conditions. For a simple switch tool, this is adequate but not fully complete.

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?

Schema coverage is 100%, and the description adds value by explaining the conditional behavior of 'project' parameter (global vs project-scoped), going beyond the schema's individual parameter descriptions.

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 it changes the active environment, with a precise distinction between global and project-specific usage. This distinguishes it from siblings like env_set or env_set_default.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use the 'project' parameter versus omitting it, providing clear context. However, it does not explicitly mention when not to use the tool or suggest alternatives.

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

export_collectionB

Exporta los requests guardados en formato nativo (JSON) a .atm/. Carpeta portable — cópiala a otro proyecto para importar.

ParametersJSON Schema

Name	Required	Description	Default
`tag`	No	Filtrar requests por tag
`output_dir`	No	Directorio donde guardar el archivo (default: .atm/)

TDQS

B3.4/5.0

Behavior3/5

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

No annotations are provided, so the description carries full burden. It discloses that the tool exports requests in native JSON format to a .atm/ directory, which is portable, but does not mention behavior like overwriting existing files, required permissions, or what the output structure looks like.

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 a single, well-formed sentence that conveys the main action, output format, target directory, and portability. No superfluous information, efficiently structured.

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

Completeness2/5

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

Given the lack of output schema and annotations, the description does not fully equip an agent to use the tool. It omits details about whether the export produces a single file or folder, how to use the import counterpart, and what happens if the output directory exists. For a tool with multiple sibling export tools, more context is needed.

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?

Input schema has 100% coverage for both parameters (tag and output_dir). The description adds that the format is native JSON and the default output is .atm/, but these are already captured in the schema descriptions. No additional semantic meaning is provided beyond what is in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool exports saved requests in native JSON format to a portable .atm/ folder. It distinguishes from sibling tools like export_curl or export_environment by specifying the target format and portability, but does not explicitly mention 'collection' in the text, slightly reducing clarity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for moving requests between projects (cópiala a otro proyecto para importar), but does not explicitly state when to use this tool versus alternative export tools, nor does it provide guidance on when not to use it.

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

export_curlB

Genera un comando cURL a partir de un request guardado en la colección. Listo para copiar y pegar.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	Nombre del request guardado en la colección
`resolve_variables`	No	Resolver {{variables}} del entorno activo (default: true)

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations, the description is minimal, not disclosing whether the operation is read-only, potential side effects, or authentication requirements.

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?

Two efficient sentences that front-load the main function and result, without unnecessary words.

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

Completeness2/5

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

Given no output schema, the description omits details on the output format, error handling, and usage prerequisites, making it incomplete.

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 description does not add extra context beyond what the schema already provides.

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?

Description clearly states it generates a cURL command from a saved request, distinguishing it from sibling export tools like export_collection and export_environment.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives; lacks context about prerequisites or limitations.

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

export_environmentA

Exporta un entorno en formato nativo (JSON) a .atm/. Carpeta portable — cópiala a otro proyecto para importar.

ParametersJSON Schema

Name	Required	Description	Default
`name`	No	Nombre del entorno a exportar (default: entorno activo)
`output_dir`	No	Directorio donde guardar el archivo (default: .atm/)

TDQS

A4.1/5.0

Behavior3/5

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

No annotations provided, so description must disclose behavior. It reveals export format and destination. However, it does not mention side effects, file overwrites, or permissions. Adequate but not exhaustive for a simple export.

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?

Single sentence with all essential information, front-loaded with action. No redundant words.

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?

Given the tool's simplicity (2 optional params, no output schema), the description fully covers its purpose and use case. It explains the output format and portability, sufficient for an export tool.

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% with detailed parameter descriptions. The description adds no extra meaning beyond the schema (default active environment and output directory are already in schema). 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?

Description clearly states 'Exporta un entorno en formato nativo (JSON) a .atm/. Carpeta portable', specifying the verb (export), resource (environment), format (JSON), and destination (.atm/ folder). It distinguishes from sibling export tools like export_collection and export_curl.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implicitly indicates when to use: when you need a portable environment to import into another project. No explicit exclusions or alternative tools mentioned, but context is clear given sibling import tools.

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

export_postman_collectionA

Exporta los requests guardados como una Postman Collection v2.1 (JSON). Escribe el archivo en disco, importable directamente en Postman.

ParametersJSON Schema

Name	Required	Description
`name`	No	Nombre de la colección (default: "API Testing Collection")
`tag`	No	Filtrar requests por tag
`output_dir`	No	Directorio donde guardar el archivo (default: ./postman/)
`resolve_variables`	No	Resolver {{variables}} del entorno activo (default: false)

TDQS

A3.5/5.0

Behavior3/5

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

No annotations provided, so description carries burden. States it writes a JSON file to disk, but lacks details on overwrite behavior, permissions, or side effects. Additional traits like default output directory are noted.

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?

Two concise sentences with front-loaded key action (export format) and immediate outcome (write to disk, importable in Postman). No filler.

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?

Adequate for basic understanding but missing details on return value, parameter interactions, file overwrite policy, and handling of optional parameters. Could provide more context for a file-writing tool.

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 parameters are well-documented structurally. The description adds minimal extra meaning (e.g., 'saved requests' context). Baseline 3 is appropriate.

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 exports saved requests as a Postman Collection v2.1 JSON file, specifying both the export format and the resource. It differentiates from sibling tools like export_curl and import_postman_collection by focusing on Postman Collection export to disk.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives (e.g., export_collection, export_curl). No mention of prerequisites or context for selecting this specific export method.

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

export_postman_environmentB

Exporta un entorno como Postman Environment (JSON). Escribe el archivo en disco, importable directamente en Postman.

ParametersJSON Schema

Name	Required	Description	Default
`name`	No	Nombre del entorno a exportar (default: entorno activo)
`output_dir`	No	Directorio donde guardar el archivo (default: ./postman/)

TDQS

B3.4/5.0

Behavior3/5

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

Describes the side effect of writing a file to disk, but lacks details on overwrite behavior, error handling, or required permissions. With no annotations, more behavioral context would be beneficial.

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?

Two concise sentences that front-load the main action. No unnecessary words, but could be slightly more structured (e.g., mentioning defaults).

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?

For a simple tool with two optional parameters and no output schema, the description covers the basic functionality. However, it lacks usage guidance and behavioral details that would make it fully contextually complete given the many sibling tools.

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%, so baseline is 3. The description adds no extra meaning beyond the parameter descriptions already in the schema. It does not elaborate on default values or constraints.

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 exports an environment as a Postman Environment JSON file and writes it to disk. It specifies the format and importability, differentiating it from sibling tools like export_environment (generic) and import_postman_environment (import).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives such as export_environment or import_postman_environment. The description does not mention prerequisites, context, or scenarios where this tool is preferred.

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

flow_runA

Ejecuta una secuencia de requests en orden. Extrae variables de cada respuesta para usar en pasos siguientes con {{variable}}.

ParametersJSON Schema

Name	Required	Description	Default
`steps`	Yes	Pasos a ejecutar en orden
`stop_on_error`	No	Detener al primer error (default: true)

TDQS

A3.9/5.0

Behavior3/5

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

No annotations exist, so the description carries full burden. It covers sequential execution and variable extraction, but lacks details on error handling, authentication per step, and overall behavior beyond the basics.

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 extremely concise at two sentences, front-loading the core purpose without unnecessary words.

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?

Given the tool's complexity (chained requests with variable extraction) and no output schema, the description is adequate but lacks details on error responses, default stop_on_error, and variable path format.

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?

Schema coverage is 100%, providing a baseline of 3. The description adds meaning by explaining the variable extraction mechanism with {{variable}} syntax, which is not detailed in the schema's extract field description.

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 executes a sequence of requests in order and extracts variables for use in subsequent steps with {{variable}}. This distinguishes it from sibling single-request tools like 'request', providing a specific verb-resource pair.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use for multi-step sequences but does not explicitly state when to use this tool over alternatives (e.g., single requests). No exclusions or contextual clues are provided.

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

import_collectionA

Importa requests desde .atm/collection.json o un archivo específico. Auto-detecta .atm/ en el proyecto.

ParametersJSON Schema

Name	Required	Description
`file`	No	Ruta al archivo (default: busca en .atm/collection.json)
`tag`	No	Tag adicional para aplicar a todos los requests importados
`overwrite`	No	Sobreescribir requests existentes con el mismo nombre (default: false)

TDQS

A3.7/5.0

Behavior3/5

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

No annotations provided. Description covers basic import and auto-detection but omits details like overwrite behavior (though 'overwrite' param exists in schema), merge rules, or what happens to existing collections. Does not mention mutation or side effects.

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?

Two sentences, no redundant words. Focused and efficient.

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?

No output schema and no description of return value or errors. For a tool with 3 params and no annotations, it leaves gaps: not specifying what happens after import (e.g., success indicator, returned data). Adequate but not fully complete.

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% with parameter descriptions. The description adds context about auto-detection for the 'file' parameter but adds little beyond schema. Baseline 3 is appropriate.

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 it imports requests from .atm/collection.json or a specific file, with auto-detection. This differentiates it from sibling tools like import_environment or import_postman_collection.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives (e.g., import_environment, import_postman_collection). The description implies it is for importing request collections but lacks context for appropriate use cases.

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

import_environmentA

Importa un entorno desde .atm/ o un archivo específico. Auto-detecta archivos .env.json en .atm/.

ParametersJSON Schema

Name	Required	Description
`file`	No	Ruta al archivo (default: busca *.env.json en .atm/)
`name`	No	Nombre para el entorno (default: usa el nombre del archivo exportado)
`overwrite`	No	Sobreescribir si ya existe un entorno con el mismo nombre (default: false)
`activate`	No	Activar el entorno importado como entorno activo (default: false)

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It mentions auto-detection and the 'overwrite' parameter implication but does not state whether the import is destructive, what happens on conflicts when overwrite is false, or any authentication/rate-limit constraints. Key behavioral traits (e.g., file not found, permission errors) are omitted.

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 sentences long, front-loading the primary action and a key behavioral feature (auto-detection). Every sentence provides essential information without redundancy or filler. It is appropriately concise for a tool with four parameters.

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 the core purpose but lacks information on success/failure outcomes, prerequisite conditions (e.g., file existence), and return values. Since there is no output schema, the description should at least hint at what the tool returns (e.g., environment details or confirmation). The 4-parameter complexity and lack of annotations make the description insufficiently complete for an AI agent to fully understand usage.

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?

The input schema covers 100% of parameters with clear descriptions. The description adds marginal value by explaining auto-detection behavior for the 'file' parameter default. However, it does not go beyond the schema to clarify semantic nuances like format expectations or validation rules. Given full schema coverage, a baseline of 3 is appropriate.

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 imports an environment from a specific file or auto-detects .env.json files in the .atm/ directory. The verb 'importa' and resource 'entorno' match the tool name exactly, and it distinguishes from sibling tools like env_create (manual creation) or import_postman_environment (Postman format).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description indicates when to use the tool (importing from files) but lacks explicit guidance on alternatives or when not to use it. For example, it doesn't contrast with env_create for manual creation or with import_collection for collections. The auto-detection hint is helpful but incomplete for an AI agent to decide between similar import tools.

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

import_postman_collectionB

Importa una Postman Collection v2.1 (JSON) como requests guardados en la colección. Soporta folders, auth, headers, body y query params.

ParametersJSON Schema

Name	Required	Description
`file`	Yes	Ruta al archivo .postman_collection.json exportado de Postman
`tag`	No	Tag adicional para aplicar a todos los requests importados
`overwrite`	No	Sobreescribir requests existentes con el mismo nombre (default: false)

TDQS

B3.2/5.0

Behavior3/5

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

No annotations are provided, so the description carries the burden. It mentions support for various Postman features and implies mutation (saving requests). However, it does not disclose side effects like overwriting behavior (though captured in params), error handling, or performance implications.

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?

The description is concise with two sentences covering purpose and features. No redundant information, well-structured for quick understanding.

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?

Given moderate complexity (3 params, no output schema), the description explains core functionality but lacks return value details, error conditions, and explicit mention that the file must be valid. It covers the essentials but leaves gaps.

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% with clear parameter descriptions. The description does not elaborate on parameters beyond the schema, which is acceptable. No additional semantic value is added.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool imports a Postman Collection v2.1 JSON and saves them as requests in the collection. It specifies the format and supported features (folders, auth, etc.). However, it does not differentiate from the sibling tool import_collection, which may have overlapping functionality.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives like import_collection or export_postman_collection. No prerequisites or restrictions are mentioned.

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

import_postman_environmentA

Importa un Postman Environment (JSON) como entorno local. Soporta variables con valores initial/current.

ParametersJSON Schema

Name	Required	Description
`file`	Yes	Ruta al archivo .postman_environment.json exportado de Postman
`name`	No	Nombre para el entorno (default: usa el nombre del archivo Postman)
`overwrite`	No	Sobreescribir si ya existe un entorno con el mismo nombre (default: false)
`activate`	No	Activar el entorno importado como entorno activo (default: false)

TDQS

A3.6/5.0

Behavior3/5

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

The description adds the behavioral detail that it supports variables with initial/current values, which is not in the schema. However, it does not disclose other behaviors like side effects, validation, or permissions. Since no annotations exist, the description provides minimal extra context.

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, front-loading the core purpose and adding a key feature. No wasted words.

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?

Given that the schema fully documents parameters and there is no output schema, the description adequately covers the tool's purpose and key feature. It does not mention that it creates a local environment, but that is implied by the context of sibling tools. Nearly complete for the complexity.

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 each parameter has a clear description. The description adds a small detail about variable support but does not enhance understanding of the parameters beyond the schema. Baseline 3 is appropriate.

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 verb ('Importa') and resource ('Postman Environment (JSON) como entorno local'), and distinguishes from siblings like env_create or import_environment by specifying the Postman format and support for initial/current variables.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives like import_environment or env_create. The description does not mention prerequisites, compatibility, or exclusion cases.

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

inspect_last_responseA

Recupera la respuesta HTTP completa de una llamada previa de request cuando la versión comprimida no basta. Usa el call_id que aparece en el campo call_id de la respuesta comprimida. Sin call_id devuelve la más reciente.

ParametersJSON Schema

Name	Required	Description	Default
`call_id`	No	ID devuelto en el campo 'call_id' de una response comprimida. Si se omite, devuelve la última response guardada (warning si hay varias en los últimos 5s).

TDQS

A4.1/5.0

Behavior4/5

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

With no annotations, the description carries full burden. It discloses the read-only nature (returns response, no mutations), explains the dependency on compressed responses, and warns about multiple recent responses if 'call_id' is omitted. No contradictions detected.

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?

The description is two sentences in Spanish, front-loaded with the main purpose. It is concise but could be more compact without losing clarity. Structure is effective.

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?

Given no output schema, the description adequately explains the return content (full HTTP response) and parameter usage. It lacks explicit mention of response format (headers, body) but the context of 'HTTP response' is generally understood. Completes the picture for a targeted retrieval tool.

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% for the single parameter 'call_id', with a thorough description. The tool description adds only context (the relationship to compressed responses) beyond the schema. Baseline of 3 is appropriate since schema already explains the parameter well.

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 retrieves the full HTTP response from a previous 'request' call when the compressed version is insufficient. It specifies the action (recupera/inspect), the resource (last response), and distinguishes it from related tools like 'request' which likely returns compressed responses.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use (when compressed version is insufficient) and how to supply the 'call_id' parameter, including behavior when omitted (returns most recent). It implicitly suggests using it as a fallback to 'request'. Could mention alternatives or when not to use, but overall clear.

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

load_testC

Lanza N requests concurrentes al mismo endpoint y mide tiempos promedio, percentiles y tasa de errores.

ParametersJSON Schema

Name	Required	Description
`method`	Yes	HTTP method
`url`	Yes	URL del endpoint
`headers`	No	Headers HTTP
`body`	No	Body del request
`query`	No	Query parameters
`auth`	No	Autenticación
`concurrent`	Yes	Número de requests concurrentes a lanzar (max: 100)
`timeout`	No	Timeout por request en ms (default: 30000)

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description must disclose behavioral traits. It mentions concurrent requests and metric measurement but omits critical details like whether the tool is safe (non-destructive), rate limiting, authentication requirements, or potential impact on endpoints. This is insufficient for an agent to assess side effects.

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?

The description is a single concise sentence, front-loaded with the core action. It efficiently communicates the tool's purpose without unnecessary words, though it is in Spanish while the tool name is English, which may slightly reduce clarity for an AI agent.

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?

Given the complexity (8 parameters, nested objects, no output schema), the description is adequate but minimal. It hints at the output (average times, percentiles, error rate) but does not elaborate on format or interpretation. It provides just enough context for basic understanding but lacks depth for comprehensive agent use.

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?

The input schema has 100% description coverage, so the baseline is 3. The description does not add additional meaning beyond what the schema already provides; it merely restates the tool's purpose without elaborating on any parameter semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool launches concurrent requests and measures performance metrics like average times, percentiles, and error rate. It effectively communicates the core load testing functionality, though it does not explicitly differentiate from sibling tools like 'bulk_test'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites, limitations, or contexts where it is not appropriate, leaving the agent without decision-making support.

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

mockA

Genera datos mock/fake para un endpoint basándose en su spec OpenAPI importada. Útil para frontend sin backend.

ParametersJSON Schema

Name	Required	Description
`name`	Yes	Nombre del API importada
`method`	Yes	Método HTTP del endpoint
`path`	Yes	Path del endpoint (ej: "/users", "/blog")
`target`	No	Generar mock del body de request o de la response (default: response)
`status`	No	Status code de la respuesta a mockear (default: "200" o "201")
`count`	No	Número de items mock a generar si el schema es un array (default: 3)

TDQS

A3.6/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavior. It only states it generates mock data but does not mention if it is read-only, what happens if the spec is missing, or any side effects. This is insufficient for full transparency.

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 very concise with two sentences, front-loaded with the action and context. Every word is meaningful with no fluff.

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

Completeness2/5

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

The tool has no output schema and 6 parameters, but the description does not explain what the output looks like or what to expect from the generated data. This lack of completeness could confuse an AI agent about the return format.

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?

All parameters have descriptions in the input schema (100% coverage), so the description adds no additional meaning beyond what the schema already provides. Baseline 3 is appropriate.

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 generates mock/fake data for an endpoint using an imported OpenAPI spec, with a specific use case for frontend without backend. It is distinct from sibling tools which focus on API details, imports, or testing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions it's useful for frontend without backend, providing a clear context of use. However, it does not explicitly state when not to use it or mention alternatives.

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

requestA

Ejecuta un HTTP request. URLs relativas (/path) usan BASE_URL del entorno activo. Soporta {{variables}}. La respuesta se comprime por defecto (verbosity=normal) para ahorrar tokens; usa verbosity=full o inspect_last_response si necesitas la respuesta completa.

ParametersJSON Schema

Name	Required	Description
`method`	Yes	HTTP method
`url`	Yes	URL del endpoint. Si empieza con / se antepone BASE_URL del entorno activo. Soporta {{variables}}.
`headers`	No	Headers HTTP como key-value pairs
`body`	No	Body del request (JSON). Soporta {{variables}}
`query`	No	Query parameters como key-value pairs
`timeout`	No	Timeout en milisegundos (default: 30000)
`auth`	No	Configuración de autenticación
`verbosity`	No	Controls response detail to save context tokens. Default: 'normal'. - 'minimal': Only status, method, url, elapsed_ms, and first 200 chars of body. USE FOR: health checks (/health, /ping), status polling loops, fire-and-forget POST/DELETE, waiting for a job to complete, or when you only care whether the call succeeded. SAVES: ~95% tokens vs full. - 'normal' (DEFAULT): Filtered headers (omits Date, Server, CF-*, Set-Cookie, etc.) + body truncated to max_body_bytes with 'body_truncated' flag. USE FOR: most debugging — CRUDs, checking error messages, API contract exploration. SAVES: ~75% tokens vs full. - 'full': Complete response untouched. USE FOR: debugging CORS/cache/auth headers, large bodies you must inspect completely, or when the user asks to see everything. NO SAVINGS. If a response is truncated and you need more, prefer inspect_last_response({call_id}) over re-running with 'full'.
`only_fields`	No	Cheap alternative to 'full' when you know exactly what you need from the body. Returns only these dot-paths. Supports array index and wildcard. Examples: ["data.id"], ["user.email", "user.role"], ["items[*].id", "meta.total"]. Often saves >95% vs full while keeping the fields you care about.
`max_body_bytes`	No	Max body size in bytes for verbosity='normal' (default: 2048). Ignored for minimal/full.

TDQS

A4.1/5.0

Behavior4/5

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

With no annotations, the description carries full burden. It discloses that responses are compressed by default (verbosity=normal) to save tokens, supports {{variables}}, and relative URLs use BASE_URL. These are key behavioral traits.

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?

The description is a single concise paragraph covering key details without unnecessary repetition. It is front-loaded with the core action. Could be slightly more structured with bullet points, but it's efficient.

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?

Given 10 parameters with 100% schema coverage and no output schema, the description plus schema provide adequate guidance for usage. It hints at response behavior (compressed by default) and points to inspect_last_response for full data, covering completeness needs.

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 the schema already explains parameters thoroughly. The description adds context about compression and inspect_last_response but does not significantly expand parameter meaning beyond schema descriptions like verbosity examples.

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 'Ejecuta un HTTP request' (executes an HTTP request), specifying the verb and resource. It distinguishes from sibling tools like inspect_last_response by mentioning it as an alternative for full responses.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit guidance on verbosity levels and when to use inspect_last_response instead of re-running with full verbosity. However, lacks explicit comparisons with siblings like api_endpoint_detail, though the context makes the primary use case clear.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

42 tool updatesv0.13.4May 16, 2026
- First observedapi_endpoint_detail
- First observedapi_endpoints
- First observedapi_import
- First observedapi_spec_list
- First observedassert
- First observedbulk_test
- First observedcollection_delete
- First observedcollection_get
- First observedcollection_list
- First observedcollection_save
- First observeddiff_responses
- First observedenv_create
- First observedenv_delete
- First observedenv_get
- First observedenv_group_add_scope
- First observedenv_group_create
- First observedenv_group_delete
- First observedenv_group_list
- First observedenv_group_remove_scope
- First observedenv_list
- First observedenv_project_clear
- First observedenv_project_list
- First observedenv_rename
- First observedenv_set
- First observedenv_set_default
- First observedenv_set_group
- First observedenv_spec
- First observedenv_switch
- First observedexport_collection
- First observedexport_curl
- First observedexport_environment
- First observedexport_postman_collection
- First observedexport_postman_environment
- First observedflow_run
- First observedimport_collection
- First observedimport_environment
- First observedimport_postman_collection
- First observedimport_postman_environment
- First observedinspect_last_response
- First observedload_test
- First observedmock
- First observedrequest

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.6/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose, covering areas like API spec management, environment handling, request execution, testing, and collections. Descriptions are detailed and specific, leaving no ambiguity about what each tool does.

Naming Consistency5/5

All tool names use snake_case consistently, following verb_noun or noun_verb patterns. The naming is predictable and readable, despite the large number of tools.

Tool Count2/5

With 42 tools, the server exceeds the recommended range for a well-scoped MCP server. While the domain is broad, the high count may overwhelm agents and suggests potential for consolidation or modularization.

Completeness5/5

The tool set covers the full lifecycle of API testing: importing specs, managing environments, executing requests, running tests, and exporting collections. There are no obvious gaps, and the tools support complex workflows like flows and load testing.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Apideck MCP A
dev.apideck.mcp
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
Developer Tools
42
secureflows-mcp A
io.github.michal-lefler
MCP server for secureFlows: token-free URL builders and integration-linting tools for AI agents.
Code Analysis Developer Tools Security
181
postman-mcp-server
com.postman
A basic MCP server to operate on the Postman API.
API Testing Developer Tools App Automation
3311
SupabaseOAuth
com.supabase
MCP server for interacting with the Supabase platform
Cloud Platforms Databases Developer Tools
32,890

Related MCP Servers

Bruno MCP
Testing & QA Tools Developer Tools
hungthai1401
A
license
B
quality
D
maintenance
MCP Server for running Bruno Collections
Updated a year ago (2025-08-16 04:24 UTC)
1
87
44
MIT
Postman MCP Generator
API Testing Developer Tools App Automation
harichandra599
F
license
Not graded
quality
D
maintenance
An MCP server that converts Postman API requests into executable tools for LLMs using the Postman Runtime. It supports complex authentication types and enables seamless integration between Postman collections and MCP clients like Claude Desktop.
Updated 5 months ago (2026-03-27 12:50 UTC)
-
Postmancer
API Testing Developer Tools
hijaz
A
license
Not graded
quality
D
maintenance
A standalone MCP server for API testing and management, allowing AI assistants to interact with RESTful APIs through natural language.
Updated a year ago (2025-08-19 00:45 UTC)
23
28
MIT
bruno-mcp
API Testing Developer Tools
jackmulligan-ire
A
license
Not graded
quality
C
maintenance
MCP server that executes requests from Bruno API collections via the Bruno CLI tool, enabling API request execution and collection management.
Updated 5 months ago (2026-04-14 20:13 UTC)
4
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/cocaxcode/api-testing-mcp'

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